* Re: Keyword args
@ 2010-12-12 17:01 MON KEY
0 siblings, 0 replies; 7+ messages in thread
From: MON KEY @ 2010-12-12 17:01 UTC (permalink / raw)
To: emacs-devel
> This bug was fixed quite some time ago:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6408
Well not all _that_ long ago.
But yes, applying that patch fixes things here. Thanks.
Did this make it into the current pretest?
So, apparently it is true what you say, dbind is a panacea!
"Got &keys? destructuring-bind em.
dbind - the elixir for all ones elisp ails." ™
--
/s_P\
^ permalink raw reply [flat|nested] 7+ messages in thread
* Keyword args (was: Return)
@ 2010-12-12 4:49 MON KEY
2010-12-12 8:34 ` Keyword args Helmut Eller
0 siblings, 1 reply; 7+ messages in thread
From: MON KEY @ 2010-12-12 4:49 UTC (permalink / raw)
To: eller.helmut; +Cc: emacs-devel
> Since we have destructuring-bind parsing plists is not very hard.
No, we have _some_ of dbind...
Following is the CL specs cannonical `destructuring-bind' example:
,----
|
| Examples:
|
| (defun iota (n) (loop for i from 1 to n collect i)) ;helper
|
| (destructuring-bind ((a &optional (b 'bee)) one two three)
| `((alpha) ,@(iota 3))
| (list a b three two one)) → (ALPHA BEE 3 2 1)
|
`----
Does evaluating the above two forms in elisp land you in *Backtrace*
with something like this at beginning-of-buffer:
Debugger entered--Lisp error: (void-variable bind-enquote)
If so, I would argue that the current elisp's implementation fo
`destructuring-bind' isn't exactly the panacea to keyword parsing you
claim it is.
By way of comparison this is what a recent SBCL returns:
CL-USER> (format nil "~a ~a" (lisp-implementation-type)
(lisp-implementation-version))
;=> "SBCL 1.0.45.3"
CL-USER> (defun iota (n) (loop for i from 1 to n collect i))
;=> IOTA
CL-USER> (destructuring-bind ((a &optional (b 'bee)) one two three)
`((alpha) ,@(iota 3))
(list a b three two one))
;=> (ALPHA BEE 3 2 1)
--
/s_P\
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Keyword args
2010-12-12 4:49 Keyword args (was: Return) MON KEY
@ 2010-12-12 8:34 ` Helmut Eller
0 siblings, 0 replies; 7+ messages in thread
From: Helmut Eller @ 2010-12-12 8:34 UTC (permalink / raw)
To: emacs-devel
* MON KEY [2010-12-12 04:49] writes:
>> Since we have destructuring-bind parsing plists is not very hard.
>
> No, we have _some_ of dbind...
>
> Following is the CL specs cannonical `destructuring-bind' example:
>
> ,----
> |
> | Examples:
> |
> | (defun iota (n) (loop for i from 1 to n collect i)) ;helper
> |
> | (destructuring-bind ((a &optional (b 'bee)) one two three)
> | `((alpha) ,@(iota 3))
> | (list a b three two one)) (ALPHA BEE 3 2 1)
> |
> `----
>
> Does evaluating the above two forms in elisp land you in *Backtrace*
> with something like this at beginning-of-buffer:
>
> Debugger entered--Lisp error: (void-variable bind-enquote)
>
> If so, I would argue that the current elisp's implementation fo
> `destructuring-bind' isn't exactly the panacea to keyword parsing you
> claim it is.
This bug was fixed quite some time ago:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6408
Helmut
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
@ 2010-12-05 23:55 MON KEY
2010-12-06 1:48 ` Return Stephen J. Turnbull
0 siblings, 1 reply; 7+ messages in thread
From: MON KEY @ 2010-12-05 23:55 UTC (permalink / raw)
To: emacs-devel; +Cc: stephen
,----
| Note that Python (at least) has adopted this approach, with a core
| language definition that is 99% or so independent of implementation
| (cf. CPython, Cython nee pyrex, Stackless Python, Jython, IronPython,
| and PyPy).
`----
Pshaw... Doesn't GVR eschew ++Lambda++ in p3k? Heresy!
,----
| Speaking of Common Lisp, since it has a package scheme, you might be
| able to implement the elisp interpreter by using the elisp
| interpreter, and put in in a package that uses elisp eval instead of
| Common Lisp's eval.
`----
Sam Steingold has explored this in the CLOCC.
There is also LICE.
Pretty sure Closure has an "Emacs like" editor for Mac environs.
PJB maintains quite a bit of Elisp<-->Common-Lisp code.
FWIW I've been collecting various bits and pieces from the above mentioned
sources into a personal package for the last ~6 months.
I'm sure many Common Lispers do similarly.
Also, as mentioned there is Climacs which is quite functional with McClim/CLX.
Likewise, there is Hemlock. (AIUI someone is currently porting it to Qt...)
Also, there are any number of legacy "Emacs like" editors from the
Lispm/TI/Symbolics/BBN/Xerox... implementations. Source is generally available
for all of these.
Contemporary commercial sources like Lispworks and Allegro provide "Emacs like"
editors.
Given Emacs' Maclisp lineage and the number of Lisp2 users whom actively use
GNU/Xemacs (or some equivalent) and the presence of a formal Common Lisp
specification implemented on myriad platforms and multiple
implementations of said
specification, why on earth should a switch to either a Scheme/Python VM warrant
consideration.
FWIW I find it quite odd that discussions of moving the Emacs VM to
Guile are bandied
about when Clisp is available as a GNU project (since forever), has an existing
C interface, is easily as portable across platformas as Guile scheme, counts
among its core authors a formidable contributor to various high-level
GNU projects
(Bruno Haible) and has the admirable quality that it doesn't get confused
between nil/empty-list/falsehood in the way that a Scheme will.
--
/s_P\
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
2010-12-05 23:55 Return MON KEY
@ 2010-12-06 1:48 ` Stephen J. Turnbull
2010-12-06 5:50 ` Return MON KEY
0 siblings, 1 reply; 7+ messages in thread
From: Stephen J. Turnbull @ 2010-12-06 1:48 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
MON KEY writes:
> ,----
> | Note that Python (at least) has adopted this approach, with a core
> | language definition that is 99% or so independent of implementation
> | (cf. CPython, Cython nee pyrex, Stackless Python, Jython, IronPython,
> | and PyPy).
> `----
>
> Pshaw... Doesn't GVR eschew ++Lambda++ in p3k? Heresy!
No, YAGNI. Even more so in Emacs Lisp:
(defmacro lambda (&rest forms) `(defun ,(gensym) ,@forms))
or something like that. ;-)
> ,----
> | Speaking of Common Lisp, since it has a package scheme, you might be
> | able to implement the elisp interpreter by using the elisp
> | interpreter, and put in in a package that uses elisp eval instead of
> | Common Lisp's eval.
> `----
>
> Sam Steingold has explored [...]
I'll take a look. But ...
> Also, there are any number of legacy "Emacs like" editors
Indeed. For unacceptably small values of "like", though. AFAIK the
people you would expect to actually be working on those things (eg,
you mention Bruno Haible as well as Sam Steingold) use "real" Emacs
instead for production work. I wonder why? ;-)
> why on earth should a switch to either a Scheme/Python VM warrant
> consideration.
I'm not suggesting switching to the Python VM, I'm proposing Python as
an example of a language with several implementations targeting
multiple VMs. The reason for using a Scheme is that it's much lighter
weight than a Common Lisp implementation. That may not butter your
bread, but it matters to Richard, I believe, and to the people who
work on those implementations.
> FWIW I find it quite odd that discussions of moving the Emacs VM to
> Guile are bandied about
"Bandied about" is quite the odd term to use for a decision that AIUI
was made more than a decade ago. Emacs just has a long gestation
period for features. :-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
2010-12-06 1:48 ` Return Stephen J. Turnbull
@ 2010-12-06 5:50 ` MON KEY
2010-12-06 7:20 ` Return Stephen J. Turnbull
0 siblings, 1 reply; 7+ messages in thread
From: MON KEY @ 2010-12-06 5:50 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: emacs-devel
On Sun, Dec 5, 2010 at 8:48 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
> Pshaw... Doesn't GVR eschew ++Lambda++ in p3k? Heresy!
,----
| No, YAGNI. Even more so in Emacs Lisp:
`----
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.
Fortunately a good many lispers are too accustomed w/ lambda by virtue of
defmacro and Lisp's terse parenthetical syntax to not miss it.
,----
| (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. :)
> ,----
> | Speaking of Common Lisp, since it has a package scheme, you might be
> | able to implement the elisp interpreter by using the elisp
> | interpreter, and put in in a package that uses elisp eval instead of
> | Common Lisp's eval.
> `----
>
> Sam Steingold has explored [...]
,----
| I'll take a look. But ...
`----
FWIW I've found the old LispM sources to be the most enlightening.
> Also, there are any number of legacy "Emacs like" editors
,----
| Indeed. For unacceptably small values of "like", though.
|
| AFAIK the people you would expect to actually be working on those things (eg,
| you mention Bruno Haible as well as Sam Steingold) use "real" Emacs
| instead for production work. I wonder why? ;-)
`----
I've no idea why either of those individuals might do what they do.
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?
I imagine there are still a good many Common Lisp hacks that would contribute
their valuable skills to such an effort were it not for the closed/proprietary
control maintained on the FSF Emacs source tree.
Regardless, the "real" Emacsen we are using today are not fundamentally so far
removed from the legacy CLTL based systems they were once built upon that we can
describe the contemporary Emacsen as somehow more "real" than its ancestor.
Indeed, as you have framed it, mine was a comparison of Emacs to TECO. I would
offer that the situation may be inverted, and that in many ways todays Emacsen
are the TECOs to a certain breed of ancestral Emacsen. No doubt you're well
aware of the lineage ;-)
Indeed, when browsing through the LispM sources it is quite surprising to learn
how much of the underlying Emacs VM (now C based) was once CLTL based. In some
cases one can still catch glimpes of entire blocks of text which nearly
superimpose one another (syntax differences aside)...
> why on earth should a switch to either a Scheme/Python VM warrant
> consideration.
,----
| I'm not suggesting switching to the Python VM, I'm proposing Python as
| an example of a language with several implementations targeting
| multiple VMs.
`----
Great! I misunderstood.
,----
| The reason for using a Scheme is that it's much lighter
| weight than a Common Lisp implementation.
`----
This is an awfully general assertion.
Which Scheme implementation?
Which Scheme with which R[456]RS?
And for any given implementation, which shared/linked libraries are required?
Which CL implementation?
,----
| That may not butter your bread, but it matters to Richard, I believe, and to
| the people who work on those implementations.
`----
Butter aside, it isn't at all clear what the matter that matters is and to and
for whom.
> FWIW I find it quite odd that discussions of moving the Emacs VM to
> Guile are bandied about
,----
| "Bandied about" is quite the odd term to use for a decision that AIUI
| was made more than a decade ago.
`----
Which decision, the decision to fork Emacs' CLTL code base from the LispM or the
decision that Guile might eventually grow into its shoes enough to become a
worthy consideration as the Emacs scripting engine?
,----
| Emacs just has a long gestation period for features. :-)
`----
And enough hubris to squelch many such features which should never have been
removed during the initial LispM fork 25+ yrs ago.
--
/s_P\
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
2010-12-06 5:50 ` Return MON KEY
@ 2010-12-06 7:20 ` Stephen J. Turnbull
2010-12-07 2:42 ` Return MON KEY
0 siblings, 1 reply; 7+ messages in thread
From: Stephen J. Turnbull @ 2010-12-06 7:20 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
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.
> ,----
> | (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. 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. 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).
> the closed/proprietary control maintained on the FSF Emacs source
> tree.
Hardly closed *or* proprietary. 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. If they choose not,
you can always do it yourself, as we do.
But ... I wouldn't bet that you'll have more luck peddling your warez
at xemacs.org or sxemacs.org for that matter. That's the nature of a
distribution, that somebody decides what to distribute. Typically by
rejecting your proposals, c'est la vie. :-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
2010-12-06 7:20 ` Return Stephen J. Turnbull
@ 2010-12-07 2:42 ` MON KEY
2010-12-07 14:34 ` Return Stephen J. Turnbull
0 siblings, 1 reply; 7+ messages in thread
From: MON KEY @ 2010-12-07 2:42 UTC (permalink / raw)
To: emacs-devel
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\
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
2010-12-07 2:42 ` Return MON KEY
@ 2010-12-07 14:34 ` Stephen J. Turnbull
2010-12-07 15:54 ` Return David Kastrup
0 siblings, 1 reply; 7+ messages in thread
From: Stephen J. Turnbull @ 2010-12-07 14:34 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
MON KEY writes:
> > [GvR] just doesn't think such [lambda or anon blocks] 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. :)
No, it won't. However, I must say (as a maintainer) that use of
lambdas often imposes extra work on debuggers. I almost always give
lambdas a nickname when I'm reading code that uses them, unless
they're simply implementing partial evaluation.
> 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.
Not at all. That's an excuse that some lambda supporters will buy,
but he just doesn't think that the scope for appropriate use of
lambdas is that great, and especially not in Python. He'd rather add
new specialized syntax for major use cases. He's almost certainly
right for Python, and he doesn't claim any more generality than that.
> 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.
Proposing a non-Lispy language wasn't my intention at all.
> 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>?
I'm not sure what you think happens there. All that defun ever does
(that matters to this discussion) is create a function object and
assign a name (a symbol) to it. In a Lispy language when that symbol
is encountered as the car of a list to be evalled it is dereferenced
(the function cell in Lisp-2s and the value cell in Lisp-1s), and the
resulting function object applied to the arguments. Otherwise the car
must be a function object. And what is a function object? Either a
lambda or equivalent compiled code (yes, Virginia, a list starting
with a subr can be eval'ed).
So all the interesting questions of lexical scope vs. compilation have
to do with argument passing (including the special semantics of the
environment "variable", however that is defined and implemented).
However, AFAICS this doesn't (and mustn't, otherwise you'd be able to
tell the difference between eval'ing interpreted code and eval'ing
compiled code, which is verboten) change depending on whether the
compiled code object was defined directly as a lambda expression, or
via defun. If you know differently, I'd rather learn than teach. :-)
> > But [the CL advocates] all long since left the [Emacs]
> > 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.
Nobody says they are. But unless they hang out here, which they only
seem to do when they've got a bug report, they're not going to have
much influence on the future of the language. Given that RMS is
generally not in favor of incorporating Common Lisp features, I grant
that could be a huge investment of time, effort, code, and persuasive
engineering. I'm not criticizing them, I'm telling you that my view
is Emacs Lisp will turn into an implementation of Common Lisp sometime
later than Real Soon Now.
> > 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."
One of my problems is an addiction to email. The other is an
affection for David Kastrup. That is what my presence here
indicates.
More to the point, I long ago gave up on effecting a mutual consensus.
We either do it Emacs's way, or we don't. That's just the way it has
to be. I advocate things here that I think would be good for Emacs on
Emacs's own terms. I don't always get that right, but I'm definitely
not here to advocate the XEmacs way of thinking.
> 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.
Frankly, I don't see any such general acknowledgement in the general
Emacs community. There is a significant subset of developers who
would like that, yes. But the non-developer users could care less,
and many developers either prefer a different style of language or
fear that incorporation of more features would lead to a deterioration
of performance for typical use-cases or instability in use, which
really isn't acceptable.
Take lexbind, for example. It's been on the agenda for a long time,
and AFAIK RMS *never* objected to it in principle (at least once it
was made clear that dynamic scope would continue to be supported).
However, he does like dynamic scope, and insists that features like
lexbind be added in a way that doesn't get in the way of ordinary
users of existing Emacs features or cause the whole program to become
unstable.
> [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).
All it proves is that we're lazy, and want to take advantage of the
improvements to *Emacs* technology more than we want to take advantage
of improvements to *Lisp* technology. When all is said and done,
\(S?X\)?Emacs is as much an application as it is a language, and most
of our developers have far more interest in the application than the
language.
Eg, Aidan Kehoe has been busily improving our Common Lisp support,
even down to rewriting some of the docs (will wonders never cease?!)
and using some standard set of tests for the features he's
adding/upgrading/conformancing. Has he released any code that
*depends* on these features? Not yet, and I bet not soon. Does he
release (non-CL-implementation) code? Sure, an' he does. But it's
all bug fixes and conventional features. You may think that's
unfortunate, but that's the way the world works.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
2010-12-07 14:34 ` Return Stephen J. Turnbull
@ 2010-12-07 15:54 ` David Kastrup
2010-12-07 16:30 ` Return Stephen J. Turnbull
0 siblings, 1 reply; 7+ messages in thread
From: David Kastrup @ 2010-12-07 15:54 UTC (permalink / raw)
To: emacs-devel
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> MON KEY writes:
>
> > > [GvR] just doesn't think such [lambda or anon blocks] 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. :)
>
> No, it won't. However, I must say (as a maintainer) that use of
> lambdas often imposes extra work on debuggers. I almost always give
> lambdas a nickname when I'm reading code that uses them, unless
> they're simply implementing partial evaluation.
A nickname doesn't really apply well with closures. For debugging
purposes, a "named lambda" might be helpful. Conceivably one could
supply something like that using a DOC string.
> Nobody says they are. But unless they hang out here, which they only
> seem to do when they've got a bug report, they're not going to have
> much influence on the future of the language. Given that RMS is
> generally not in favor of incorporating Common Lisp features,
I don't think anybody minds the features. The problem is the cost in
syntactic complexity and language intransparency. cl is a large and
invasive hack that is not particularly nice during debugging,
decompiling and code design and optization. lexbind is a first step in
a direction where some Common Lisp features become less costly.
> > 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."
>
> One of my problems is an addiction to email. The other is an
> affection for David Kastrup. That is what my presence here indicates.
Doing all the right things for ostensibly awfully bad reasons sounds
like a form of compassionate nihilism designed to get out of the line of
appreciation. After all, it could get you into serious trouble at
/home/xemacs if somebody were as foolish as to, say, nominate you for
the Free Software Award for minimizing, for whatever reason, the
consequences of the great schism without losing face or focus. And it
would look decidedly fishy if I were to do such a thing after this
announcement.
> More to the point, I long ago gave up on effecting a mutual consensus.
> We either do it Emacs's way, or we don't. That's just the way it has
> to be. I advocate things here that I think would be good for Emacs on
> Emacs's own terms. I don't always get that right, but I'm definitely
> not here to advocate the XEmacs way of thinking.
You are advocating the Turnbull way of thinking, here and "there". At
least here, mixed success is nothing to be worried about.
> Frankly, I don't see any such general acknowledgement in the general
> Emacs community. There is a significant subset of developers who
> would like that, yes. But the non-developer users could care less,
> and many developers either prefer a different style of language or
> fear that incorporation of more features would lead to a deterioration
> of performance for typical use-cases or instability in use, which
> really isn't acceptable.
I see much more the danger in bit rot. I've been considering helping
with a dedicated lilypond-mode building on lyqi.el (there is a git repo
for that). The code is an exercise in cl use and makes my eyes glaze
over. I can't sensibly contribute, because it is utterly beyond me.
Many times in Emacs programming, I give up on the documentation and just
dig through the sources to see what something does deep down.
cl does not lend itself to that approach. Its code is highly complex
and utterly underdocumented. You have to trust it to do the right
thing. I hate doing that.
--
David Kastrup
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
2010-12-07 15:54 ` Return David Kastrup
@ 2010-12-07 16:30 ` Stephen J. Turnbull
2010-12-10 7:42 ` Return Daniel Colascione
0 siblings, 1 reply; 7+ messages in thread
From: Stephen J. Turnbull @ 2010-12-07 16:30 UTC (permalink / raw)
To: David Kastrup; +Cc: emacs-devel
David Kastrup writes:
> I don't think anybody minds the features.
IIRC rms has recently declared his dislike for CL-style keyword
arguments. I suppose that's part of the "syntactic complexity" you
mention, but MON KEY OTOH points out cases where he'd like to use
them. So there are some fundamental disagreements here.
There are also people who would like full-blown CL conformance in
Emacs. You could argue they could get that with Hemlock, but then
they don't get full-blown Emacs conformance. (I'm not sure why they
think it would be easier to turn Emacs Lisp into Common Lisp, than to
turn Hemlock into a fully compatible implementation of GNU Emacs, but
there you have it.)
> cl does not lend itself to that approach. Its code is highly complex
> and utterly underdocumented. You have to trust it to do the right
> thing. I hate doing that.
I think everybody agrees with all of those points, except that some
people are happy to trust now and debug later.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Return
2010-12-07 16:30 ` Return Stephen J. Turnbull
@ 2010-12-10 7:42 ` Daniel Colascione
2010-12-10 8:53 ` Keyword args (was: Return) Helmut Eller
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Colascione @ 2010-12-10 7:42 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
On 12/7/10 8:30 AM, Stephen J. Turnbull wrote:
> David Kastrup writes:
>
> > I don't think anybody minds the features.
>
> IIRC rms has recently declared his dislike for CL-style keyword
> arguments. I suppose that's part of the "syntactic complexity" you
> mention, but MON KEY OTOH points out cases where he'd like to use
> them. So there are some fundamental disagreements here.
I'd just like to add my support for keyword arguments. Functions like
write-region are both horrible and brittle because their parameters are
both numerous and overloaded; specific functionality can be more simply
expressed with using keyword arguments. Precedent can be seen in
play-sound, defcustom, and elsewhere. The performance arguments opposing
keyword arguments don't seem to be supported by benchmarks, and in any
case, most functions, especially ones with rich functionality, aren't on
the fast path.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Keyword args (was: Return)
2010-12-10 7:42 ` Return Daniel Colascione
@ 2010-12-10 8:53 ` Helmut Eller
2010-12-13 2:10 ` Keyword args Daniel Colascione
0 siblings, 1 reply; 7+ messages in thread
From: Helmut Eller @ 2010-12-10 8:53 UTC (permalink / raw)
To: emacs-devel
* Daniel Colascione [2010-12-10 07:42] writes:
> On 12/7/10 8:30 AM, Stephen J. Turnbull wrote:
>> David Kastrup writes:
>>
>> > I don't think anybody minds the features.
>>
>> IIRC rms has recently declared his dislike for CL-style keyword
>> arguments. I suppose that's part of the "syntactic complexity" you
>> mention, but MON KEY OTOH points out cases where he'd like to use
>> them. So there are some fundamental disagreements here.
>
> I'd just like to add my support for keyword arguments. Functions like
> write-region are both horrible and brittle because their parameters are
> both numerous and overloaded; specific functionality can be more simply
> expressed with using keyword arguments.
You always have the option to make a macro with keyword arguments which
expands to a call to the "raw" function.
The only disadvantage of this approach is that macros can't be used with
higher order functions, ala mapcar. But keyword arguments a rarely
useful in that case.
> Precedent can be seen in play-sound, defcustom, and elsewhere.
For a bad example see make-network-process. That takes keyword
arguments but the keyword parsing is done in C and it doesn't do a good
job. It doesn't detect invalid keywords; doesn't detect conflicting
keys; some keys are documented to be ignored when some other keys are
supplied. It's very difficult to use. Correct keyword parsing in C is
difficult so I would vote against it.
Also note that defcustom is a macro and play-sound takes a plist. The
plist idiom is IMO superior to keywords. In particular passing
arguments along gets easier. E.g.
(defun foo (x y plist)
(bar x y)
(baz plist))
is IMO more readable than:
(defun* foo (x y &key key1 key2 key3)
(bar x y)
(baz :key1 key1 :key2 key2 :key3 key3))
or the rather silly
(defun* foo (x y &rest plist &key key1 key2 key3)
(bar x y)
(apply #'baz plist))
Since we have destructuring-bind parsing plists is not very hard.
> The performance arguments opposing
> keyword arguments don't seem to be supported by benchmarks, and in any
> case, most functions, especially ones with rich functionality, aren't on
> the fast path.
The sequence functions find, position, assoc*, member* etc. are on the
fast path. Ironically those are the functions where keyword args are
very useful because the meaning is relatively consistent.
Helmut
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Keyword args
2010-12-10 8:53 ` Keyword args (was: Return) Helmut Eller
@ 2010-12-13 2:10 ` Daniel Colascione
2010-12-13 8:30 ` Helmut Eller
2010-12-13 20:00 ` Andy Wingo
0 siblings, 2 replies; 7+ messages in thread
From: Daniel Colascione @ 2010-12-13 2:10 UTC (permalink / raw)
To: Helmut Eller; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 3712 bytes --]
On 12/10/10 12:53 AM, Helmut Eller wrote:
> * Daniel Colascione [2010-12-10 07:42] writes:
>
>> On 12/7/10 8:30 AM, Stephen J. Turnbull wrote:
>>> David Kastrup writes:
>>>
>>> > I don't think anybody minds the features.
>>>
>>> IIRC rms has recently declared his dislike for CL-style keyword
>>> arguments. I suppose that's part of the "syntactic complexity" you
>>> mention, but MON KEY OTOH points out cases where he'd like to use
>>> them. So there are some fundamental disagreements here.
>>
>> I'd just like to add my support for keyword arguments. Functions like
>> write-region are both horrible and brittle because their parameters are
>> both numerous and overloaded; specific functionality can be more simply
>> expressed with using keyword arguments.
>
> You always have the option to make a macro with keyword arguments which
> expands to a call to the "raw" function.
How many forwarder macros do you need to sufficiently cover the problem
space? Combinatorial explosion is a problem when the set of possible
inputs is large.
> The only disadvantage of this approach is that macros can't be used with
> higher order functions, ala mapcar. But keyword arguments a rarely
> useful in that case.
You're mostly right, though it's not impossible to imagine a situation
in which it's useful to APPLY a keyword-argument-parsing function.
>> Precedent can be seen in play-sound, defcustom, and elsewhere.
>
> For a bad example see make-network-process. That takes keyword
> arguments but the keyword parsing is done in C and it doesn't do a good
> job. It doesn't detect invalid keywords; doesn't detect conflicting
> keys; some keys are documented to be ignored when some other keys are
> supplied. It's very difficult to use. Correct keyword parsing in C is
> difficult so I would vote against it.
Clearly, the solution is more uniform keyword argument parsing; either
library functions in C could be provided, or make-network-process could
be made a Lisp keyword-parsing front-end for some horrible
%make-network-process that implements the functionality.
Still, most functions aren't written in C, and keyword parsing is easier
in Lisp.
> Also note that defcustom is a macro and play-sound takes a plist. The
> plist idiom is IMO superior to keywords. In particular passing
> arguments along gets easier. E.g.
>
> (defun foo (x y plist)
> (bar x y)
> (baz plist))
>
> is IMO more readable than:
>
> (defun* foo (x y &key key1 key2 key3)
> (bar x y)
> (baz :key1 key1 :key2 key2 :key3 key3))
>
> or the rather silly
>
> (defun* foo (x y &rest plist &key key1 key2 key3)
> (bar x y)
> (apply #'baz plist))
The apply example isn't that bad in my book, and most of the time, you
don't need to forward an arbitrary subset of keyword parameters to
another function anyway.
>
> Since we have destructuring-bind parsing plists is not very hard.
Sure, but putting them in the lambda-list is even easier for most cases,
especially when there aren't that many arguments. It's also easier to
document functions written with &key than it is to document equivalent
functions that do ad-hoc parsing.
>
>> The performance arguments opposing
>> keyword arguments don't seem to be supported by benchmarks, and in any
>> case, most functions, especially ones with rich functionality, aren't on
>> the fast path.
>
> The sequence functions find, position, assoc*, member* etc. are on the
> fast path. Ironically those are the functions where keyword args are
> very useful because the meaning is relatively consistent.
Compiler macros can eliminate the pain in this case.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Keyword args
2010-12-13 2:10 ` Keyword args Daniel Colascione
@ 2010-12-13 8:30 ` Helmut Eller
2010-12-13 20:00 ` Andy Wingo
1 sibling, 0 replies; 7+ messages in thread
From: Helmut Eller @ 2010-12-13 8:30 UTC (permalink / raw)
To: emacs-devel
* Daniel Colascione [2010-12-13 02:10] writes:
> On 12/10/10 12:53 AM, Helmut Eller wrote:
>> * Daniel Colascione [2010-12-10 07:42] writes:
>>
>>> On 12/7/10 8:30 AM, Stephen J. Turnbull wrote:
>>>> David Kastrup writes:
>>>>
>>>> > I don't think anybody minds the features.
>>>>
>>>> IIRC rms has recently declared his dislike for CL-style keyword
>>>> arguments. I suppose that's part of the "syntactic complexity" you
>>>> mention, but MON KEY OTOH points out cases where he'd like to use
>>>> them. So there are some fundamental disagreements here.
>>>
>>> I'd just like to add my support for keyword arguments. Functions like
>>> write-region are both horrible and brittle because their parameters are
>>> both numerous and overloaded; specific functionality can be more simply
>>> expressed with using keyword arguments.
>>
>> You always have the option to make a macro with keyword arguments which
>> expands to a call to the "raw" function.
>
> How many forwarder macros do you need to sufficiently cover the problem
> space? Combinatorial explosion is a problem when the set of possible
> inputs is large.
Exactly as many macros as you would be need keyword argument parsing
functions. Whether keywords are used for functions or macros makes no
difference to cover the "problem space" (which I presume is a better
interface to write-region).
Helmut
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Keyword args
2010-12-13 2:10 ` Keyword args Daniel Colascione
2010-12-13 8:30 ` Helmut Eller
@ 2010-12-13 20:00 ` Andy Wingo
2010-12-14 5:03 ` Miles Bader
1 sibling, 1 reply; 7+ messages in thread
From: Andy Wingo @ 2010-12-13 20:00 UTC (permalink / raw)
To: Daniel Colascione; +Cc: Helmut Eller, emacs-devel
On Mon 13 Dec 2010 03:10, Daniel Colascione <dan.colascione@gmail.com> writes:
> Clearly, the solution is more uniform keyword argument parsing; either
> library functions in C could be provided, or make-network-process could
> be made a Lisp keyword-parsing front-end for some horrible
> %make-network-process that implements the functionality.
FWIW, Guile supports keyword arguments natively. IMO the proper way to
do things is to keep a uniform calling convention, and allow procedures
to parse arguments themselves, with low-level support.
scheme@(guile-user)> (lambda* (#:key (foo 42)) foo)
$1 = #<procedure 1c2f080 at standard input:1:0 (#:key foo)>
scheme@(guile-user)> ,disassemble $1
Disassembly of #<procedure 1c2f080 at standard input:1:0 (#:key foo)>:
Here we have some instructions that aren't disassembled quite as
perspicaciously as one might like, but they take the args on the stack,
and shuffle the non-positional args up:
0 (assert-nargs-ge 0 0)
3 (bind-optionals/shuffle 0 0 0 0 0 1)
And here we bind keywords. This says "fetch the keywords from the
constant table at index 1, and scan the non-positional args for one
keyword, disallowing other keywords.
10 (bind-kwargs 0 1 0 1 0)
It's somewhat complicated code, but it's a const only borne by keyword
arguments. Here we have the code that initializes `foo' if it's not
given:
16 (reserve-locals 0 1)
19 (local-bound? 0)
21 (br-if :L111) ;; -> 29
25 (make-int8 42) ;; 42
27 (local-set 0) ;; `foo'
And finally (!) the main body:
29 (local-ref 0) ;; `foo'
31 (return)
Some tests:
> (define (fib n) (if (< n 2) 1 (+ (fib (- n 1)) (fib (- n 2)))))
> ,time (fib 35)
$1 = 14930352
clock utime stime cutime cstime gctime
2.99 2.99 0.01 0.00 0.00 0.00
> (define* (fibk #:key (n 0)) (if (< n 2) 1 (+ (fibk #:n (- n 1)) (fibk #:n (- n 2)))))
> ,time (fibk 35)
<stdin>:5:6: warning: possibly wrong number of arguments to `fibk'
While executing meta-command:
ERROR: Odd length of keyword argument list
> ,time (fibk #:n 35)
$2 = 14930352
clock utime stime cutime cstime gctime
5.01 4.99 0.00 0.00 0.00 0.00
FWIW on this machine a byte-compiled elisp (fib 35) on emacs takes about
6 seconds.
I wrote more about this sort of thing here:
http://wingolog.org/archives/2009/11/07/case-lambda-in-guile
http://wingolog.org/archives/2009/11/08/optionals-keywords-oh-my
Our elisp support uses this native infrastructure for keywords and
optionals, but there obviously are some differences regarding
implementation of dynamic scope. Lexical binding is a lot cheaper, for
Guile, but we hope to get dynamic binding cheap too.
Anyway, I would like to discourage complicated implementations in
"user-space" for keyword arguments. They should be a core language
feature, for all the reasons I gave in my first article.
Happy hacking,
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Keyword args
2010-12-13 20:00 ` Andy Wingo
@ 2010-12-14 5:03 ` Miles Bader
2010-12-14 7:43 ` Helmut Eller
0 siblings, 1 reply; 7+ messages in thread
From: Miles Bader @ 2010-12-14 5:03 UTC (permalink / raw)
To: Andy Wingo; +Cc: Helmut Eller, Daniel Colascione, emacs-devel
Andy Wingo <wingo@pobox.com> writes:
> Anyway, I would like to discourage complicated implementations in
> "user-space" for keyword arguments. They should be a core language
> feature, for all the reasons I gave in my first article.
well... I agree, mostly (though that doesn't mean I agree that many
primitives in elisp should _use_ keywords, e.g. to the extent that CL
does).
Another perhaps-useful concept is alternate function entry points for an
"already handled" argument form (my vague memory is that CMUCL does
this). In many cases the compiler could then do argument parsing at
compile time and generate a call to the "simple" entry point.
-Miles
--
Consult, v.i. To seek another's disapproval of a course already decided on.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Keyword args
2010-12-14 5:03 ` Miles Bader
@ 2010-12-14 7:43 ` Helmut Eller
0 siblings, 0 replies; 7+ messages in thread
From: Helmut Eller @ 2010-12-14 7:43 UTC (permalink / raw)
To: emacs-devel
* Miles Bader [2010-12-14 05:03] writes:
> Another perhaps-useful concept is alternate function entry points for an
> "already handled" argument form (my vague memory is that CMUCL does
> this). In many cases the compiler could then do argument parsing at
> compile time and generate a call to the "simple" entry point.
CMUCL does compile-time keyword parsing only for the local-call
convention, i.e. if the callee is known and doesn't change. It's not
done for a normal call to a named global function; that uses the generic
slow entry point. If all call-sites were known (say recorded in a
linkage table) and could be patched on redefintion a more direct entry
point could be used more often, but CMUCL doesn't do that. So, I think
compile-time keyword parsing is rarely done in practice.
Helmut
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-12-14 7:43 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-12 17:01 Keyword args MON KEY
-- strict thread matches above, loose matches on Subject: below --
2010-12-12 4:49 Keyword args (was: Return) MON KEY
2010-12-12 8:34 ` Keyword args Helmut Eller
2010-12-05 23:55 Return MON KEY
2010-12-06 1:48 ` Return Stephen J. Turnbull
2010-12-06 5:50 ` Return MON KEY
2010-12-06 7:20 ` Return Stephen J. Turnbull
2010-12-07 2:42 ` Return MON KEY
2010-12-07 14:34 ` Return Stephen J. Turnbull
2010-12-07 15:54 ` Return David Kastrup
2010-12-07 16:30 ` Return Stephen J. Turnbull
2010-12-10 7:42 ` Return Daniel Colascione
2010-12-10 8:53 ` Keyword args (was: Return) Helmut Eller
2010-12-13 2:10 ` Keyword args Daniel Colascione
2010-12-13 8:30 ` Helmut Eller
2010-12-13 20:00 ` Andy Wingo
2010-12-14 5:03 ` Miles Bader
2010-12-14 7:43 ` Helmut Eller
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.