implicit conversions

[Stéphane Payrard <address@hidden>]

On Wed, May 21, 2003 at 03:52:10PM -0500, Robby Findler wrote:
> At Wed, 21 May 2003 15:44:01 -0400, Dan Sugalski wrote:
> > At 3:34 PM -0400 5/21/03, John Clements wrote:
> > >Put another way:  don't you want as much checking as you can 
> > >possibly get at acceptable cost?
> > 
> > No.
> > 
> > >and
> > >
> > >isn't having to write 'string->number' an acceptable cost?
> > 
> > No.
> > 
> > Which, I expect, will bring the discussion to something of a halt. I 
> > don't see it as a general problem. In those circumstances where it 
> > is, I use a language that doesn't do it.
> 
> Wonderful -- error checking is not a general problem. Lets just make up
> results for strange situations. Trying index outside the bounds of the
> array? No problem, just return some random bits. Trying to pop an empty
> stack? No problem, we'll just guess you probably wanted 0 (or maybe, on
> Tuesday's, for variety, we'll return the null pointer or the empty list
> or false).
> 
> In fact, lets get rid of all errors in programs. Up with the DWIM
> instruction! Down with reliability!

Automatic conversion can be good because the code is less cluttered so
more readable.  When you get a string representing a number by a
regular expression, it would be cumbersome to explicitely convert it
because this kind of conversion is all over the place.  Pragamatic
language like Perl5 manipulate files/strings all the time and convert
them effortlessly to and from datastructures.

Perl6 will both statically typed and dynamically typed, I am curious
what we will be able to do with types; I am learning the ML class of
language and I have trouble to see if this model can blend with Perl.
Perhaps this is a non objective.

May be the set of conversions allowed in a given piece of code
should some kind pragma. That would give a lot of rope.

The C++ approach which makes conversion part of type (class)
definition by using constructors as potential convertors (except if
disabled by the "explicit keyword) is certainly wicked.

There are many languages for different tasks. My hope is that we will
be able to move to more versatile languages that can behave differently
depending on the task.  I find sad that because Perl is "blue-collar"
by history, it should be considered with snide by people that are more
interested in theorem proving or whatever.


--
  stef

> 
> 
> Robby