Re: Return

[MON KEY <monkey@sandpframing.com>]

On Mon, Dec 6, 2010 at 2:20 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> MON KEY writes:
>
>  > Indeed, one often doesn't miss what one never knew wasn't there to be missed.
>  > GVM has no doubt leveraged this against future Python initiates.
>
>
> Not at all.  Python is intended to have functional programming
> features, but it's also intended to primarily be an imperative
> language, not a functional language.  GvR is well aware of the uses of
> lambda and there are a lot of fans of lambda (as well as of "first-
> class anonymous blocks" which may or may not be the same as lambdas)
> among Pythonistas.  He just doesn't think such features belong in
> Python, and I have to admit I don't miss them.
>

I'e no clue whether this is good or bad for Python(istas) my
concern is simply that this viewpoint not encroach upon the Emacs Lisp
VM without qualification. :)

In any event, AIUI much of GvR's objection w/re Python's lambda was
that it won't parse cleanly given the syntactic reliance on
whitespace.

Whichever, I was mostly pointing out that with lisp source we don't
rely on whitespace to formally convey syntax and that (with lisp2's at
least) there is ample opportunity to make use of imperative style
block/go/return/return-from forms as well... No doubt this is obvious
to most here but it is all too easily forgotten when discussion of
alternative non-lispy languages are brought to bare on the efficacy of
lispy languages.

>
>  > ,----
>  > | (defmacro lambda (&rest forms) `(defun ,(gensym) ,@forms))
>  > |
>  > | or something like that. ;-)
>  > `----
>  >
>  > Perhaps, but quite a bit more happens at compile time around lambda and will do
>  > more so if/when the lexbind is merged. :)
>
> That was a wink because of course I'm cheating like hell: in a typical
> interpreted Lisp, defun is just a feature-creepy way of associating a
> lambda with a name (aka symbol), and my macro is an inefficient way of
> creating an anonymous function.

Likely you know better than I and the wink wasn't lost on me. :)

However, as you suggest with your caveat "in a typical interpreted
Lisp" this may not apply to compiled code... Which is to say, doesn't
your example dance around what happens around defun/defmacro/lambda at
compile time in any lexically scoped implementation of
<substitute your non-interpreted lexically scoped modern lispy
dialect of choice here>?

> IOW, no, nothing special happens at
> compile time and no, lexbind won't change that.  Any semantic changes
> that happen to lambda will happen to defun and vice versa.
>
>  > What would be interesting to learn is whether there is any will for a formal
>  > incorporation of the C in Clisp w/ the E in elisp?
>
> {...}
> Hrvoje Niksic and Martin Buchholz advocated a Common Lisp as the
> appropriate way to evolve elisp, and IIRC Erik Naggum was in that camp
> too.  But they've all long since left the development community.

The slime users/developers are _actively_ incorporating Common Lisp
(of various implementations) with Emacs/Emacs lisp (unfortunately they
have to resort to a different RPC per implementation to do
so). Regardless, the Slime user/devel community is hardly an
insignificant group.

This said, I suspect most of them only actively engage elisp in lieu
of Common Lisp out of necessity not preference.

>
> I think most of the people with an interest in it are either hacking
> elisp directly (like Miles) or are Schemers (like Mike "R6RS"
> Sperber).
>

Don't forget the Guile Schemers whose efforts to incorporate the R6RS
with that implementation will eventually bring yet another Scheme that
much closer to Greenspun's 10th...

In which case, assuming further future integration of Guile with (GNU)
Emacs we might find that much of what the Common Lisp crowd has sought
for years will (finally) be made available to the Emacs VM.

If such does happen, it will be highly amusing to witness the clamor
by Schemers for elisp incorporation of `#:keywords-styled-thusly'
esp. when these too are dismissed as "ugly" , "inefficient to
implement", "confusing to users", etc.

Meanwhile burgeoning adepts of the GNU Findutils toolbox will no doubt
chuckle nervously at the thought of trying to invoke a `find' command
(with its 70+ flags) with only "By Order of Argument" at their
disposal...

>
>  > the closed/proprietary control maintained on the FSF Emacs source
>  > tree.
>
> Hardly closed *or* proprietary.

Tomato/Potato[1]

> Remember XEmacs in your prayers, and
> rest assured that any work you do on Emacs remains free for others to
> use, whether GNU chooses to distribute it or not.

No doubt. :)

>  If they choose not, you can always do it yourself, as we do.

Yes but there is an accord to maintain some mutual consensus. AIUI your
presence on this list is indicative of such an effort no?
To paraphrase JWZ,  "Now you have two problems."

>
> But ... I wouldn't bet that you'll have more luck peddling your warez
> at xemacs.org or sxemacs.org for that matter.
>

I'm not aware of peddling either here or there... what is occurring
here is more akin to carpet-bagging than to commerce in snake-oil.

>
> That's the nature of a distribution, that somebody decides what to distribute.
> Typically by rejecting your proposals, c'est la vie. :-)
>

If there is angst here it is not around the rejection of any
particular proposal (certainly not my own), but rather about the
persistent inability to engage in reasoned/meaningful/intentioned
discussion w/re incorporating of a particular set of Lisp features by
either ignoring and/or dismissing the utility these features do
otherwise provide both Emacs user community and the greater community
of Lisp dialect users despite a general acknowledgment by both of
these communities that the particular set of features are
wanted/needed and FTMP can be reasonably implemented.

[1] The long term evidence of this inability IMO suggests that the Emacs
project(s) are closed and proprietary project (whether their source be
free or not). That [SX]Emacs does remain reasonably compatible with
GNU Emacs suggest that it too abides this inability (whether tacitly
or otherwise).

--
/s_P\