Deposing Dictators

[Stephen Horne]

On 27 Jul 2001 17:48:30 GMT, Donn Cave <donn at u.washington.edu> wrote:

>I'm going to bottom quote the rest because it's so long and my comment
>is so brief and tangential - I see you have some interesting ideas about
>numbers, and I'm ignoring them!  Have you ever played around with a
>language that's typed the way functional languages seem to all do it?
>I have been looking at OCaml.  It's quite rigid about types, but you
>don't have to specify them all the time like you would in C - or like
>you're proposing to do with "assume".  Instead it only insists that it
>be able to follow the data around through the program logic, on the
>assumption that will lead to a context where the type can be inferred,
>from a literal or an output specifier or a type-limited operation.
>I can't say OCaml does it right, for all I know you could get all the
>real mileage out of the idea in a less cumbersome way if you didn't
>have the provability baggage that the FPL world carries, but anyway
>type inference has been around for a while and I guess may be "well
>understood".  At least better understood than I understand it!
>(Say, anyone heard from Max Skaller?)

I've used a number of functional languages, but not really for
anything more than newbie exercises. Many of the principles are IMO
highly beneficial, but I miss my imperative stuff when too much when
it is taken away ;-)

To be honest, the only time I took a functional language seriously to
any real degree it was Miranda - and that was about 8 years ago now.
It was a required part of the college course I took. The syntax
annoyed me a little (like (I assume) most people I find expressions in
infix notation most natural, though I have used postfix in Forth and,
as I say, prefix in Miranda) but what really annoyed me was that we
stopped short of what I though of as the meat of the language - coping
with the apparent need for 'state' in a state-free language.

But the point is, I don't really recall how numbers were handled or
what kind of typing schemes were used. And I haven't used OCaml, or ML
or any derivative to my knowledge. I kind of assumed they weren't much
different to Python dynamic types, but it seems like I was wrong.

Anyway, type inference doesn't sound quite like what I want. I don't
want the language to assume, just because I wrote 0.1, that that is an
approximate float value. As much as possible, I don't want the
language second guessing the programmer. I think the programmer should
be explicit about types - it's just that in a very high level
language, that shouldn't necessarily mean being explicit about the
representation.

The trouble is, I'm not quite sure what is a logical way for the types
to interelate.

I'm afraid I'm going to have to ramble a bit...



ATM, I see types in a heirarchy similar to...

----------------------------------------------------------------------
Types                      Representations
-----                      ---------------

anything                   *
- number                   { int, longint, rational, fixed() }
  - integer                { int, longint }
  - fast integer           { int }
  - real                   { int, longint, rational, fixed() }
    - approx real          { int, longint, rational, fixed(), float }
- string                   { ASCII, ANSI????, UTF16 }
  - 8bit string            { ASCII, ANSI???? }
- list
- dictionary
- ...
----------------------------------------------------------------------

Integer should specifically mean C-like-integer (ie not a
specialisation of real or approx real) and should therefore allow
bitwise operations and such not supported for other numeric types.

Fast integer is not a specialisation of integer because it's operators
would be allowed to overflow or underflow without raising an
exception, thus the same operation on the same arguments might give a
different result, thus it is different in ways other than reducing the
legal set of values and increasing the legal set of operations.
Changing the behaviour of existing operations based on specialisation
of the type should be illegal.

Approximate reals are a specialisation of reals so that exact results
can be implicitly specialised into approximate ones when used in
inherently approximate calculations, but approximate results are never
implicitly converted to the general (assumed exact) real type. That
said, there are issues with allowing new representations in
specialisations, so I'm thinking hard. Maybe floats should be allowed
as a representation for real, number etc, but the operations on those
types should just ban using (approximate) float arithmetic, convering
to rational or whatever the need arises.

Typing of arguments to functions would be static, but the 'anything'
type would always be the default if nothing else was specified.
Therefore...

  def Sum (a, b) :
    return a + b

...would do what Python does now, but...

  def Sum (number a, number b) number :
    return a + b

...would refuse to work as an append for lists or strings, and...

  def Sum (integer a, integer b) integer :
    return a + b

...would only be allowed to work on integers, and...

  def Sum (fast_integer a, fast_integer b) fast_integer :
    return a + b

...should be significantly faster - the price being less insulation
from the limitations of C integer arithmetic.

Supporting this kind of logic efficiently could be difficult, though.
Basically, I suspect that whereas the Python interpreter probably uses
a single C type to represent any value (with a datatype specifier
field, a union for the specific type, etc - I haven't checked yet
though) this would probably mean having several such C types - the
particular one to use being chosen by the bytecode compiler based on
context (explicitly declared argument and literal types, and
typecasts). General types would still need to support more specialised
types being attached to particular values, though - eg a function with
real parameters would need to know about approx_real arguments in
order to handle float representations, and determining the type of
global variables would be impractical.

Hmmm...

Time to sleep on it a bit...