Deposing Dictators

[Donn Cave]

Quoth Steve Horne <sh at ttsoftware.co.uk>:
...
| I've been thinking very hard about this. Forking Python would be a
| very damaging thing. It isn't a way of enhancing Pythons usefulness in
| the way that other variants of Python have been. It would, IMO, be an
| abuse of the open source principles. Using the openly available Python
| source to create mutually incompatible variants of the language would
| be just as bad as Microsofts attempts to 'enhance' Java.

I agree.  I think Python follows the C language it's implemented in
on division - (Python / 2) -> 0, at least until there's a much larger
base or a more clearly defined constituency for two C variants.
Either might appear in the course of time.  Folks who feel pinched
here have a while, maybe years, to work this out.  Like with any
computer technology, it makes sense to re-evaluate once in a while,
and look at the alternatives.  I think there's too much interesting
stuff out there, for a stunted clone of Python to be worth the trouble.

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

	Donn Cave, donn at u.washington.edu

| 2.  Those ideas I do have for a scripting language would describe
| something superficially similar to Python, but substantially
| different. The reason being that I have realised that datatypes in all
| current languages are attempting to represent two distinct concepts
| with one language construct.
|
| Someone once defined a type to me as a set of values and the
| operations that can be performed on those values. AFAICR, it was in
| relation to Z and formal methods.
|
| This definition of type is quite distinct from the representation.
|
| On this basis, you could define types like 'number', 'integer',
| 'real', 'approximate_real' - and yet allow that within the each type
| the language is free to change representations (and in some cases may
| be forced to change representations) in order to best handle the data.
|
| In other words, it would be quite reasonable to have strong static
| typing and yet still have dynamic representation of values.
|
| To be practical, literals would have to have sensible default types -
| the most general type possible for the given value and there would
| need to be a rule that allowed more general types to be implicitly
| cast into more specialist types (the reverse of what generally happens
| with representations) with errors raised if the value is not supported
| by the target type.
|
| In blocks of code that would otherwise require excessive casting, it
| should be possible to override the default type for literals.
|
| For example, the following code...
|
|   assume real :
|     a = 5/2
|
| Would result in the values '5' and '2' being classified initially with
| the 'real' type. They would be represented as ints, but (and you have
| no idea how hard it is to say this ;-) division would change
| representations (maybe to float, maybe to rational etc) and return the
| value two-and-a-half.
|
| However, in the following code...
|
|   assume integer :
|     a = 5/2
|
| The 5 and 2 would have 'integer' type and representation 'int'. When
| the division operator is evaluated, changing to float or rational
| representations would be illegal.
|
|
| Depending on your religion, there are a few ways this could work. I
| would favour division being considered ambiguous and therefore illegal
| with 'number' type, and otherwise working as per current Python
| division (but with respect to type, not representation).
|
| Therefore...
|
|   print 5/2  #  error - don't know whether to use integer or real
|              #  arithmetic
|
|   assume integer :
|     print 5/2   #  result 2
|
|   assume real :
|     print 5/2   #  result 2.5
|
| In the two-division-operators religion, // would be defined for all
| specialisations of number but / would only be defined for
| specialisations of real. / would work for two number arguments, but
| only due to implicit casting to real - the result would therefore be
| considered real as well.
|
| Thus...
|
|   a = 5/2   #  5 and 2 both number, but must cast to real for /
|             #  value assigned to a therefore has type real
|
|   b = a * integer (2)  # error - attempt to mix integer and real
|                        # arithmetic
|
|   c = 5//2  # result is 2 - type is number as no need to specialise
|             # further at present, even though representation is
|             # certainly int.
|
|
| How this would affect performance is unclear. In general, having a
| known type would restrict the number of representations to be
| considered. Functions that restrict the types that they are valid for
| would probably be significantly faster than those that allowed their
| arguments to default to the anything type, but they would also trigger
| some kind of check on call which might easily wipe out that gain if it
| happened in inner loops.
|
|
|
| This strikes me as a worthwhile experiment, but one that still needs a
| lot of thought and also one which has a big chance of turning out
| impractical.