RE: another take on hackers and painters

["Todd Proebsting" <address@hidden>]

The Icon programming language got this right.  The + operator is for
numerical addition, and the || operator is for string catenation.  With
this, all the implicit conversions do what you'd expect:
  1  +  2    => 3
  1  +  "2"  => 3
  "1"+  2    => 3
  "1"+  "2"  => 3
  1  || 2    => "12"
  1  || "2"  => "12"
  "1"|| 2    => "12"
  "1"|| "2"  => "12"

It's not a type problem, but an overloading-meets-conversions problem.
I happily give up overloading for implicit conversions.

(And, the ||| operator is for list append.  All three are associative.)

Todd

-----Original Message-----
From: owner-ll1-discuss@ai.mit.edu [mailto:owner-ll1-discuss@ai.mit.edu]
On Behalf Of Guy Steele - Sun Microsystems Labs
Sent: Wednesday, May 21, 2003 12:02 PM
To: Jerry.Jackson@sun.com
Cc: ll1-discuss@ai.mit.edu
Subject: Re: another take on hackers and painters



   Date: Wed, 21 May 2003 09:48:11 -0600
   From: Jerry Jackson <Jerry.Jackson@Sun.COM>
   CC: ll1-discuss@ai.mit.edu
   Subject: Re: another take on hackers and painters
   
   
   
   Matt Hellige wrote:
   
   > [Dan Sugalski <dan@sidhe.org>]
   > 
   >>At 5:00 PM -0400 5/20/03, John Clements wrote:
   >>
   >>>...
   >>>
   >>>Depends what you mean by "a type problem."  If I'm adding a number

   >>>and a string, that's definitely a "type problem,"
   >>>
   >>Is it? What's wrong with 1 + "3" producing 4?
   >>
   > 
   > Wow... That just makes me cringe... And sets off my "perl
proximity"
   > alarm. By the same token, why not have 1 + "3" produce the string
"13"?
   > 
   
   Heh, heh.  That's what Java does... :-)
   
With the unfortunate consequence, I might add, that
the "+" operator fails to be associative:

   ("foo" + 1) + 3   =>   "foo13"
   "foo" + (1 + 3)   =>   "foo4"

--Guy