From: "Sean E. Russell" <ser@...>
Date: 2005-03-31T20:44:47+09:00
Subject: Re: New block syntax

--nextPart8074212.RB4l7iZRBx
Content-Type: text/plain;
  charset="utf-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 =3D SomeClass.new
>     b =3D 100
>
>     { a =3D> "apple", b =3D> "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=
=20
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 h=
ash=20
key/value pair.  However, then we get into issues of whether the key/values=
=20
are parsed as strings or variables, so if I were in charge, the syntax woul=
d=20
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=20
expressions.  This sort of un-perlifies Ruby, where you have different=20
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=
=20
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 bee=
n=20
the genesis of the proposal.  We can still do away with the 'lambda' keywor=
d=20
without changing hashes, as originally proposed with:

	func =3D {|| x =3D 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 mo=
re=20
orthoganal, easy to remember (albeit mildly), and easier to type than the=20
current syntax.

=46urthermore, a language shouldn't be afraid to change.  If we're afraid t=
o=20
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=20
syntax, it'll never see the light of day.  IME, I think you're pretty safe;=
 I=20
doubt the syntax for Hash will be changed.

=2D-=20
=2D-- SER

"As democracy is perfected, the office of president represents,=20
more and more closely, the inner soul of the people.  On some=20
great and glorious day the plain folks of the land will reach=20
their heart's desire at last and the White House will be adorned=20
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+8Ewf6QS24=
=3qcC
-----END PGP SIGNATURE-----

--nextPart8074212.RB4l7iZRBx--