A critic of Guido's blog on Python's lambda

[Xah Lee]

Python, Lambda, and Guido van Rossum

Xah Lee, 2006-05-05

In this post, i'd like to deconstruct one of Guido's recent blog about
lambda in Python.

In Guido's blog written in 2006-02-10 at
http://www.artima.com/weblogs/viewpo...?thread=147358

is first of all, the title “Language Design Is Not Just Solving
Puzzles�. In the outset, and in between the lines, we are told that
“I'm the supreme intellect, and I created Python�.

This seems impressive, except that the tech geekers due to their
ignorance of sociology as well as lack of analytic abilities of the
mathematician, do not know that creating a language is a act that
requires little qualifications. However, creating a language that is
used by a lot people takes considerable skill, and a big part of that
skill is salesmanship. Guido seems to have done it well and seems to
continue selling it well, where, he can put up a title of belittlement
and get away with it too.

Gaudy title aside, let's look at the content of his say. If you peruse
the 700 words, you'll find that it amounts to that Guido does not like
the suggested lambda fix due to its multi-line nature, and says that he
don't think there could possibly be any proposal he'll like. The
reason? Not much! Zen is bantered about, mathematician's impractical
ways is waved, undefinable qualities are given, human's right brain is
mentioned for support (neuroscience!) , Rube Goldberg contrivance
phraseology is thrown, and coolness of Google Inc is reminded for the
tech geekers (in juxtaposition of a big notice that Guido works
there.).

If you are serious, doesn't this writing sounds bigger than its
content? Look at the gorgeous ending: “This is also the reason why
Python will never have continuations, and even why I'm uninterested in
optimizing tail recursion. But that's for another installment.� . This
benevolent geeker is gonna give us another INSTALLMENT!

There is a computer language leader by the name of Larry Wall, who said
that “The three chief virtues of a programmer are: Laziness,
Impatience and Hubris� among quite a lot of other ingenious
outpourings. It seems to me, the more i learn about Python and its
leader, the more similarities i see.

So Guido, i understand that selling oneself is a inherent and necessary
part of being a human animal. But i think the lesser beings should be
educated enough to know that fact. So that when minions follow a
leader, they have a clear understanding of why and what.

----

Regarding the lambda in Python situation... conceivably you are right
that Python lambda is perhaps at best left as it is crippled, or even
eliminated. However, this is what i want: I want Python literatures,
and also in Wikipedia, to cease and desist stating that Python supports
functional programing. (this is not necessarily a bad publicity) And, I
want the Perl literatures to cease and desist saying they support OOP.
But that's for another installment.

----
This post is archived at:
http://xahlee.org/UnixResource_dir/w...bda_guido.html

Â* Â* Xah
Â* Â* xa*@xahlee.org
∑ http://xahlee.org/

[Duane Rettig]

Alexander Schmolck <a.********@gma il.com> writes:

Duane Rettig <du***@franz.co m> writes:

Alexander Schmolck <a.********@gma il.com> writes:

> Ken Tilton <ke*******@gmai l.com> writes:
>
>> In Common Lisp we would have:
>>
>> (defvar *x*) ;; makes it special
>> (setf *x* 1)
>> (print *x*) ;;-> 1
>> (let ((*x* 2))
>> (print *x*)) ;; -> 2
>> (print *x*) ;; -> 1
>
> You seem to think that conflating special variable binding and lexical
> variable binding is a feature and not a bug. What's your rationale?
A bug is a non-conformance to spec.

There is a world beyond specs, you know. If copies of allegro CL accidently
sent out death-threats to the US president on a weekly basis, because someone
at franz accidently or purposefully left in some pranky debugging code the
fact that this behaviour would likely neither violate the ansi spec nor any
other specs that ACL officially purports to adhere to wouldn't make it any
less of a bug (or help to pacify your customers).

It wouldn't be a bug in Allegro CL, because it would never happen in an Allegro CL
that hasn't been enhanced with some kind of program. And although that program
itself could have a bug whereby such a threat were accidental, I would tend not
to call it accidental, I would tend to call it expicit, and thus not a bug but
an intended consequence of such explicit programming.

My reason for responding to you in the first place was due to your poor use
of the often misused term "bug". You could have used many other words or
phrases to describe the situation, and I would have left any of those alone.

For example:

Kenny's statement was specifically about Common Lisp

No Kenny's statement was about contrasting the way something is done in python
and the way something is done in common lisp (with the implication that the
latter is preferable). Of course the way something is done in common lisp is
almost tautologically in closer agreement with the ansi common lisp spec than
the way it is done in python, so agreement with the clhs is not a useful
criterion when talking about design features and misfeatures when contrasting
languages.

I thought it would have been pretty obvious that I was talking about language
design features and language design misfeatures (Indeed the infamously post
hoc, "It's a feature, not a bug" I was obviously alluding too doesn't make
much sense in a world were everything is tightly specified, because in it
nothing is post-hoc).

Whether it is preferable is a matter of opinion, and whether Kenny meant it
to infer preferability (I suspect so) or not has nothing to due with whether
it is a bug. Instead, you should call it a "design misfeature", which would
set the stage for a more cogent argumentation on the point, rather than on the
hyperbole. By the way, if you do call it a design misfeature, I would be
arguing against you, but that is another conversation.

, which has a spec.

Bah -- so does fortran. But scheme also has operational semantics.

Now, what was your rationale for it _being_ a bug?

I just don't think the way special variable binding (or variable binding in
general[1]) is handled in common lisp is particularly well designed or
elegant.

Then call it "misdesigne d" or "inelegant" .
Special variables and lexical variables have different semantics and using
convention and abusing[2] the declaration mechanism to differentiate between
special and lexical variables doesn't strike me as a great idea.
Then call it a "bad idea".
I can certainly think of problems that can occur because of it (E.g. ignoring
or messing up a special declaration somewhere; setf on a non-declared variable
anyone? There are also inconsistent conventions for naming (local) special
variables within the community (I've seen %x%, *x* and x)).
Then call it "not fully standardized or normative".
Thus I don't see having to use syntactically different binding and assignment
forms for special and lexical variables as inherently inferior.
Then call it "inherently inferior".
But I might be wrong -- which is why was asking for the rationale of Kenny's
preference.
But you _didn't_ ask him what rationale he had for his _preference_, you
asked him his rationale for considering it not a _bug_.
I'd be even more interested in what you think (seriously; should
you consider it a design feature (for reasons other than backwards
compatiblity constraints), I'm pretty sure you would also give a justification
that would merrit consideration).

Well, OK, let's change the conversation away from "bug"-ness and toward any of
the other negatives we discussed above. I actually doubt that I can provide
a justification in a small space without first understanding who you are
and from what background you are coming, so let me turn it around and ask
you instead to knock down a straw-man:

You seem to be saying that pure lexical transparency is always preferable
to statefulness (e.g. context). Can we make that leap? If not, set me
straight. If so, tell me: how do we programmaticall y model those situations
in life which are inherently contextual in nature, where you might get
a small piece of information and must make sense of it by drawing on
information that is _not_ given in that information, but is (globally,
if you will) "just known" by you? How about conversations in English?
And, by the way, how do you really know I'm writing to you in English, and
not some coded language that means something entirely different?

--
Duane Rettig du***@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: [phone]; Fax: [phone]

[Alexander Schmolck]

Duane Rettig <du***@franz.co m> writes:

My reason for responding to you in the first place was due to your poor use
of the often misused term "bug". You could have used many other words or
phrases to describe the situation, and I would have left any of those alone.
I'm happy to accept your terminology of bug (not conforming to a certain
specification) for the remainder of this discussion so that we can stop
quibbling over words.

[...]

I'd be even more interested in what you think (seriously; should
you consider it a design feature (for reasons other than backwards
compatiblity constraints), I'm pretty sure you would also give a justification
that would merrit consideration).

Well, OK, let's change the conversation away from "bug"-ness and toward any of
the other negatives we discussed above. I actually doubt that I can provide
a justification in a small space without first understanding who you are
and from what background you are coming, so let me turn it around and ask
you instead to knock down a straw-man:

You seem to be saying that pure lexical transparency is always preferable
to statefulness (e.g. context).

No.
Can we make that leap? If not, set me straight.
I think that in most contexts lexical transparency is desirable so that
deviations from lexical transparency ought to be well motivated. I also
believe that a construct that is usually used to establish a lexically
transparent binding shouldn't be equally used for dynamic bindings so that it
isn't syntactically obvious what's going on. I've already provided some
reasons why CL's design wrt. binding special and lexical variables seems bad
to me. I don't think these reasons were terribly forceful but as I'm not aware
of any strong motivation why the current behaviour would be useful I'm
currently considering it a minor wart.

To make things more concrete: What would be the downside of, instead of doing
something like:

(let ((*x* ...)) [(declare (special *x*))] ...) ; where [X] denotes maybe X

doing any of the below:

a) using a different construct e.g. (fluid-let ((*x* ...)) ...) for binding
special variables
b) having to use *...* (or some other syntax) for special variables
c) using (let ((q (special *x*) (,a ,b ,@c)) (values 1 2 '(3 4 5 6)))
(list q ((lambda () (incf *x*))) a b c)) ; => (1 3 3 4 (5 6))

(It's getting late, but hopefully this makes some vague sense)
If so, tell me: how do we programmaticall y model those situations in life
which are inherently contextual in nature, where you might get a small piece
of information and must make sense of it by drawing on information that is
_not_ given in that information, but is (globally, if you will) "just known"
by you? How about conversations in English? And, by the way, how do you
really know I'm writing to you in English, and not some coded language that
means something entirely different?

We can skip that part.

'as

[Alexander Schmolck]

jayessay <no****@foo.com > writes:

Great -- so can I see some code? Can't be that difficult, it takes about 10-15
lines in python (and less in scheme).

Do you actually need the code to understand this relatively simple concept???

Yes. I'd be genuinely curious to see how an implementation in Java, Pascal, C,
(or any other language that has little more than dictionaries) compares to
python and CL.

In my limited understanding I have trouble seeing how you'd do without either
unwind-protect/try-finally or reliable finalizers for starters.

'as

[Alexander Schmolck]

Ken Tilton <ke*******@gmai l.com> writes:

Alexander Schmolck wrote:

Ken Tilton <ke*******@gmai l.com> writes:

In Common Lisp we would have:

(defvar *x*) ;; makes it special
(setf *x* 1)
(print *x*) ;;-> 1
(let ((*x* 2))
(print *x*)) ;; -> 2
(print *x*) ;; -> 1

You seem to think that conflating special variable binding and lexical

variable binding is a feature and not a bug. What's your rationale?

Transparency.

That's is circular. You might be right, but you failed to provide a rationale
and not just a restatement.
That is where power comes from. I did the same things with Cells. Reading a
slot with the usual Lisp reader method transparently creates a dependency on
the variable.
Let me see if I understand it right -- if an instance of class A has a ruled
slot a that reads an instance of class B's slot b then it is noted somewhere
that A's a depends on b?
To change a variable and have it propagate throughout the datamodel, Just
Change It.
Exposed wiring means more work and agonizing refactoring.

Well, you claim that in that instance python suffers from exposed wiring and I
claim that CL suffers from a (minor) booby trap. You can't typically safely
ignore whether a variable is special as a mere wiring detail or your code
won't work reliably (just as you can't typically safely ignore whether
something is rigged or not even if booby-trapness is pretty transparent) --
it's as simple as that (actually its a bit worse because the bug can be hard
to detect as lexical and special variables will result in the same behaviour
in many contexts).

So in the case of booby traps and special variables, I generally prefer some
exposed wiring (or strong visual clues) to transparency.

I'd like to see a demonstration that using the same binding syntax for special
and lexical variables buys you something apart from bugs.

'as

[Ken Tilton]

Alexander Schmolck wrote:

Duane Rettig <du***@franz.co m> writes:

Alexander Schmolck <a.********@gma il.com> writes:

Ken Tilton <ke*******@gmai l.com> writes:
In Common Lisp we would have:

(defvar *x*) ;; makes it special
(setf *x* 1)
(print *x*) ;;-> 1
(let ((*x* 2))
(print *x*)) ;; -> 2
(print *x*) ;; -> 1

You seem to think that conflating special variable binding and lexical
variable binding is a feature and not a bug. What's your rationale?

I will expand on my earlier "transparen cy" rationale with a further
rationale for transparency: I do not need no stinkin' rationale. A
special variable is still a variable. They should be set, read, and
bound (say, by "let") the same way as any other variable.

You need a rationale. It sounds as if you want some noisey syntax to
advertise the specialness. I do not think the Python community will
appreciate you messing up their pretty code.

You are right about one thing: specialness needs advertising. You know
what we do in Lisp? We obediently name special variables with bracketing
*s, like *this*. Too simple?

A bug is a non-conformance to spec.

There is a world beyond specs, you know. If copies of allegro CL accidently
sent out death-threats to the US president on a weekly basis, because someone
at franz accidently or purposefully left in some pranky debugging code the
fact that this behaviour would likely neither violate the ansi spec nor any
other specs that ACL officially purports to adhere to wouldn't make it any
less of a bug (or help to pacify your customers).

Kenny's statement was specifically about Common Lisp

No Kenny's statement was about contrasting the way something is done in python
and the way something is done in common lisp (with the implication that the
latter is preferable).

Close, but no. The question I was weighing in was "has Michele
replicated special variables?". My implication was, "Not yet -- can you
match the transparency?", and it was an honest question, I do not know.
Again, transparency is a qualitative difference.

I liked your solution better, btw, because it does minimize the noise.
For fun, you should call the class ** instead of special, so we end up
with: **.b = 42

We'll understand. :)
Of course the way something is done in common lisp is
almost tautologically in closer agreement with the ansi common lisp spec than
the way it is done in python, so agreement with the clhs is not a useful
criterion when talking about design features and misfeatures when contrasting
languages.
Again, no, it is not the spec, it is the highly-valued Python quality of
clean code. Also, the consistency of treating variables as variables,
regardless of some special/dynamic quality.

Some background. Lisp is a big language, and I am self taught and do not
like to read, grew up in Lisp in isolation. Not many Lispers in the
exercise yard. Discovered special variables only when we hired an old
hand who gently corrected a howler:

(let* ((old-x *x*))
(setf *x* 42)
....
(setf *x* old-x))

I still laugh at that. Anyway, as soon as I learned that, I was able to
make Cells syntax infinitely more transparent. And guess what? It also
made dependency identification automatic instead of cooperative, and
when I rebuilt a huge Cells-based app I discovered two or three cases
where I had neglected to publish a dependency.

It's a mystery, but somehow simpler syntax... oh, wait, this is
c.l.python, I am preaching to the choir.

I just don't think the way special variable binding (or variable binding in
general[1]) is handled in common lisp is particularly well designed or
elegant.
See above. There is nothing like a concrete experience of implementing a
hairy library like Cells /without/ leveraging specials and then
converting to specials. Talk about an Aha! experience. I mean, bugs ran
screaming from their nests simply because of the implementation change--
we call that A Message From God that the design has taken a correct turn.

Special variables and lexical variables have different semantics and using
convention and abusing[2] the declaration mechanism to differentiate between
special and lexical variables doesn't strike me as a great idea.
I know what you mean, but I like reading tea leaves, and I find it
fascinating that *this* somehow eliminates all ambiguity. Background:
don't know where I might find it, but I once saw a thread demonstrating
the astonishing confusion one could create with a special variable such
as a plain X (no *s). Absolutely mind-bogglingly confusing. Go back and
rename the special version *x*, and use *x* where you want to rebind it.
Result? Utterly lucid code. Scary, right?
I can certainly think of problems that can occur because of it (E.g. ignoring
or messing up a special declaration somewhere; setf on a non-declared variable
anyone?
Sh*t, you don't respond to compiler warnings? Don't blame CL for your
problems. :)
There are also inconsistent conventions for naming (local) special
variables within the community (I've seen %x%, *x* and x)).
OK, you are in flamewar mode, now you are just making things up.

Thus I don't see having to use syntactically different binding and assignment
forms for special and lexical variables as inherently inferior.

DUDE! They are both variables! Why the hell /should/ the syntax be
different? "Oh, these are /cross-training/ sneakers. I'll wear them on
my hands." Hunh?

:)
kenny

[Ken Tilton]

Paul Rubin wrote:

Alexander Schmolck <a.********@gma il.com> writes:

(defvar *x*) ;; makes it special
(setf *x* 1)
(print *x*) ;;-> 1
(let ((*x* 2))
(print *x*)) ;; -> 2
(print *x*) ;; -> 1

You seem to think that conflating special variable binding and lexical
variable binding is a feature and not a bug. What's your rationale?

I thought special variables meant dynamic binding, i.e.

(defvar *x* 1)
(defun f ()
(print *x*) ;; -> 2
(let ((*x* 3))
(g)))
(defun g ()
(print *x*)) ;; - > 3

That was normal behavior in most Lisps before Scheme popularlized
lexical binding. IMO it was mostly an implementation convenience hack
since it was implemented with a very efficient shallow binding cell.
That Common Lisp adapted Scheme's lexical bindings was considered a
big sign of CL's couthness. So I'm a little confused about what Ken
Tilton is getting at.

Paul, there is no conflict between your example and mine, but I can see
why you think mine does not demonstrate dynamic binding: I did not
demonstrate the binding applying across a function call.

What might be even more entertaining would be a nested dynamic binding
with the same function called at different levels and before and after
each binding.

I just had the sense that this chat was between folks who fully grokked
special vars. Sorr if I threw you a curve.

kenny

[Ken Tilton]

Everything else responded to separately, but...

I'd like to see a demonstration that using the same binding syntax for special
and lexical variables buys you something apart from bugs.

Buys me something? Why do I have to sell simplicity, transparency, and
clean syntax on c.l.python?

kenny

--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.

[Duane Rettig]

Alexander Schmolck <a.********@gma il.com> writes:

I think that in most contexts lexical transparency is desirable so that
deviations from lexical transparency ought to be well motivated. I also
believe that a construct that is usually used to establish a lexically
transparent binding shouldn't be equally used for dynamic bindings so that it
isn't syntactically obvious what's going on. I've already provided some
reasons why CL's design wrt. binding special and lexical variables seems bad
to me. I don't think these reasons were terribly forceful but as I'm not aware
of any strong motivation why the current behaviour would be useful I'm
currently considering it a minor wart.

To make things more concrete: What would be the downside of, instead of doing
something like:

(let ((*x* ...)) [(declare (special *x*))] ...) ; where [X] denotes maybe X
Let's start with this. You seem to be saying that the above construct is inferior
to the alternatives you are about to suggest. Why? And since you are adding
an optional form, let's break it down into its separate situations:

1. (let ((*x* ...)) (declare (special *x*)) ...)

Here there is no question about the specialness of *x*; it is textually
obvious what the binding is - that it is not a lexical binding but a special
binding.

2. (let ((*x* ...)) ...)

[where there is no special declaration for *x* within the form]

Here, the issue is that it is not obvious that *x* is special (in this case,
it would have to already be a dynamic variable (what we internally call
"globally special"), because a special declaration within a lexical context
does not affect inner bindings. Perhaps this form is the one you are really
having trouble with.
doing any of the below:

a) using a different construct e.g. (fluid-let ((*x* ...)) ...) for binding
special variables
Unless you also _remove_ the #2 case above, this seems no diferent than writing
a macro for the #1 case, above.
b) having to use *...* (or some other syntax) for special variables
In fact, the spec does suggest precisely this (see
http://www.franz.com/support/documen...r/defparam.htm,
in the Notes section), and to the extent that programmers obey the suggestion,
the textual prompting is present in the name.
c) using (let ((q (special *x*) (,a ,b ,@c)) (values 1 2 '(3 4 5 6)))
(list q ((lambda () (incf *x*))) a b c)) ; => (1 3 3 4 (5 6))

(It's getting late, but hopefully this makes some vague sense)

Well, sort of; this seems simply like a sometimes-fluid-let, whose syntax could
easily be established by a macro (with destructurings whose form is (special X)
could be specially [sic] treated.

Now if in the above example you would have trouble with (a) and/or (c)
based on the absence of a "lexical" declaration (i.e. one that would undo
the effect of a globally special declaration), thus guaranteeing that a
fluid-let or a "sometimes-fluid-let" would work, you should know that while
I was working on the Environments Access module I theorized and demonstrated
that such a declaration could be easily done within a conforming Common Lisp.
I leave you with that demonstration here (though it really is only for
demonstration purposes only; I don't necessarily propose that CL should add
a lexical declaration to the language):

[This only works on Allegro CL 8.0]:

CL-USER(1): (defvar pie pi)
PIE
CL-USER(2): (compile (defun circ (rad) (* pie rad rad)))
CIRC
NIL
NIL
CL-USER(3): (circ 10)
314.15926535897 93d0
CL-USER(4): (compile (defun foo (x) (let ((pie 22/7)) (circ x))))
FOO
NIL
NIL
CL-USER(5): (foo 10)
2200/7
CL-USER(6): (float *)
314.2857
CL-USER(7): (sys:define-declaration sys::lexical (&rest vars)
nil
:variable
(lambda (declaration env)
(declare (ignore env))
(let* ((spec '(lexical t))
(res (mapcar #'(lambda (x) (cons x spec))
(cdr declaration))))
(values :variable res))))
SYSTEM::LEXICAL
CL-USER(8): (compile (defun foo (x) (let ((pie 22/7)) (declare (sys::lexical pie)) (circ x))))
; While compiling FOO:
Warning: Variable PIE is never used.
FOO
T
NIL
CL-USER(9): (foo 10)
314.15926535897 93d0
CL-USER(10):

--
Duane Rettig du***@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: [phone]; Fax: [phone]

[Marcin 'Qrczak' Kowalczyk]

Ken Tilton <ke*******@gmai l.com> writes:

I think the point is that, with the variable actually being just
a string and with dedicated new explicit functions required as
"accessors" , well, you could hack that up in any language with
dictionaries. It is the beginnings of an interpreter, not Python
itself even feigning special behavior.

If the semantics and the global structure of the code is right, only
you don't like the local concrete syntax, then the complaint is at
most as justified as complaints against Lisp parentheses.

--
__("< Marcin Kowalczyk
\__/ qr****@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Marcin 'Qrczak' Kowalczyk]

Alexander Schmolck <a.********@gma il.com> writes:

I'd like to see a demonstration that using the same binding syntax
for special and lexical variables buys you something apart from bugs.

There are 3 fundamental operations related to plain mutable variables:

A1. Making a new mutable variable with an initial value.
A2. Getting the current value.
A3. Setting the new value.

and 4 operations related to dynamically scoped variables:

B1. Making a new dynamic variable with an initial value.
B2. Getting the current value.
B3. Setting the new value.
B4. Local rebinding with a new initial value.

If you don't ever use B4, dynamic variables behave exactly like plain
variables. For this reason I see no point in distinguishing A2 from B2,
or A3 from B3. Dynamic variables are a pure extension of plain variables
by providing an additional operation.

Distinguishing the syntax of A1 and B1 is natural: somehow it must be
indicated what kind of variable is created.

Mutability is orthogonal to dynamic scoping. It makes sense to have a
variable which is like a plain variable but without A3, and a variable
which is like a dynamic variable but without B3, although it doesn't
provide anything new, only allows to express more constraints with a
potential for optimization. I won't consider them here.

Common Lisp does something weird: it uses the same syntax for A1 and B4,
where the meaning is distinguished by a special declaration. Here is
its syntax:

Directly named plain variables:
A1. (let ((name value)) body) and other forms
A2. name
A3. (setq name value), (setf name value)

First-class dynamic variables:
B1. (gensym)
B2. (symbol-value variable)
B3. (set variable value), (setf (symbol-value variable) value)
B4. (progv `(variable) `(value) body)

Directly named dynamic variables:
B1. (defvar name value), (defparameter name value)
B2. name
B3. (setq name value), (setf name value)
B4. (let ((name value)) body) and other forms

Dynamic variables in Lisp come in two flavors: first-class variables
and directly named variables. Directly named variables are always
global. You can convert a direct name to a first-class variable by
(quote name).

Plain variables have only the directly named flavor and they are
always local. You can emulate the first-class flavor by wrapping a
variable in a pair of closures or a closure with dual getting/setting
interface (needs a helper macro in order to be convenient). You can
emulate a global plain variable by wrapping a dynamic variable in a
symbol macro, ignoring its potential for local rebinding. You can
emulate creation of a new first-class variable by using a dynamic
variable and ignoring its potential for local rebinding, but this
can't be used to refer to an existing directly named plain variable.

In order to create a plain variable, you must be sure that its name is
not already used by a dynamic variable in the same scope.

So any essential functionality is possible to obtain, but the syntax
is very irregular.

--
__("< Marcin Kowalczyk
\__/ qr****@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/