"sins" (aka, acknowledged language problems)

[skaller]

Alex Martelli wrote:

> > Ok. You have set me a problem here.
> > I need more cases to examine!
> 
> Please see my answer to Neel Krishnaswami --
> I think I've come upon a good solution to the
> dilemma -- a simple wrapper class (small set
> of wrapper classes, actually) that will let me
> use elegant "for/in" syntax in these cases,
> without (I think/hope) substantial overhead.
> Tim's responses were of course precious in
> getting me to think along the right lines.

	It's very often possible to 'solve' this
kind of problem with wrapper classes -- but it isn't
always good programming style.

	Firstly, it requires writing the class
non-locally, to solve a localised problem.
Secondly, the reader has to find the class,
and try to understand it, and remember its name.
I think people remember patterns (idioms) better than names.

	If the class is 'general purpose'
enough, it is common to make a utilities
module. But somehow, this doesn't work well:
everyone has their own private 'utilities'.

	The 'classic' bungle (well, I did it :-)
was to #define BEGIN and END (a'la modula) and use
them in C: it makes the code unreadable -- except
to a Modula programmer :-)

	I think my point is, it seems to be better
to write out the long winded code each time
than wrap it up, unless it has significant application
related functionality, or is somehow 'standardised':
made part of the core language, or be a part of a
very popular toolkit. E.g I might forgive someone
for using mxTools.

	[Please note these truly are vague, personal
impressions]
 
> (Despite which, I'd still like to see this wrapper
> idea [a] either shot to pieces because of some
> subtle problem I can't see, or [b] made more
> available as a 'standard' idiom, perhaps in an
> example or tutorial).

	Yeah -- even if it works, you get an uneasy 
feeling that it make the code a bit harder to read?

> I have introduced ONE entirely
> > new statement into Viper (my version of Python):
> >
> > with: ...
> > do: ...
> >
> > in which the variables introduced in the with part
> > are available in the do part, and then forgotten.
> > This adds to the lexical scoping Viper provides,
> > to correct Python's lousy scope control.
> 
> Now that sounds extremely interesting.  Python's
> scopes are extremely simple, but perhaps this IS
> too simple, as you claim.

	Python's scopes are NOT simple.
The idea that 'exactly two scopes' is simpler
that 'stack of scopes' is a misconception,
and it doesn't even work in Python: 
there are at least two places where it fails:
(a) the __builtins__ hack, to make builtin
functions available, and (b) in except clauses,
to make the exception available.

	On the other hand, starting from some
weird hackery, I have eventually evolved an implementation
in Viper of a thing called an 'environment' which is
represented internally by an abstraction supporting
get, set and del methods for variables. At present,
I use six or seven distinct instances of environments
in various contexts:

	a) module environment (for defining modules)
	b) class environment (for defining classes)
	c) function environment (for executing function bodies)
	d) exception handler environment (for exception handlers)
	e) with/do environment (for the with/do statement)
	f) python globals/locals environment 
		(for compatibility in 'exec' et al)
	g) null environment (bottom of an environment chain)
	h) stacked environment (used during imports??)

and the increasingly clean implementation tends to suggest
this concept actually works better in python than 'two scopes'.
It was, of course, necessary to do something like this in
Viper to support lexical scoping.

> What are the drawbacks of supplying the needed
> wrappers, rather than adding new syntax...?

	For a start, efficiency. And, as above,
readability.
 
> > But 'break'
> > in python isn't labelled, and there is no goto,
> > so you end up having to use exceptions ... Uggghhhh.
> 
> Labeled breaks might well be a good idea, I guess.

	I'm not sure. I also have no candidate syntax
for defining the labels. Labelled breaks give me
an uneasy feeling.
 
> > Of course, most functional languages provide coherent
> > and very concise ways of doing this kind of thing.
> > So it is fairly well known WHAT is required, just not
> > what syntax to use in a 'pythonic' version. :-)
> 
> What about the "for x in y" syntax -- that seems neat
> to me, as long as we can supply the y appropriately:-).

	Quite a lot of the time, you CAN provide the y:
using functional programming with map and reduce etc.
This works well in functional programming languages,
but it doesn't work nearly as well in python.
What I mean  is, the 'y' becomes so cluttered the reader
isn't sure what is happening.

	for example, to loop thru two lists I can write:

	for x,y in zip(l1, l2): ..

which is something like:

	for x,y in map(None, l1, l2):

although I can never figure map(None, ..) out.
But somehow, this is wrapping the structure TOO much.
Guido noted something like

	for x in l1; for y in l2:

at the last conference, which is a bit ugly,
but it _exhibits_ the intended structure better
than functional wrapping: here I can see a
pattern, rather than remember a name.

-- 
John 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