[Haskell-cafe] [Haskell] ANN: syntactic-0.1

[Emil Axelsson]

2011-05-07 09:52, Heinrich Apfelmus skrev:
> Emil Axelsson wrote:
>> I'm happy to announce the first release of syntactic:
>>
>> http://hackage.haskell.org/package/syntactic
>>
>> providing generic abstract syntax and utilities for embedded
>> languages.
>>
>> To get an idea of what it's about, check out the tiny(!)
>> implementation of (simplified) Feldspar in the Examples directory:
>>
>> http://projects.haskell.org/syntactic/Examples/MuFeldspar
>>
>> The library is intended to provide a growing set of utilities for
>> embedded languages. In particular, I hope to be able to provide safe
>>   interfaces to various unsafe techniques for speeding things up.
>>
>> Comments, patches and clients are welcome!
>
> Looks very interesting!
>
> I'm currently working on a functional reactive programming DSL. Source code:
>
>      http://tinyurl.com/reactive-banana-0-2-pushio
>
> The  EventD  type represents the abstract syntax tree (line 150), which
> is then compiled in three phases (line 313)
>
>     compile e ~= map compilePath =<<  compileUnion =<<  compileAccumB e
>
> If you look at the  EventD  type, you can see it contains a lot of
> "internal constructors" (line 158) that are created in destroyed in
> certain compilation phases. Ideally, I would make a new  EventD  type
> for each compilation phase that doesn't have any superfluous
> constructors. For instance,  compileUnion  removes the  Union  constructor.

Hello Heinrich! Thanks for your interest!

In principle, this is exactly the kind of thing you can do with 
syntactic -- if you can make your data type fit into the framework, that 
is. A compilation phase would then look something like this:

   phase :: AST (C1 :+: TheRest) -> AST (C2 :+: C3 :+: TheRest)

This phase destroys the constructor C1 and introduces C2 and C3.

Now, the question is whether your data type can be made to fit into the 
framework. The only problem I can see (but there may be more!) is that 
you'd have to treat EventD and BehaviorD as parts of the same data 
structure. I've pasted an example of how to do that here:

   http://hpaste.org/46525/

Here, the difference between Event and Behavior is denoted by the type 
constructors E and B respectively:

   type Event a = ASTF (Never :+: B2E :+: Pure :+: E2B) (E a)

   type Behavior a = ASTF (Never :+: B2E :+: Pure :+: E2B) (B a)

You decide if this seems like an acceptable solution...



> I'm also unhappy about some of the boilerplate. For instance, have a
> look at the function  goE  in  compileAccumB  (line 210), it's just a
> generic applicative traversal through the data type.

Most likely, this boilerplate could be simplified using syntactic.



> Would your library make me happier? Note that I have an additional
> complication: I need to observe sharing and I need to support recursive AST.

I plan to add observable sharing soon. Once that's is in place, it 
should -- I think/hope -- be easy to support cycles. This is not 
something we need in Feldspar, so it might take a while before I get 
around to supporting cycles, though.

I'd be happy to give more assistance should you choose to try out 
syntactic for your library!

Best regards

/ Emil