[Prev][Next][Index][Thread]

Re: Simple Reader Macros for Dylan

When Keith first suggested this, I thought it
looked really neat.  After some reflection, I
wonder whether it really offers much over simple
strings.  Instead of converting a simple name
into a longer function name, why not just use a
simple function name?

> #http://www.functionalobjects.com/
http("//www.functionalobjects.com")

> #time:12:30am
time("12:20am")

> #date:12/3/2000
date("3/12/2000")
    ;-)
> #file:D:\dylan\sources\
file("D:\\dylan\\sources")

> #mailto:sales@functionalobjects.com
mailto("sales@functionalobjects.com")

The only advantage I can see for the literal
syntax is the option of using different
delimiters and escape processing.  Where I've
most often wanted this is when dealing with
strings containing backslashes, as with the
Windows path above.  Perhaps a simpler change
would be the ability to change the string escape
character, either as a compiler option, or by a
declaration in the code.  E.g.

string-escape('^');
file("D:\dylan\sources");
print("hello, world^n");

Obviously STRING-ESCAPE would have to be a
declaration that the compiler recognises, not a
regular Dylan expression.

(Please pardon any lapses in my Dylan syntax).

Dave.

P.S. Hi!



In article
<199911161645.LAA12733@life.ai.mit.edu>,
  Jonathan Bachrach <jrb@functionalobjects.com>
wrote:
> As promised here is a very brief description of
a very simple reader macro
> facility that permits Dylan to have friendly
literal formats for popular
> data types. This was thought up by Andrew
Armstrong, Keith Playford and
> myself while at Harlequin.  We would love to
get your feedback on it.  The
> following is Keith's description of it.
>
> Jonathan Bachrach
> President, Functional Objects, Inc.
>
> Simple Reader Macros
>
> The syntax:
>
> #<name>:<text>
>
> gets transformed, setter-like, into:
>
> <name>-parser(<text>)
>
> The <text> part can be either delimited or
undelimited. Undelimited text
> can contain anything but commas, semicolons,
brackets of any kind, and
> whitespace. There is no \ escape processing.
All the following are valid:
>
> #http://www.functionalobjects.com/
> #time:12:30am
> #date:12/3/2000
> #file:D:\dylan\sources\
> #mailto:sales@functionalobjects.com
>
> In the delimited form, you have a choice of
delimiters: "...", (...), [...],
> {...}. Within the delimiters, only the matching
close delimiter must be
> escaped. The selection allows you to choose the
delimiter requiring least
> escaping for the enclosed data. The text (less
the delimiters) is passed
> to the parsing function. Examples:
>
> #file:"C:\Program Files\Functional Objects\."
> #html:{<html>
> <head><title>Foo</title></head>
> <body bgcolor="#FFFFFF">
> </body>
> </html>}
>
> 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.
>
> 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.
>
>



Sent via Deja.com http://www.deja.com/
Before you buy.