[wg-camlp4] Meta Programming from the view of the implementaion

[Hongbo Zhang]

Besides, I would really appreciate that we don't introduce *too many ad-hoc
rules*. typing several more characters is ok, typing hundred lines of code
does matter.

Haskell already suffers from its too flexible syntaxes, think about
haskell-src-meta which is a Haskell front-end, can not parse Haskell
correctly due to the fact that haskell's operator precedence is dynamic.

So far, to my best knowledge, all the feature requests should be not too
hard to implement or already exist  in Fan(without changing the grammar),
so I do hope that we don't introduce too much complexity in Parsetree for
little benefit or *making tooling too hard.*

Only one syntax extension I think revised syntax did in a write way is
match with [ ... ], the closed brackets really helps to avoid a lot of bugs.

On Thu, Jan 31, 2013 at 9:29 AM, Gabriel Scherer
<gabriel.scherer at gmail.com>wrote:

> >>> What about nested uses of the same quotation?
> >>>
> >> Handled like nested comments, assuming the lexer knows where the
> >> anti-quotations are.
> >
> > An assumption that I really don't think we should make. It involves
> forcing
> > a particular style of anti-quotation on all extensions. Besides it is
> easier
> > to simply use a syntax that supports unique delimiters.
>
> Note that there is a nice continuum in the design space for
> compromises between syntactic flexibility and easy tool support
> (assuming non-smart, non-extensible tools that know how to handle
> OCaml code):
>
> 0) Pure OCaml syntax : combinator libraries, etc. (note: this is where
> the mixfix discussion fits)
> 1) Alain's style of all-OCaml expressions, using annotations to denote
> the domain-specific semantics (tool support for the whole expression)
> 2) Quotations with an agreed-upon antiquotation syntax (tool support
> inside antiquotations)
> 3) Quotations with extension-custom antiquotation syntax (no tool
> support; treated like a string)
>
> I would be interested in seeing which use cases can be satisfyingly
> encoded under which approaches. I personally suspect that for
> small-scale syntax supports (say, regexps), the outer quotation syntax
> being too heavy is more problematic that any antiquotation syntax
> considerations (because if it needs to be short it probably doesn't
> have antiquotations besides possibly a custom syntax to denote OCaml
> variables, that need no editor support).
>
> (Note: to my knowledge, Hongbo was the first to remark (
> http://caml.inria.fr/mantis/view.php?id=5665 ) that the Camlp4 syntax
> for antiquotations was problematic for nested *antiquotations*. That's
> a cogent point that can also be taken into consideration, and
> something I like about his work on Fan. The use cases for this are
> however quite specialized, so it will be easy to counter-argue that
> those considerations are for the Fan-class of preprocessing, not the
> included-in-the-language-itself one.)
>
> On Thu, Jan 31, 2013 at 3:02 PM, Leo White <lpw25 at cam.ac.uk> wrote:
> > On Jan 31 2013, Török Edwin wrote:
> >
> >> On 01/31/2013 03:56 PM, Leo White wrote:
> >>>>
> >>>> What do you think of this syntax:
> >>>> {:lid|...|lid:}
> >>>
> >>>
> >>> What about nested uses of the same quotation?
> >>>
> >>
> >> Handled like nested comments, assuming the lexer knows where the
> >> anti-quotations are.
> >
> >
> > An assumption that I really don't think we should make. It involves
> forcing
> > a particular style of anti-quotation on all extensions. Besides it is
> easier
> > to simply use a syntax that supports unique delimiters.
> >
> >
> > _______________________________________________
> > wg-camlp4 mailing list
> > wg-camlp4 at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/wg-camlp4
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4
>



-- 
-- Regards, Hongbo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130131/388452b1/attachment.html>