"sins" (aka, acknowledged language problems)

[skaller]

Alex Martelli wrote:

>     class enum:

> > So the hypothetical xreadlines() method should return an object
> > that reads one additional line from the file each time it is called.
> 
> Right; but it need not be hypothetical, see above.

	One problem with this approach is that it based around
a generic calling protocol -- which is as slow as a wet week in Python.
For example, I have extended the for statement in Viper, to accept
dictionaries and sets. It is very inconvenient to get the i'th, or
even the next, element from a set: I have a natural way to apply
a function to each element.

	As a result, Viper loops are one of the things that Viper
currently does faster than CPython -- the iteration time
is effectively zero, and that is what pystone reported on my machine.
 
> > The general problem that needs fixing is that Python really needs a
> > better iteration protocol.

> The iteration protocol implemented above seems good enough
> to me -- even though I was the one first expressing concern on
> this thread.

	I think wrappers have limited application for modelling
fundamentals. One needs to get the fundamental right, just to write
the wrappers. It's possible to write:

	for i in range(0, len(x)):

but is sucks badly. Consider instead that [1:10] is just
a notation for [1,2,3,...9], and that

	s1 s2

is the composition of two maps: a sequence is a map 
from 0 thru n-1 to some object. This explains:

	seq[1:10] <==> seq [1,2,...9]

and the result is a sequence. This means you should
be able to write something like:

	s2 = [1:10]
	s1 = ['a','b','c'..'z']
	x = s1 s2

and this can be extended to functions, if only Python
functions always accepted exactly one argument. :-)
But this interpretation also implies:

	for i in [1:10]: ..

should work. The _change_ that is required (for sequences)
is primarily syntactic (Operator 'whitespace').

> Good point.  So, we need some *inertia* in changing a language's
> definition -- at least enough to make sure that the solution space
> possible within a given language IS well explored, before coming
> to the determination that the language needs extension.
> 
> Fortunately, we have it -- and maybe we have a deeper explanation
> for Guido's apparent stonewalling about language changes...?-)

	Guido needs to maintain a lot of compatibility.
The solution space for 'upgrading' ideas of a language 
is often constrained by the initial syntax.

	Providing class based wrapper hackery to 'hook'
existing syntax falls down badly when the initial syntax
is inadequate.

	This is the case in most languages with respect
to comparators (<, <= etc) because they're usually built
on the notion of a total order. Obviously, Guido ran out
of operators, using + to concatenate strings. The nice 
slicing notation (one of Python's strong points) is not
well generalised. Etc.

	Syntax is visual appearance: the shape of code
should indicate its overall semantics, not a bunch of named
function calls like 'enum()' or 'items()'. I mean,
who needs [1:10] for a slice:

	slice(a,1,10)

is functionally equivalent. But it looks like
an _arbitrary_ function call.

-- 
John (Max) Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850