RE: another take on hackers and painters

["Todd Proebsting" <address@hidden>]

Ages ago when I wrote an Icon compiler, I wondered about automatic
conversions for append, and I came to the conclusion that it would
be more confusing than helpful because I could come up with more
than one reasonable interpretation for the following expression.
   "abc" ||| []

On the one hand, there's the interpretation that you propose,
which would be
   "abc" ||| []  => ["abc"] ||| []          => ["abc"]

The problem is that I think it is reasonable to convert a
string to a list of characters, which would give us
   "abc" ||| []  => ["a", "b", "c"] ||| []  => ["a", "b", "c"]

(Now, this is a little odd since there are no characters in Icon, but
it is still reasonable to think of a string as a list of single
characters.)

Further, Icon blurs the line between records and lists by allowing
one to index a record by position.  Does this mean that Icon should
have a conversion from a record to a list?

Because of these confusions, I'm not convinced it is "a pity" that there
is no automatic conversion to a list from anything.  It's a judgment
call.

Todd

-----Original Message-----
From: Jasvir Nagra [mailto:jas@cs.arizona.edu] 
Sent: Wednesday, May 21, 2003 4:02 PM
To: Todd Proebsting
Cc: ll1-discuss@ai.mit.edu
Subject: Re: another take on hackers and painters



Icon certainly does a very nice job.  The tension between overloading
and implicit conversion is introduced by the language trying to
balance DWIM and error checking.  Whereas some people may insist that
a program should never try to deduce "intent" others may happily give
that up for more succinct syntax.

In the case of Icon (as in the case of perl, I might add), having
different operators for addition and concatenation means that the
program can make good assumptions about what the programmer intended
to do.  Ditto introducing a new operator for list appends.  Using ||
to do list append would mean that its difficult to deduce whether by

"alpha" || ["beta"]

the programmer meant to get ["alpha","beta"] or "alphabeta" (that is
string to list then append or convert list to string and concatenate).
Its a pity that icon, having paid the expense of introducing a new
operator "|||" did not go ahead and reap its benefits.  Namely,

1 ||| [2,3,4] and ["hello"] ||| "world" 

should do the right thing and implicitly convert the scalars to lists
before appending the lists because ||| is a list operator.  It does
these conversions for + and || afterall.

"Todd Proebsting" <toddpro@microsoft.com> writes:

> 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
>
>
>

-- 
Jasvir Nagra
http://www.cs.auckland.ac.nz/~jas