[Prev][Next][Index][Thread]
RE: Simple Reader Macros for Dylan
> > #<name>:<text>
> >
> > gets transformed, setter-like, into:
> >
> > <name>-parser(<text>)
>
> This is a great idea. I can see it before me:
>
> #regex:"(\s+)[a-q]?"
>
> Using regexes in Dylan has been a nightmare due to all the escaping.
>
> > There is no \ escape processing. [...]
> > In the delimited form, you have a choice of delimiters: "...", (...), [...],
> > {...}. Within the delimiters, only the matching close delimiter must be
> > escaped.
>
> Ok, when there is no escape processing, then how do I escape the close
> delimiter?
The "there is no escape processing" bit is only meant to refer to the
undelimited version. As for the delimited form, we'd be open to suggestions
that get in the way as little as possible. I think the quickie prototype
we wrote just did \} -> } and \\ -> \ but it wasn't given much thought.
Under that scheme, though:
> Please specify how the following cases are to be handled:
>
> #foo:"\"
Char: "
Char: <more until an unescaped end delimiter is found>
> #foo:"\""
Char: "
> #foo:"\\"
Char: \
> #foo:"\\""
Char: \
with a " left over
> #foo:"\\\""
Char: \
Char: "
Not a great choice if you have to work much with MS network file names,
however. Perhaps something more heavyweight but less likely to look like
content, \}\ -> } maybe.
I guess another issue is, where there are distinct begin and end delimiters
(i.e. brackets of some kind), should scanning be nesting-aware & so should
escaping have to be applied to both delimiters? Example:
#dylan:{ define macro when
{ when (?test:expression) ?:body end } => { if (?test) ?body end }
end macro }
-- Keith
Follow-Ups:
References: