On Wed, Jan 21, 2009 at 2:24 PM, Eduardo Cavazos <[email protected]> wrote:
> The
> with-slots expression conceptually expands into an expression involving
> [let and [wlet. Those are in turn parsing words. with-slots is also a
> parsing word. So the standard Factor mechanism for macros cannot be
> employed here. Alarmingly, the implementation doesn't generate
> expressions involving the actual [let and [wlet words! It must resort to
> using the backend 'let' and 'wlet' tuple datastructures. At this point,
> this strikes me as a weakness in locals and macros. I.e. with this kind
> of abstraction, traditional macros break down. Parsing words are really
> a whole new ball game.

If you look at basis/functors/, and some of the usages (eg,
basis/alien/destructors/) you'll see an early attempt. Functors are
just a hack but I'm going to take it further at some point by changing
how parsing words work.

I want to make parsing more declarative; that is, the body of a
parsing word will no longer be an arbitrary piece of code, but some
kind of rewrite rule from the parsing word into a quotation. It would
be nice to also generate the inverse rewrite to make prettyprinting
and 'see'-type functionality automatic, rather than hand-coded as it
is now.

In turn, this will give us some kind of syntax for 'quoting' parsing
words. Eg, you can imagine constructing a [let expression by writing
code that has a [let expression with "holes" to be filled in.

I like rich syntax more than Lisp's "everything is an s-expression"
paradigm, and I don't think its incompatible with meta-programming.
The only problem that our current system has is that syntax needs to
be first-class, with a quasi-quotation-type facility, generalizing
functors.

As for macros, our current macros have the following semantics,

MACRO: foo ( ... -- ... ) XYZ ;

: foo ( ... -- ... ) XYZ call ;

That is, macros they don't buy you any expressive power, they're just
an optimization so that XYZ is constructed at compile time. So I think
macros are the feature that sticks out like a sore thumb, and better
partial evaluation, along with other compiler optimizations, could
eliminate the need for most of them (in Lisp it's even worse; I notice
that Lisp programmers tend to mostly only use macros to simulate
inline functions and to wrap verbose lambda syntax, rather than to
define DSLs).

Slava

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to