
Earlier in this thread I wrote "... but like so what." In this letter I hope to address what I wrote more fully. The command line option that was found that allows for Haskell source code to be preprocessed accepts a Haskell source code file as an argument. This file defines a preprocessor. It seems to me that such a preprocessor would be undisciplined and capable of wrong doing because the Haskell language does not have all the facilities that a utility such as Happy possesses. Care is needed. It also lacks those facilities that are particular to preprocessors. The paper at http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf may provide a means to introduce this needed discipline. I do not see how the runtime verses compile time distinction is important, however. You can't really hand craft a preprocessor on the fly that is going to work. I do not believe the paper is explaining itself all that well. What they are referring to as syntax macros given a superficial examination of the paper seem to be the functional language equivalent of a definite clause grammar found in Prolog. So it seems that an effort to bring that goodness that Prolog programmers have enjoyed for years over to Haskell and perhaps to do one or two better. Their emphasis on runtime verses compile time seems like a distraction in that it is merely a necessary condition for inclusion into the Haskell language since Haskell is both compiled and interpreted. It is a problem that would need to be solved. They may have lost sight of what they were doing after having spent so much time working on just this one aspect. Haskell at the present time need external tools. The benefits of bringing in that sort of functionality into the language I would regard as self-evident. It is still a bottom up approach, but a bottom up approach would be easier to implement and it would be desirable for the two worlds to meet, the bottom up and the top down. An important question will be, Will syntax macros work out better than an existing tool such as Happy?

An important question will be, Will syntax macros work out better than an existing tool such as Happy?
They work in scheme, and typed scheme http://www.ccs.neu.edu/scheme/pubs/popl08-thf.pdf and a different hygienic mscheme is used in dylan http://people.csail.mit.edu/jrb/Projects/dexprs.pdf Both are based on pattern matching rewrite rules. Integrating a similar macro system in haskell should be possible, but definitely not trivial - how will it interact with the type system? Haskell is already halfway there, Template Haskell provides a platform to base them on http://www.haskell.org/ghc/docs/6.10-latest/html/users_guide/template-haskel...

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.
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.
--------------------------------------------------
From: "Vladimir Zlatanov"
An important question will be, Will syntax macros work out better than an existing tool such as Happy?
They work in scheme, and typed scheme http://www.ccs.neu.edu/scheme/pubs/popl08-thf.pdf and a different hygienic mscheme is used in dylan http://people.csail.mit.edu/jrb/Projects/dexprs.pdf Both are based on pattern matching rewrite rules. Integrating a similar macro system in haskell should be possible, but definitely not trivial - how will it interact with the type system?
Haskell is already halfway there, Template Haskell provides a platform to base them on http://www.haskell.org/ghc/docs/6.10-latest/html/users_guide/template-haskel... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

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"
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

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
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
participants (2)
-
John D. Earle
-
Vladimir Zlatanov