Reduceron
Reduceron copied to clipboard
tommythorn
Need a Haskell front-end
When writing code for Reduceron, I currently start with Haskell program and manually translate it to Flite, including adding whichever library/prelude functions I use. This is pretty tedious. Unfortunately, hf doesn't appear to be very helpful.
A proper Haskell front-end or compiler is much desired. I briefly looked at GHC, but that tasked seemed to daunting and also it wasn't obvious where to go as STG assumptions creep in rather quickly (Reduceron is a essentially a template reducer and doesn't quite match the GHC model).
Fay or JHC may be a better choice.
I hope someone volunteers...
Fay has a very similar issue and it only makes sense to pay deeply attention to the solution they eventually adopts. Some options are discussed at the end of "Why fay does not currently support type classes".
After looking at some of the GHC API, I think it might be possible to hook in via CoreModule, which happens technically before any transformation into STG, although I suppose it's possible that STG assumptions have already been made
Thanks, that sounds promising. Would you be able look into more? I'll read up on CoreModule myself.
This should be doable- basically all of the work will be in translating Core bindings into Reduceron templates. Speaking of which- in the Reduceron specification, the template type is defined as:
type Template = (Arity, App, [App])
but in the Flite code the template type is defined as
type Template = (String, Int, [LUT], [Atom], [App])
Is there any explanation for what was added/changed?
Hi Benji,
I've been following your work, but haven't had time to replicate it yet.
I hope you'll find https://github.com/tommythorn/Reduceron/blob/master/semantics/Reduceron.lhs useful. I know I have returned to it many times and still am.
I derived the text from the report into a series of six semantic models, with the last one capable of running unmodified Red files (within limits of memory and time). There should be the explanations you are looking for, otherwise please let me know.
One thing I should mention: if we are going straight to Red (which is a valid choice), we need to implement/port all the transformation and optimizations that Flite performs. It may be an easier route to hook into Flite and use that as a backend.
I had looked into that, and I think you're right- hooking into the Flite frontend will be easier than trying to replicate all of the transformations. Also, there's no need to redo all of the conceptual work of compiling a functional language to Red.
I'm going that route (GHC -> Flite -> Red) currently, and it's been going well. Probably once I have a working first iteration, I'll work on some of the inefficiencies introduced- like collapsing nested lambdas together, etc.
Hey, so I made some good progress on connecting GHC to Flite, and I wanted to push my work to a branch on this repo. I don't have any experience doing open source work, so I'm not really sure how I would go about doing that. I have a local branch that I'd want to push, and all the work is organized in a top-level folder named 'red'
That's excellent.
There are lots of ways this can be done, but the standard way is for you to fork my repo and send me pull requests. Normally one would merge these, but I'll rebase instead to get rid of the merge points as described in http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful
I don't see the need for this to go an a separate branch though as there will be no conflicts (I assume) with the rest of the repo.
I do have one request: Can you named it something other than "Red"? That name is already taken for the backend .red files and besides, it's really overused. Just about anything that doesn't start with "Red" would be fine (fx. GHCtoRed or something more elegant).
I'm happy to name it something other than red. ghc-flite would probably be the most accurate name. 'red' was just the name that I imagined the compiler would have, but that's for another time.