Prev: What do we call (+ lisp cells qooxdoo)?
Next: comparing types for equality
From: Pascal J. Bourguignon on 18 May 2010 16:11
Peter Keller <psilord(a)merlin.cs.wisc.edu> writes:

> Tamas K Papp <tkpapp(a)gmail.com> wrote:
>> On Tue, 18 May 2010 00:21:13 +0000, Peter Keller wrote:
>> I don't see why I should care about the extensions you use to _define_
>> your macros, when I am just _using_ those macros. So I see no problem
>> with the ! stuff (though personally I don't see the great
>> advantages, I am fine with existing facilities like with-unique-names
>> and once-only).
>
> I see, so in general noone would care that a macro might encode a DSL in its
> API. People would read the directions, and hopefully get it right.
> I can live with that.
>
>> Regarding read macros: check out the named-readtables library, it
>> brings some sanity into the management of readtables/readmacros.
>
> Interesting.
>
> Are there any really good tutorials out there for how to use readtables
> to make things like Pascal suggessted (with the C syntax to lisp syntax
> translator)?

Well, implementing the C syntax with reader macros is somewhat an
extreme example, since it would involve mapping all the characters to
reader macros, to start the parsing of a C form from any character
read. (With more thinking I guess we could select a set of "start"
character to begin parsing a C form).

Basically:

(dolist (code (cons 10 (loop for i from 32 to 127 collect i)))
(set-macro-character (code-char code)
(lambda (stream ch)
(unread-char ch stream)
(parse-c-form stream))))


Then parse-c-form may start parsing the input stream, until it has
read and parsed one form, for example, something like:

(defun parse-c-form (stream)
(let ((parse-tree (c-parser stream)))
(c-parse-tree-to-lisp-sexp parse-tree)))



--
__Pascal Bourguignon__ http://www.informatimago.com/
From: Tim Bradshaw on 18 May 2010 17:59
On 2010-05-18 19:44:52 +0100, Peter Keller said:

> Are there any really good tutorials out there for how to use readtables
> to make things like Pascal suggessted (with the C syntax to lisp syntax
> translator)?

I'm guessing not, since Lisp people generally don't *want* to do that,
since, being Lisp people, they tend to like the syntax they have, or
minor variants.

From: Peter Keller on 18 May 2010 21:05
Tim Bradshaw <tfb(a)tfeb.org> wrote:
> On 2010-05-18 19:44:52 +0100, Peter Keller said:
>
>> Are there any really good tutorials out there for how to use readtables
>> to make things like Pascal suggessted (with the C syntax to lisp syntax
>> translator)?
>
> I'm guessing not, since Lisp people generally don't *want* to do that,
> since, being Lisp people, they tend to like the syntax they have, or
> minor variants.

I'd totally believe that.

However, knowing this, what extensive readtable hackery has been done? Is any
of it documented somewhere? What is the computational complexity of readtable
coding, can one do only lexical analysis with it? Actual parsing? If parsing,
can only LL(1) be done? LL(k)? LALR(k)?

Thank you.

-pete
From: D Herring on 19 May 2010 00:36
On 05/18/2010 09:05 PM, Peter Keller wrote:

> However, knowing this, what extensive readtable hackery has been done? Is any
> of it documented somewhere? What is the computational complexity of readtable
> coding, can one do only lexical analysis with it? Actual parsing? If parsing,
> can only LL(1) be done? LL(k)? LALR(k)?

You can extend the CL reader with arbitrary code. Once a reader macro
has been triggered, that macro is given the input stream and it can
consume characters however it wants. It can even query google if it
wants to know how to interpret a character.

Hence there is no principled way to layer such extensions.

Hence the best we have is to store entire readtables, and use tools
like named-readtables to cleanly swap them in and out.

Hence reader macro collisions are a real problem, and people generally
discourage their use when plain macros would do just as well.

- Daniel

P.S. Take a look at PLT Scheme if you'd like to see another approach
on the topic of local syntax.
From: Peter Keller on 19 May 2010 02:01
D Herring <dherring(a)at.tentpost.dot.com> wrote:
> On 05/18/2010 09:05 PM, Peter Keller wrote:
>
>> However, knowing this, what extensive readtable hackery has been done? Is any
>> of it documented somewhere? What is the computational complexity of readtable
>> coding, can one do only lexical analysis with it? Actual parsing? If parsing,
>> can only LL(1) be done? LL(k)? LALR(k)?
>
> You can extend the CL reader with arbitrary code. Once a reader macro
> has been triggered, that macro is given the input stream and it can
> consume characters however it wants. It can even query google if it
> wants to know how to interpret a character.

So, one could take something like a lex/yacc specification and have it output a
readtable and associated code to do lexical analysis and parsing, and then have
the rest of the readtable codes convert the parsed AST into real lisp forms
which is the final output of the read macro?

> Hence reader macro collisions are a real problem, and people generally
> discourage their use when plain macros would do just as well.

I have a particular application in mind, mostly dealing with integrating
multiple programming languages into one variable namespace.

An example would be:

(let ((a 0))
#{
int i;
for (i = 0; i < 10; i++) {
a += i;
}
}

(+ a 10))

See how the binding of 'a' is used between both languages?

It could be theoretically (I'm ignoring bignums and whatnot for this example)
converted to:

(let ((a 0))

(do ((i 0 (1+ i)))
((>= i 10))
(incf a i))

(+ a 10))

This is why I'm interested.

Thank you.

-pete
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: What do we call (+ lisp cells qooxdoo)?
Next: comparing types for equality