Re: [groovy-dev] Re: [groovy-jsr] Re: [groovy-dev] static binding subsystem for better performance

On 13 Jul 2004, at 22:35, John Rose wrote:

>
>
> jastrachan@... wrote:
>> On 8 Jul 2004, at 00:30, Chris Poirier wrote:
>>> Hi James,
>>>
>>>> Maybe we should use a magic type name of 'any' to indicate that you
>>>> definitely want to be dynamically typed?
>>>
>>>
>>> My shortlist for the next time I have some groovy time:
>>>
>>>  1) add "any" as a keyword and make type required on method and
>>>     member declarations (thus eliminating numerous ambiguities and
>>>     the "def" keyword)
>
> I guess "any" is a reasonable way to deal with the ambiguity.  We're 
> coming to the point where we need to define the type system, and (in 
> particular) explain why "any" differs from "Object".  I find it 
> frustrating (though it's maybe inevitable) that Groovy has to define a 
> "really really root type" that is not Object.

I guess 'any' is just a magic type which means, this value can be of 
any type whatsoever and dynamic method dispatch will be used to invoke 
any operations. i.e. do not use static typing.

> Let me suggest an alternative way to get rid of the 
> declaration/statement ambiguity (which I agree is very bad).  Allow 
> the keyword "let" to mark declarations:
>
>    let x = 5
>    let String y = "foo"   // 'let' is optional here
>    String y2 = "foo2"     // 'let' was optional here
>    let z                  // z==null by default
>    let a = 1, b = 2, c = 3
>    let (a,b,c) = (1,2,3)  // if we do tuples
>    let f(x) { return x+1 } // disambiguated method def
>
> Maybe it's just me, but I like the way 'let' reads....

though there is a nice symmetry about interchanging any with types.

any x
int y
boolean b

>> Good call - if this fixes ambiguity lets do it. Can we list the 
>> ambiguities first so we know what they are & can put them somewhere 
>> on the wiki so we remember why we're doing this
>>>  2) changing the statement terminator to EOL from semicolon (with
>>>     automatic line continuation at trailing operators, a la Ruby)
>> I'm not sure about the line continuation part; there's always a way 
>> to wrap things over multiple lines if people really wanna do that.
>> e.g.
>> coll.each {
>> }
>> could be done as
>> coll.each(
>> {
>> })
>> sure its 1 more character than using a line continuation but hey, 
>> folks should use the groovy way, { on the same line :)
>
> James and I also discussed the trick of using a statement label, which 
> has additional advantages (which I will enumerate soon):
>
>   coll.each block:
>   { ... }
>   coll.each b:
>   { ... }
>
> (Named blocks and named (&KEYWORD) parameters can be unified in 
> interesting ways....)

Agreed. This is a neater workaround for those who really wanna put 
their squiggleys on the next line using a reserved label.

>>>  3) making the leading | on closure parameter lists required.
>> I chatted to John at J1 and it might be we can come up with syntax 
>> rules so that we only use 1 | by default and only use a leading | (or 
>> parenthesis) to be explicit when there could be ambiguity.
>
> Yes.  Note that Java forbids most expressions as statements:  You must 
> have an assignment or method call as the top-level syntax of an 
> expression statement.  Therefore, the following is not really 
> ambiguous:
>
>    { x | f() }
>
> In the interests of conciseness, we should exploit this fact, to 
> support the single-bar syntax.  Basically, the thing before the single 
> bar, if it is just a list of names, should be implicitly 
> parenthesized, and anything more complex than a name list must be 
> explicitly parenthesized:
>
>    { x = 2 | f() }    // no argument list
>    { (x = 2) | f() }  // one argument
>    { (x, String y) | f() }  // 2 arguments

Or we could use another | if we need to be explicit - its maybe a bit 
less noisy

{ x = 2 | f() +} 		// no arg list
{| x = 2 | f() } 		// one argument
{| x, String y| f() } 	// 2 arguments

>> BTW next time you've some parser hacking time I'd like to support 
>> $foo inside Strings...
>> println "hello $user how are you $today"
>> i.e. $ followed by identifier.
>
> These G-strings rock.  A lot of Groovy codes will assemble vaguely 
> tree-structured output strings using these strings.  Long ago they 
> were called "ropes" or "bundles" and they have the great property that 
> assembling them does not require characterwise copying.  Eventually, 
> they must be flattened (for output or conversion to flat strings) and 
> this requires a tree-walk, essentially a post-pass.  I've used this 
> structure in source-code generators several times, and it's a win.

Agreed. We've a Writable interface as well which GStrings support so if 
you're sending a large GString with lots of expressions to some 
underlying Writer then things are streamed efficiently without having 
to make an unnecessary long String of everything first.

James
-------
http://radio.weblogs.com/0112098/