Re: [Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
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 [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
| In order to get part of the work for free I decided to design the | translator as a compiler backend. The best option so far seems to be | Yhc's Core API (http://haskell.org/haskellwiki/Yhc/API/Core ), which | unfortunately lacks type information. | | I discarded GHC due to the current bit-rotted state of External Core | (http://www.haskell.org/pipermail/haskell-cafe/2006-October/018786.html | ) and higher complexity of its core representation (SystemFC). Yhc is a great, so don't let me stop you using it... but I can't resist explaining why FC is the way it is. There is a real tension here between simplicity and types. The reason that GHC uses FC as its intermediate language is precisely because FC is the simplest *typed* language we know that can serve as a target for Haskell. If you drop the types, you certainly can use a simpler language! However, you only pay for what you use; for example, if you don't use newtypes, GADT's, associated types, you won't see any coercions. 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.) Aaron Tomb has offered to become the maintainer for External Core; I'm sure he'd be interested in having a customer. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
On 11/6/06, Neil Mitchell [EMAIL PROTECTED] wrote: 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. I think you're correctly suspecting it. What I meant is that, like with every structured programming language (that I know about at least) all VHDL functions and procedure declarations (Entities Architectures as well) include a mandatory interface declaration which includes the type of its parameters and possible return value. 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? I think that should be all the type information required for the translation. Yhc is a great, so don't let me stop you using it... but I can't resist explaining why FC is the way it is. There is a real tension here between simplicity and types. The reason that GHC uses FC as its intermediate language is precisely because FC is the simplest *typed* language we know that can serve as a target for Haskell. If you drop the types, you certainly can use a simpler language! I'm sure SystemFC wasn't arbitrarily chosen, and works well for its main purpose (being GHC's intermediate language). On the other hand it can be a bit complicated if it is used as the input of backend whose goal is translating to a another another high abstraction language. For my planned backend, it _seems_ to be enough to use a desugarized version of the initial source file as input and being able to obtain/infer the type its the functions. That doesn't mean I have already discarded GHC, I recorsidered it again after reading that there is some work being done to update it. Does http://www.haskell.org/ghc/docs/papers/core.ps.gz still apply? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
Hi all, As I wrote in the previous HLADPSA announcement, during the following moths I'm going to write a translator from Haskell to VHDL in order to accomplish my masters thesis goal. The main requirement is managing to translate from a ForSyDe (http://www.imit.kth.se/info/FOFU/ForSyDe/ ) specification which is Haskell after all, to VHDL. In order to get part of the work for free I decided to design the translator as a compiler backend. The best option so far seems to be Yhc's Core API (http://haskell.org/haskellwiki/Yhc/API/Core ), which unfortunately lacks type information. I discarded GHC due to the current bit-rotted state of External Core (http://www.haskell.org/pipermail/haskell-cafe/2006-October/018786.html ) and higher complexity of its core representation (SystemFC). I might have overlooked other approaches and/or intermediate representations such as GHC's C-- and STG (is it still used?). I'd be pleased to hear any suggestions. Thanks in advance, Alfonso Acosta ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
Hi In order to get part of the work for free I decided to design the translator as a compiler backend. The best option so far seems to be Yhc's Core API (http://haskell.org/haskellwiki/Yhc/API/Core ), which unfortunately lacks type information. 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. I discarded GHC due to the current bit-rotted state of External Core (http://www.haskell.org/pipermail/haskell-cafe/2006-October/018786.html ) and higher complexity of its core representation (SystemFC). 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. I'd be pleased to hear any suggestions. I (obviously...) would like you to use Yhc.Core, if you could expand on why that isn't appropriate for you then perhaps you'll either get improvements into Yhc.Core or some hints from the GHC team :) Thanks Neil (ndm) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
On 11/6/06, Neil Mitchell [EMAIL PROTECTED] 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) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
