[Prev][Next][Index][Thread]
Re: Simple Reader Macros for Dylan
> [...]
>
> > The syntax:
> >
> > #<name>:<text>
> >
> > gets transformed, setter-like, into:
> >
> > <name>-parser(<text>)
>
> Hmmm, so these are not so much reader macros as just a new bit of syntactic
> sugar, correct? <name>-parser doesn't actually get called at compile-time,
> correct?
Well, if <name>-parser is a macro rather than a function, then it will
get called at compile-time. You need an extended macro system to be able to
take a string apart usefully, however.
Certainly <name>-parser doesn't get called at read time with a stream like
Common Lisp reader macros do, so the mechanism is less general than that.
The benefit is that Dylan implementations that don't support compile-time
evaluation can still provide this facility.
> [...]
>
> > An example parser:
> >
> > define method html-parser
> > (text :: <byte-string>) => (doc :: <html-document>)
> > make(<html-document>, text: text);
> > end method;
> >
> > If an appropriate function isn't defined, you get a standard unbound
> > variable reference message indicating the # literal.
>
> I assume errors are reported by the parser throwing some condition?
If you mean the <name>-parser function or macro, then yes (a macro might
signal a parse error to the compiler either implicitly, due to a match
error, or perhaps explicitly in the case of a procedural macro).
> [...]
>
> > Also in order to allow these sort of literals in literal lists and
> > vectors,
> > we further propose to allow arbitrary expressions in "literal" lists
> > and vectors. The same constancy/sharing rules would still apply to the
> > lists and vectors themselves. That is:
> >
> > let times = #[#time:12:30am, #time:4:15pm];
> > ==
> > let times = #[time-parser("12:30am"), time-parser("4:15pm")];
> >
> > which is allowed, but still:
> >
> > times[0] := times[1];
> >
> > "is an error" in case the compiler can work its magic.
>
> You've lost me here... Why is the above assignment an error?
Because Dylan compilers are allowed to apply literal constant merging: i.e.
using the same object to represent more than one literal (or part of a
literal) if those literals are structurally identical. The objects
corresponding to literal constants are also often located in read-only
sections. For these reasons, attempting to mutate a literal string, list,
or vector is an error in Dylan.
-- Keith