jstrachan | 29 Jan 09:21 2005
Picon

Re: [groovy-dev] The opposite of builders

I confess to not quite following this; maybe I've not had enough coffee 
yet :)...

John Rose wrote:
> Long ago and far away, in a fit of envy over ML's destructuring case 
> statements, I added such a thing to Lisp as a macro, a variation on 
> Lisp's SETF convention.  It was groovy.  You could bind a value to a 
> series of backquote/comma expressions, and the things under the commas 
> became bound variables, if the structure matched.
> 
> That approach could harmonize with Groovy's switch statements.  The key 
> is being able to associate information with some operators and methods 
> (such as constructors) which tells the compiler and runtime how to 
> invert them.  By invert them, I mean taking a connection between "x" and 
> "foo(y,z)" as an instruction to inspect x as a 'foo' and extract its y 
> and z parts for further inspection.  (As opposed to taking y and z, and 
> building a foo out of them, called x.)
> 
> For example, a straw man syntax:
>    switch (x)  { case foo(def x, def y): println x }

I don't quite follow what this means; x is switched on, then passed into 
foo(), but z is printed? And what is the value of y?

> 
> would compile to something like:
>    def Object[] tmp = destructureUsing(x, foo, 2 /*it had 2 args*/ );
>    if (tmp)  { def y = tmp[0], z = tmp[1]; println z }
> 
> The destructureUsing call would have various bits of case analysis in 
> it, but the clean thing to do would be to have most invertible methods 
> declare themselves via an interface.
> 
> Note that it is not necessary for the compiler to know the identity of 
> the function 'foo'.  (There is no hash table with a key the string "foo" 
> and a value a parse-time macro expander.)
> 
> It seems likely that this could be made, with care, to mesh with builder 
> syntax, so that you could put a builder expression after a 'case'.
> 
> So, I like Mark's destructuring approach better than the programmable 
> parser approach.
> 
> Programmable parsers, by the way, ought to be expressible with Groovy 
> builders, or we've made a big mistake somewhere.

Agreed

James


Gmane