Re: [Haskell-cafe] Re: Nano-Languages

I'll try to paraphrase you, to see if I understand you correctly. The composition splice . quote can have one 'hard' error source. Grammatically incorrect quote. I think that will be caught by the type checker. Of a bigger concern are logical errors, introduced by buggy macros. But it is template haskell, so the same rules and tools apply. What I suggest is replacing the $x of template haskell, with S.x, where S is a module imported for syntax. What I'm not sure is how to deal with matching$(...). I'm not sure that the parenthesis can be avoided in all cases. On Thu, Dec 10, 2009 at 4:59 PM, John D. Earle wrote:

Vladimir, I do not mind becoming more familiar with the internals, but as you pointed out that Template Haskell may provided much of the needed functionality. I tend to doubt that it will provide all the needed functionality, however. The new syntax created by the syntax macros will either reinterpret a preexisting production in the language or will create a new one which may be based on a preexisting production, a variant. In the latter case, the compiler will have a knee jerk reaction. It will feel that the structure is grammatically illegal! This knee jerk would need to be intercepted and assigned an interpretation. We would then need to calm the compiler down and say its ok.

-------------------------------------------------- From: "Vladimir Zlatanov" Sent: 10 Thursday December 2009 0854 To: "Haskell Cafe" Subject: Re: [Haskell-cafe] Re: Nano-Languages

...

...

If one were to think of this as a project, the initial project goal might be a proof of concept, that such an undertaking though non-trivial may be worth while.

for me it is currently quite tough, since I don't know the internals at all

...

It would be desirable to act on the abstract syntax trees that result from the compiler parsing the source code and not the source code itself.

Template Haskell does that - it provides quotations, quasi-quotations and splicing, along with other utilities.

I would guess that a simple design would be to add an import_syntax clause, similar to import, but importing only declarations with type ...-> Q ... and splicing automatically their appearances.

This is a back of the envelope design, and I haven't considered any potential side-effects, but sounds like a reasonable approach _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe