--nextPart8074212.RB4l7iZRBx
Content-Type: text/plain;
  charsettf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 30 March 2005 07:55, David A. Black wrote:
> I find the visual reliance on the : separator as an indicator of
> constructor behavior obscure and fragile.  But also, in more practical

Ok.

> terms, I wonder what would happen to something like:
>
>     a = SomeClass.new
>     b = 100
>
>     { a => "apple", b => "orange" }
>
> It couldn't be [a:'apple', b:'orange'], of course.  I think that means

Why not?  ':' as a prefix to denote symbols works just fine.  Using it for 
hashes would result in:

	[ a : 'apple', b : 'orange' ]
	[ a: 'apple', b: 'orange' ]
	[ 'a': 'apple', 'b': 'orange' ]
	[ a:apple, b:orange ]

'a:apple' is not a legal token in Ruby, so it could *only* be parsed as a hash 
key/value pair.  However, then we get into issues of whether the key/values 
are parsed as strings or variables, so if I were in charge, the syntax would 
be:

	[ 'key' : 'value', 'key2' : 'value2' ]

with or without the space before the ':'.

I also sort of like the re-use of [] here, and reserving {} for lambda 
expressions.  This sort of un-perlifies Ruby, where you have different 
enclosing and prefix tokens for every different kind of variable.

> there would have to be another literal hash constructor for hashes
> whose keys were not symbols, or some other workaround or special-case
> (which it actually isn't) expression.

Heh.  As strange-looking as this is, I still believe that there is only one 
way to parse the each of the following (given the syntax we're discussing):

	[ :key::value ]
	[ 'key'::value ]
	[ 'key'::'value']
	[ 'key' : :value ]
	[ :key : :value ]

> All of this just seems like so much upheaval to avoid the
> (comparatively unusual [compared to hash literals, that is]) keyword
> 'lambda'.

This isn't about not using the 'lambda' keyword, although that may have been 
the genesis of the proposal.  We can still do away with the 'lambda' keyword 
without changing hashes, as originally proposed with:

	func = {|| x = 1 }

The 'lambda' keyword *is* tedious, if you use higher-order functions a lot.20
But, personally, I like the proposed change to hash syntax; I feel it is more 
orthoganal, easy to remember (albeit mildly), and easier to type than the 
current syntax.

Furthermore, a language shouldn't be afraid to change.  If we're afraid to 
improve Ruby, someone will do to Ruby what Ruby has done to Perl.

Incidently, I say 'we', although 'we' have absolutely no say in the matter.20
We can discuss until we're blue in the face, but if Matz doesn't like the 
syntax, it'll never see the light of day.  IME, I think you're pretty safe; 
doubt the syntax for Hash will be changed.

-- 
--- SER

"As democracy is perfected, the office of president represents, 
more and more closely, the inner soul of the people.  On some 
great and glorious day the plain folks of the land will reach 
their heart's desire at last and the White House will be adorned 
by a downright moron."        -  H.L. Mencken (1880 - 1956)

--nextPart8074212.RB4l7iZRBx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1-ecc0.1.6 (GNU/Linux)

iD8DBQBCS5v4P0KxygnleI8RAlVoAJ9mj2RfYFkTiGrnTuxiRyIJ9wGyZQCggEBa
YwvtHMaL/9kMy+8Ewf6QS240cC
-----END PGP SIGNATURE-----

--nextPart8074212.RB4l7iZRBx--