From mental at rydia.net  Wed Mar  1 13:40:25 2006
From: mental at rydia.net (mental@rydia.net)
Date: Wed, 01 Mar 2006 13:40:25 -0500
Subject: [grammarians] Subclassing Struct.new
Message-ID: <1141238425.4405ea99c1eab@www.rydia.net>

Quoting Yukihiro Matsumoto <matz at ruby-lang.org>:

> |Will the Ruby2.0 grammar no longer have variable/method
> ambiguities?
>
> I'm not sure what you meant by "ambiguities".  The identifiers
> not assigned in the scope will be treated as method calls, as
> well as in current behavior.

When speaking of grammar, "ambiguity" refers to situations where the
same text can parse to more than one tree -- for example:

 foo[1]  # (call (lvar foo) [] (array 1))
 foo [1] # (call (lvar foo) [] (array 1))

versus:

 foo[1]  # (call (fcall foo (array)) [] (array 1))
 foo [1] # (fcall foo (array (array 1)))

There may be disambiguating factors (e.g. whether 'foo' is known a
priori to be an lvar or a method), but those are external to the
grammar.

Rather than making the grammar itself ambiguous, it would be better
to introduce a new 'lvar-or-fcall' production parse the above
expressions unconditionally as:

 foo[1]  # (call (lvar-or-fcall foo) [] (array 1))
 foo [1] # (fcall foo (array (array 1)))

This way, it would be possible to write an unambiguous context-free
grammar for Ruby (heredocs and so forth aside).

Also, it would help users confused about whether "foo [1]" parses as
a method call or a variable access, since "foo 1" always parses as a
method call.

You'd still be free to backpatch the lvar-or-fcall node to an lvar
or fcall if you wanted to do so, but it wouldn't complicate the
grammar any longer.

Please don't make Ruby even harder to parse...

-mental

From parrt at cs.usfca.edu  Wed Mar  1 14:13:58 2006
From: parrt at cs.usfca.edu (Terence Parr)
Date: Wed, 1 Mar 2006 11:13:58 -0800
Subject: [grammarians] Subclassing Struct.new
In-Reply-To: <1141238425.4405ea99c1eab@www.rydia.net>
References: <1141238425.4405ea99c1eab@www.rydia.net>
Message-ID: <46CFBC2B-191C-4BF7-BAEA-D42A1C1AFC7F@cs.usfca.edu>

Hi all,

[assuming it gets to the ruby-talk list w/o challenge]

Let me second the idea that whitespace should not change the meaning  
of a construct...bad enough that it's context-sensitive (and  
lexically not via flow analysis) so that foo can be a function call  
or var ref.  ick.  Syntax implies meaning, people.  Period.

Note that ANTLR semantic predicates can resolve grammar ambiguities  
by using a boolean expression at run time to resolve things depending  
on context (i.e., what's in the symbol table).  I am using Ruby as an  
example ambig language for use in an academic paper to show off the  
predicates. ;)

Terence ("antlr project lead and supreme dictator")

From mental at rydia.net  Wed Mar  1 14:41:06 2006
From: mental at rydia.net (mental@rydia.net)
Date: Wed, 01 Mar 2006 14:41:06 -0500
Subject: [grammarians] Subclassing Struct.new
In-Reply-To: <46CFBC2B-191C-4BF7-BAEA-D42A1C1AFC7F@cs.usfca.edu>
References: <1141238425.4405ea99c1eab@www.rydia.net>
	<46CFBC2B-191C-4BF7-BAEA-D42A1C1AFC7F@cs.usfca.edu>
Message-ID: <1141242066.4405f8d2369f0@www.rydia.net>

Quoting Terence Parr <parrt at cs.usfca.edu>:

> Let me second the idea that whitespace should not change the
> meaning of a construct...bad enough that it's context-sensitive
> (and lexically not via flow analysis) so that foo can be a
> function call or var ref.  ick.

I don't agree about whitespace in this case -- I think it's fine
that foo[1] and foo [1] parse differently to one another given that
Ruby otherwise uses whitespace to signal the start of an argument
list (and that too I think fine).

However, the context-sensitivity is a problem.  Speaking of context,
I neglected to include some when I CCed the grammarians list.

What Matz is proposing for Ruby2.0 is that the criteria for a name
being treated as local variable would change from "assignment
appearing anywhere prior to the point in question" to "assignment
appearing anywhere within the same method/scope/etc".

So, rather than:

 def foo
   n # method
 end

 def hoge
   n # method
   n = 1
   n # variable
 end

We get:

 def foo
   n # method
 end

 def hoge
   n # variable
   n = 1
   n # variable
 end

I think that's a good idea -- at least, it would be if there weren't
ambiguities in the grammar that would consequently require multiple
passes or backpatching the AST to resolve.

So, just for to-day, I am putting on my prescriptivist hat.  We'll
have to defer to Matz's ultimate decision, but I hope I can
persuade him to address the ambiguities for 2.0.

-mental

From mental at rydia.net  Tue Mar 14 17:54:15 2006
From: mental at rydia.net (mental at rydia.net)
Date: Tue, 14 Mar 2006 17:54:15 -0500
Subject: [grammarians] Alternate notation for eigenclass
In-Reply-To: <3C8F4B11-D4ED-4980-9F32-3FC2694F173A@sbcglobal.net>
References: <1142271331.275572.249870@u72g2000cwu.googlegroups.com>
	<B684B586-FBE4-4F6F-93CA-C69CAE93E616@mac.com>
	<Pine.LNX.4.64.0603140738190.27104@wobblini.net>
	<3C8F4B11-D4ED-4980-9F32-3FC2694F173A@sbcglobal.net>
Message-ID: <1142376855.441749978d8af@www.rydia.net>

Quoting Gary Wright <wright_gary_r at sbcglobal.net>:

> And as I said earlier, Ruby is quite happy to have an expression
> as the superclass such as:
>
> 	class ProxyArray < DelgateClass(Array)
> 	end
>
> I would think that
>
>        class expression
>           #code
>        end
>
> [should] be analogous to
>
>        expression.class_eval { # code }

The above example illustrates exactly why general expressions aren't
allowed as the "operand" for the class keyword.  There'd be an
ambiguity around:

 class SomeConstant < some_expression
 end

...is SomeConstant the name of a new class to define, and the result
of some_expression its superclass?

...or is SomeConstant an object on which to call #<, and the result
of some_expression the argument to the call?

You can't simultanously have a special syntax for class declaration,
and still allow general expressions, without writing a really
tortured grammar and deeply confusing people in the process.

matz wisely opted to stick with just one -- the former -- which is
the standard notation for class declarations we use every day.

-mental

From gwtmp01 at mac.com  Tue Mar 14 18:27:05 2006
From: gwtmp01 at mac.com (gwtmp01 at mac.com)
Date: Tue, 14 Mar 2006 18:27:05 -0500
Subject: [grammarians] Alternate notation for eigenclass
In-Reply-To: <1142376855.441749978d8af@www.rydia.net>
References: <1142271331.275572.249870@u72g2000cwu.googlegroups.com>
	<B684B586-FBE4-4F6F-93CA-C69CAE93E616@mac.com>
	<Pine.LNX.4.64.0603140738190.27104@wobblini.net>
	<3C8F4B11-D4ED-4980-9F32-3FC2694F173A@sbcglobal.net>
	<1142376855.441749978d8af@www.rydia.net>
Message-ID: <96E31188-3912-4B55-92CF-4FEDF170292B@mac.com>


On Mar 14, 2006, at 5:54 PM, mental at rydia.net wrote:
> The above example illustrates exactly why general expressions aren't
> allowed as the "operand" for the class keyword.  There'd be an
> ambiguity around:
>
>  class SomeConstant < some_expression
>  end

Ah!  Yes.  That funny thing over my head is a light bulb.
Thanks for pointing out that which is now entirely obvious.

I wonder what syntax a language designer would come up with if
they weren't limited to ASCII punctuation.  Sometimes I think we
overload the limited punctuation in ASCII beyond its carrying capacity.


Gary Wright

From mental at rydia.net  Wed Mar 15 13:08:09 2006
From: mental at rydia.net (mental at rydia.net)
Date: Wed, 15 Mar 2006 13:08:09 -0500
Subject: [grammarians] Alternate notation for eigenclass
In-Reply-To: <1142384850.893716.161220@i40g2000cwc.googlegroups.com>
References: <1142271331.275572.249870@u72g2000cwu.googlegroups.com>
	<B684B586-FBE4-4F6F-93CA-C69CAE93E616@mac.com>
	<Pine.LNX.4.64.0603140738190.27104@wobblini.net>
	<3C8F4B11-D4ED-4980-9F32-3FC2694F173A@sbcglobal.net>
	<1142376855.441749978d8af@www.rydia.net>
	<1142384850.893716.161220@i40g2000cwc.googlegroups.com>
Message-ID: <1142446089.441858095e003@www.rydia.net>

Quoting Trans <transfire at gmail.com>:

> That's a good point. But we should be clear. First, this is only
> ambiguious for constants. Moreover, the above is equivalent to
> redefining the value of the constant. I.e.
>
>   SomeConstant = Class.new(some_expression)
>
> So it would not matter anyway --in other words, using a
> superclass is pointless when reopening a pre-existent class, so
> this statement must be defining a class called SomeConstant.
> There's really no ambiguity.

Only because you have an a priori idea of what makes sense.

It's easy to insist that a parser should "do what you mean", but try
explaining that to a pushdown automaton...

Try writing some BNF for this part of Ruby's syntax, with your
proposed change.  Then you'll understand.

-mental

From mfp at acm.org  Sat Mar 18 11:23:00 2006
From: mfp at acm.org (Mauricio Fernandez)
Date: Sat, 18 Mar 2006 17:23:00 +0100
Subject: [grammarians] [Re: Unexplored corners of Ruby's syntax]
Message-ID: <20060318162300.GE19503@tux-chan>

----- Forwarded message from Florian Gross <addr elided> -----

From: Florian Gross <addr elided>
Date: Thu, 09 Mar 2006 02:06:40 +0100
To: mfp at acm.org
Subject: Re: Unexplored corners of Ruby's syntax

Moin.

Just stumbled upon this one:

p "#{(<<'"').reverse}
hello world
"
hello world
"
^Z
"\ndlrow olleh\nhello world\n"

It confuses IRB pretty badly. :)

Regards,
Florian Gross

----- End forwarded message -----

-- 
Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby