On 11/6/06, Neil Mitchell wrote:

Can you mention what you need type information for? If it is to detect higher order functions (as you have mentioned in IRC conversations with me) then in about a week I am going to announce a Yhc.Core first order transformation, which will remove that issue for you. In general the lack of types in Yhc.Core has not proved a major issue for anyone - if there is anyone who does absolutely require type information in their intermediate language and therefore cannot use Yhc.Core, I'd be very interested to hear from them.

As you said, detecting the use of high order is one of the reasons as it's not supported by VHDL. I haven't yet planned how to achieve the translation but VHDL, unlike Haskell, doesn't have type inference mechanisms. That means I need to declare the interface of whatever I will translate each Yhc.Core function to (i.e. VHDL Entities, Architectures, Functions ... )

...

I discarded GHC due to the current "bit-rotted" state of External Core

Igloo submitted a few patches in the last week to get GHC.Core working again. It doesn't have the same infrastructure support as Yhc.Core, but it does have the advantage of having the GHC team behind it.

Does that change involve ExternalCore as well? Either the way, those are great news. I'll have a look at it again.I don't know much about SystemFC itself but I'm familiar with SystemF and doesn't seem as friendly and easy to work with as Yhc.Core . I'll give it a try anyway. Thanks for the answer, Alfonso Acosta (fons)

Hi

I haven't yet planned how to achieve the translation but VHDL, unlike Haskell, doesn't have type inference mechanisms. That means I need to declare the interface of whatever I will translate each Yhc.Core function to (i.e. VHDL Entities, Architectures, Functions ... )

Can you explain more about the "declare the interface" remark? I suspect this can be acheived with Yhc using the signatures from the .hi files, or embeding the information with our "typerep" Haskell extension.

It's true that the ExtCore rep is somewhat bit-rotted, but the only thing missing to get Core *output* is someone to beef up the pretty printer. I'd do it myself, except that there is a *design* task to do, namely to fix the concrete syntax for some of FC's constructs. One could choose anything, but it'd be good to choose a syntax that is easy to parse. Once the syntax is designed, it'd take an hour or two to make GHC emit it. (There's a separate job to make GHC parse and typecheck ExtCore as its source program, but you don't need that.)

For a reference point, I debated what the Yhc Core language should look like for a while. Then I gave up, grabbed a copy of DrIFT, adding "deriving Binary" annotations and was done. There is a concrete binary data type that represents Yhc.Core, but I have no idea what it is, and I certainly don't support access to it. There is a Haskell library which can load a Yhc.Core file, manipulate it, write it out etc - removing the need for a concrete syntax. We have a pretty printer, but since thats a one way mapping its much easier, we just made it look as much like Haskell as possible (no Z encoding etc). Thanks Neil

Hi

That implies I need a way to infere or directly obtain the types of the functions used in the core representation. That as you said, can probably be done by means of the .hi files or the typerep extension you mentioned. I'll try to have a look at both options. Any good documentation pointers?

For .hi files just compile it with Yhc and take a look at the .hi file it creates, they are plain text. If they are top level functions (which they certainly are, I guess) this should be all you need. Another approach is to get the type information out of Hugs with the :t command line prod. I've done this before in another project. Thanks Neil

After considering the different options (specially Yhc.Core) I decided to go for Embedded Compiling [1] + Observable Sharing[2] to translate from ForSyDe[3] to VHDL[4] instead of making a whole Haskell-Compiler backend. Creating a backend would fit a more ambitious goal: translating any haskell source file to VHDL, and of course would be more difficult to approach. The drawback of the Embedded Compiler approach is that ForSyDe will need to be adapted. But instead the translation would be quite easy to make and what is more important, a lot more maintainable due to being independent of external tools and embedded in the library itself. Thanks a lot for your suggestions. Specially to Neil who is fortunately always open to help. References [1] http://haskell.org/haskellwiki/Research_papers/Domain_specific_languages [2] http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html [3] http://www.imit.kth.se/info/FOFU/ForSyDe/ [4] http://en.wikipedia.org/wiki/VHDL On 11/12/06, Alfonso Acosta wrote:

...

For .hi files just compile it with Yhc and take a look at the .hi file it creates, they are plain text. If they are top level functions (which they certainly are, I guess) this should be all you need. Another approach is to get the type information out of Hugs with the :t command line prod. I've done this before in another project.

Sorry for the delay answering. I didn't (and still won't) have access to the Internet for a few days but Ill try it and tell you if it worked once I'm back to normality.

Thanks,

Alfonso Acosta