[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 26 Nov 2010 18:01:49 -0500
> just out of inertia but also because I like a more functional style
> of programming: usually/often you can find a formulation that's just
> as elegant without the need for an early exit.
I don't see how (of itself) this preference is sufficiently applicable.
W/re the current inertia of the Emacs lisp VM, it seems whatever
"elegance" gained by the "functional" style it provides is per the
dynamic scoping, and even so it still _requires_ dynamic non-local
exits with catch/throw.
How do you anticipate reconciling this preference in terms of lexbind
integration? The impression I'm given from the CL ANSI spec is that
the `block'/`return-from' special forms (despite their "non-elegance")
were desirable/needed in lieu of dynamic shadowing other dynamic
shadowing concerns w/re transfer of control on exit, e.g.
Section 3.1.5 "Shadowing" of the Common Lisp ANSI spec:
Note, in particular that the above should not be considered without
consideration of the impact this hs w/re to Common Lisps treatment of
Closures and Lexical Binding e.g. the immediately preceding section 3.1.4.
and the X3J13 Exit Extent Issue:
| The extent of an exit is not the same thing as the scope of the
| designator by which the exit is identified. For example, a BLOCK
| name has lexical scope but the extent of its exit is dynamic; the
| scope of a CATCH tag could differ from the extent of the CATCH's
| return point. (That's part of what is at issue here.)
In reading the second link above it's pretty clear that this issue had
an immediate affect on `unwind-protect'. Indeed, to the extent :P this
is so, discussion/dismissals of block/return-from should take into the
historic tension between Maclisp derived lisps dialects and the Scheme
derived lisp dialects around `unwind-protect'.
IOW, It almost certainly wasn't simply as a matter of personal
preference that the Common Lisp people incorporated and subsequently
debated the correct implementation of the things.
> We could also provide (and encourage the use of) Scheme's named-let,
> although it tends to be "too powerful" (not inherently
> tail-recursive, so making it efficient (CPU-wise and
> stack-space-wise) would require a good bit more work).
So, how then is `named-let' a somehow better/cleaner solution than an
alternative first-class implementation of a `block'/`return-from'
Re: return, Stefan Monnier, 2010/11/26
MON KEY <=
- Re: return, (continued)
- Re: return, Tassilo Horn, 2010/11/26