Hi Chris,

just my opinion here.

Indeed the proposed code could be useful for developers. Some thing that
I think is important is that when something is in the core image, it is
an endorsement for use it. So, this change even isn't really a syntax
change of smalltalk, in practice it is. Is some new syntax to write
arrays. This gives the promise that can be used everywhere without
adverse effects (like the ones others have highlighted), with uniformity
in its usage and generally a good practice in smalltalk.
Now this is not portable, because it will be only in Squeak, so if code
begin to use it it will contain unportable code that will need to be
changed, effectively reverting to a portable syntax and in fact putting
aside your concatenation code.
Also, you said that is for end users, and I think that you said
non-developer users, but if that is the case, then why don't add this as
part of the application are using, so that takes the input of the user
and transform it to the underlying, portable, historical syntax, all
transparent to the user. 
Now, if they are programming, then I think that they must now the real
syntax and that they are using a facility provided by its application
and not by the language.

Summary, I think that this belongs to a specific application code and
not to the Squeak code base.

Just my opinion.

Cheers


El jue, 23-09-2010 a las 14:07 -0500, Chris Muller escribió:
> > In Smalltalk context maybe it's different, I understand 'abc' , 33 very well.
> >
> > The problem is about common sense expectations / least surprising results.
> > For example, currently
> >   'abc' , $d -> 'abcd'
> > What would you decently expect from:
> >   $a , 'bcd' -> ?
> > Chris, ask your end users if they really understand why concatenating
> > a Character with a String should really answer an Array...
> 
> $a , 'bcd' is no different than what they should decently expect from:
> 
>   { $a }, 'bcd'
> 
> Any guesses?  It's the same answer.  It's consistent, and not just in
> the answer but in the way it is equally "non-obvious".  But I know you
> aren't going to protest concatenation of an Array of Characters with a
> String on those grounds.
> 
> These sorts of questions are irrelevant for the real-world scenario
> anyway.  You all are critiquing on the wrong criteria.  You are
> looking for some obscure way to mix a String, what we all know to be a
> special kind of Collection with special behaviors, with another kind
> of objects in order to "look for something non-obvious".  C'mon now...
> 
> The fact is that heterogeneous collections are a rarity in real-world
> applications, but this is even a subset of those cases!  e.g., this is
> some hypothetical heterogeneous collection of Strings, Objects,
> Characters that was "accidently" created by some junior programmer,
> because he used concatenation and it gave results he didn't expect
> (but should have), and he didn't test it and so planes fell out of the
> sky.  Ohhh, the humanity of it!"  :-)
> 
> I guess I'm feeling frustrated by having to fight so hard against all
> of these fake "problems" for a enhancement has absolutely _no bearing_
> on any of your lives, but tangibly important for my application and
> users.  It's just a simple way for them to express a list of objects
> in a natural way that can be directly interpreted.  Nothing more.
> 
> I think you all should let me have this.  If you don't use it, it
> can't affect you.  We haven't run across a regression in the five
> years we've had this in our images, but if we do, I'll certainly fix
> it....
> 
> 
> 
> > OK, OK, we might implement Character>>#, with a proper rule...
> >
> > But then, where to stop ?
> > Following example was already used:
> >   #( 'one'  'two' ) , 'three'.
> >   'three' , #( 'two' 'one' ).
> > Probably none of the above will be of any use to, nor expected by any end user.
> > So the end user argument does not hold to my sense, except if , is
> > used in a restricted area, but then why implement it in Object ?
> >
> > I also can understand the result of a message send is different
> > according to the receiver.
> > However using athe #difference: operator is a tricky argument :
> > concatenation is more akin to sum / union isn't it?.
> > Although not symetrical, I could decently expect it to be transitive. Like:
> >   self assert: (('abc' , $d ) , $e) = ('abc' , ($d , $e))
> >
> > Plus some packages will insist on overriding #, to create a matrix, a
> > Float array, or something...
> >
> > Plus the efficiency problem already stated (multiple copies).
> >
> > All in all, I find the (a,b,c) notation very bright, seducing and
> > elegant, but also very deceiptive... It does not hold its promises.
> >
> >
> > Nicolas
> >
> >> From my view brace syntax is slightly advantageous for complex constructs
> >> since it avoids additional parenthesis and can be indented properly as in:
> >>
> >>        self doWithArgs: {
> >>                self methodFoo: 42.
> >>                17 sqrt.
> >>                'Hello', 'World'.
> >>        }
> >>
> >> vs.
> >>
> >>        self doWithArgs: (self methodFoo: 42), 17 sqrt, ('Hello', 'World')
> >>
> >> But then again I really don't feel strongly about it.
> >>
> >> Cheers,
> >>  - Andreas
> >>
> >>
> >
> >
> 

-- 
Miguel Cobá
http://miguel.leugim.com.mx