Re: K.I.S.S. Factor (Re: Numerics)

Hi Richard,

--On 31 March, 2005 18:34:11 +1200 "Richard A. O'Keefe" <[email protected]> 
wrote:

> Dominique Colnet wrote:
>
> 	Actually, in most real situations, you would have:
> 	
> How do you know what other people would have "in most real situations"?
> Clearly, before the invention of {<type> <stuff>} notation, "in most
> (indeed, all) real situations" people couldn't possibly have the
> {<type> <stuff>} notation, and equally clearly, in ISE Eiffel they
> would be relying on conversions.
>
> Let's try to avoid misunderstandings here.
> *My* primary concern is simple numeric literals.
> *I* am arguing for a vaguely Haskell-like approach where
>
>  - every expression has a unique principal type determined by its
>    form and by the declarations of the identifiers it mentions
>
>  - this type can be determined by a single pass working from the
>    leaves towards the root
>
>  - however, that principal type will in general contain constrained
>    type variables due to integers (exact size to be determined by
>    context), floating point numbers (exact size to be determined by
>    context), characters (for characters which can only be Unicode,
>    Unicode; for characters which could be Latin-1, exact type to
>    be determined by context), strings (for strings any of whose
>    characters can only be Unicode, Unicode; for other strings, exact
>    type to be determined by context --- note that this entirely
>    eliminates the need for the painfully C-like 'U' prefix), and
>    arrays (where the choice of ARRAY, FAST_ARRAY, or NATIVE_ARRAY
>    or indeed any built-in sequence type would similarly depend on the
> context)
>
>  - the context of an expression is the variable it is assigned to or
>    the method argument it is passed to.  Such contexts cannot contain
>    type variables.  Matching the type of the context against the
>    parametric type of the expression either succeeds (in a rather mild
>    generalisation of the usual Eiffel type checking rules) or fails.
>    If it succeeds, binding type variables, the type variables are
>    checked to ensure that they satisfy their constraints.  This
>    determines the types of the literals.  (The constraints can be set
>    up so that if any literal does not fit its context-determined type,
>    this is detected by failure to satisfy the constraints.)
>
>  - this involves no conversions.
>    Conversions are a separate concern.

...snip...

> I am a little more sanguine here.  The approach I recommend is proven
> technology, efficiently implementable in a compiler, with ZERO run-time
> overheads, would not break any currently legal code, and would not
> preclude (although it would not require) supporting conversions.
> I live in hope that I might eventually be sufficiently persuasive.

How about we just implement this independent of the SE folks?  I might be 
able to find a student to work on it this summer.  This would complement my 
planned work on actually writing up the new Eiffel type system this summer. 


Would you be interested in contributing to such work?  I suspect we could 
get a few more good people interested in the coming weeks as well (right 
list members?).

This kind of work would result in an excellent paper or two and would be a 
very convincing use of principle types in Eiffel, perhaps swaying either or 
both the SE folks and the ECMA folks towards this approach.

Joe
-- 
Joseph R. Kiniry
Dept. of Computer Science, University College Dublin
http://secure.ucd.ie/