* Keyword args (was: Return)
@ 2010-12-12 4:49 MON KEY
2010-12-12 8:34 ` Keyword args Helmut Eller
0 siblings, 1 reply; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ messages in thread
* Keyword args (was: Return) 2010-12-10 7:42 ` Return Daniel Colascione @ 2010-12-10 8:53 ` Helmut Eller 0 siblings, 0 replies; 3+ 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] 3+ messages in thread
end of thread, other threads:[~2010-12-12 8:34 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-12 4:49 Keyword args (was: Return) MON KEY 2010-12-12 8:34 ` Keyword args Helmut Eller -- strict thread matches above, loose matches on Subject: below -- 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
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.