Deposing Dictators

[Steve Horne]

On Wed, 25 Jul 2001 14:05:34 +0000 (UTC),
<margg at ux-ma160-18.csv.warwick.ac.uk> wrote:

>systems. However, we may be getting to the stage now where the task of
>guiding Python should be taken out of his hands.

Despite my initial overreaction (yes, I admit it) and my ongoing
concerns, I don't think this is realistic.

>The next features of Python will see several types of changes, which
>seem to been implmented and accepted into the language without 
>discussion.

This definitely isn't realistic. Generators may not have been a major
topic for the masses, for instance, but that doesn't mean the subject
wasn't raised and discussed several times in the past.

Division has been discussed in the past, but when you don't believe
such a basic language feature would ever be changed anyway such
discussions aren't interesting.

>2) The level of dissent required to change the opinion of the BDFL
>perhaps calls into question the 'B'.  

IMO, the 'B' is not in question.

There is a clear split in opinion, and if you take the Pro-PEP0238
view then there is some merit in claiming that the short term pain is
justified by the long term greater good. I believe this opinion is
wrong, but I don't believe it is motivated by anything but the best
intentions.

>If there are enough people who feel as I do, then perhaps we will be
>able to depose the dictatorship, and create a stable and sensible 
>system for developing Python (not Python++). If this means forking 
>Python, then that will be done.

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.

Of course Guido is the person who is arguably creating the
incompatible side of the fork, but with luck Python will recover from
that given time.


I've had ideas for a new language for some time, and the events of the
last few days have given me the reason I needed to start taking it
more seriously. Having considered these ideas a little, I have come to
some conclusions...

1.  A lot of the ideas turn out not to be for a programming language
as such at all. Rather, it combines the ideas of literate programming
with a kind of replacement for make. An XML notation would allow
source code in a range of languages to be packaged in a linked set of
XML files with documentation, detailed specification of the build
process and explicit requirements for the run-time and build-time
environment. It would allow you to specify, for instance, that the
source code for this C++ module contains a constant structure derived
according to xxx principles (for the documentation) and can be
generated by running yyy script in zzz version of Python (or
whatever).

Definitely a case of going off at a tangent!

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.

-- 
Steve Horne
Home : steve at lurking.demon.co.uk
Work : sh at ttsoftware.co.uk