rur...@xarch.tu-graz.ac.at (Reini Urban) writes: > Tim Bradshaw wrote: > >(and, in a slightly alternative universe, you rule out LET too...).
> You know, I've always had a bad feeling about LET too :)
> I cannot create bindings just for debugging purposes by marking the > binding form with the mouse and evaluate it. With the let syntax this is > impossible. With &aux and following setq's it is possible.
Uh, in the olden days, when life was better, we used to not depend so heavily on "marking" as our only programming tool. If you're using Emacs, which is extensible and customizable, or any of many vendor-specific clones that are equivalent [just to drive home the point that it has nothing to do with free software], you can just write something which does the action you want on LET. The Lisp Machine has a number of little commands that manipulate forms and do interesting things with them before executing. For example, I'm pretty sure (because I think I wrote the code) that the LispM's macroexpand command (c-sh-M) will not only macroexpand the following form but will do it in a context where all of the textually visible containing macrolets are active because it used to bug me that I couldn't debug my local macros. If you just focus on complaining about local macros as "thwarting easy debugging", you'd miss out on the fact that the language is designed in a way to support flexible ways to help you. I just had the editor do a series of up-s-expression (c-m-u) commands, looking for macrolet and pasted together an appropriate expression that did something like (eval `(macrolet ,containing-macros (macrolet ((my-macroexpand (form &environment env) `',(macroexpand-1 form env))) (my-macroexpand ,macro-to-expand)))) or some such thing. can't remember exactly and am doing it off top of my head. The point is you can do a similar emacs-like command which does evaluate-let-body as a special command and which reconstructs the relevant bindings + setq. For some reason, there has been a decline in this kind of thing in recent years, I suspect because everyone got so Paste-happy. But I don't understand it really because Paste is so mouse-motion-intensive and that aggravates carpal tunnel syndrome, which a lot of people have. Good Emacs commands take about one or two characters to type on the home row of keys and because of the often-despised Lisp syntax with careful balancing of everything can exactly determine what region of text is to be manipulated without having to actually designate a region with the mouse.
> let* and efficiency > i really don't know if the expansion of LET* (into to nested lambdas) is > a good thing or if it should be a special form instead,
I don't understand this remark. The language does not forbid it from being compiled as a special form. The language is carefully designed to say that the availability of the macro is just so that if you're wanting to write code that assumes a minimum number of special forms, you can. But implementations can always offer more special forms as long as it also offers macro definitions for them for the sake of programs that don't expect them. It's hard to imagine how this can be bad. Did you read about the definition of special forms in the HyperSpec?
> lambda > might have some overhead which is not needed in the context of LET*. (?) > but I might be wrong. binding in sequence might require a full LAMBDA to > be correct. > (I don't have SICP or WINSTON/HORN here in the office to prove it by > myself, so I have to sleep over it)
Um, SICP is hardly an authority on Lisp. In Scheme, LET and LAMBDA have a very simple relationship.
In Lisp, the used to be simply related but are less so now. The primary difference is that declaration scoping is managed in an odd way that makes the rewrite possible but a little trickier than it is in Scheme or was in Maclisp before CL. Consider: (let ((x y)) (declare (special x y)) (f)) The "meaning" of this is: ((lambda (x) (declare (special x)) (f)) (locally (declare (special y)) y)) In Scheme, there is no declaration facility, so they skirt issues like this. Although declarations complicate Lisp, I think it's worth these small prices to have declarations. Declarations allow you to tell compilers things that type inferencing and other techniques either could not figure out or would not typically figure out or that might take too long time to figure out, and that often the user actually does know and can easily provide, so it seems sensible to provide a mechanism for him to do that providing.
* Iver Odin Kvello <iv...@hfstud.uio.no> | Gambit Scheme ... | | Also, in the R5RS under 6.3.3, Symbols: "Some implementations have | 'uninterned symbols' ...".[2]
we're talking about the _language_ Scheme, here. you just can't base a _language_ feature on something that only exists in some implementations, and you certainly can't dismiss it as if the existence of implementations that go way beyond the standard is a feature of the language. quite the contrary in my view. so I'm being anal and discuss the language as per specification.
| The program-as-text thing of the RnRS is pretty strange though; I've | never seen any real argument of why it's supposed to be a good idea[4].
well, it does make it much easier to construct tools for it in non-Lisp languages, using lex/yacc, and more "usual" compiler techniques.
| DEFMACRO obviously isn't a safe-syntactic-abstraction-Right-Thing all by | itself, but it seems pretty Right-Thingish anyway, given what it can do.
I agree with this, but I also think it is sometimes impossible to get it all at once, and when this is the case, it's more important to settle on _something_ and agree that the issue has been settled than to oscillate between things you never settle on.
#:Erik -- it's election time in Norway. explains everything, doesn't it?
Gareth McCaughan <Gareth.McCaug...@pobox.com> writes: > Kent M Pitman wrote:
> > The thing that I value the most about CL and > > its community is its ability to embrace multiple concepts and multiple > > ways to think about things;
> Well, since R5RS Scheme has had multiple values too, so perhaps > things are getting better in that camp. :-)
for the benefit of the Italians... dopo sette fette... :)
Cheers (apologies for the noise)
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
> I have no problem with this kind of characterization of > Scheme. Scheme is indeed unusable for many, nay, most > purposes. As I said earlier, my response to Kent is > not a defense of Scheme or the Scheme community at all. > Heck, it is not even a defense of hygienic macro > systems.
> Something very strange is going on in this thread.
It is a simple Internet phenomena. I got caught in it myself. Your post in reply to KMP, "sounded" horrifying to a lot of the readers of CLL. That's all.
Now we can all go and have a bottle of Chianti.
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
Reini Urban writes: > >(asetf (second list) (+ it 7))
> please not THIS. "Where comes this 'it' from?" a newbie would ask. > no magic names please. perl already has too much. this makes lisp way > too perl'ish.
BTW, such anaphoric macros can be recast in a more defensive, while slightly more circumstantial, form that explicitly passes IT as an argument to a one-place function:
(asetf (second list) (lambda (it) (+ it 7)))
or, according to taste,
(asetf (second list) => (lambda (snd) (+ snd 7)))
(The ornamental "=>" is stolen from Scheme's alternative COND form.)
> >>>>> "EN" == Erik Naggum <e...@naggum.no> writes:
> EN> lexical, and if Scheme had had DEFMACRO, it would have been > EN> tremendously dangerous, since it couldn't possibly be safe in > EN> Scheme, lacking all the machinery.
> Gambit Scheme has no hygienic macro system built-in; it does however > have a DEFMACRO-like system with gensym and all the necessary > machinery. This is essentially no more a problem[1] than it is in CL (and in > my opinion, this means not a problem at all.).
Why use Gambit-Scheme if you cannot even port programs written for a RxRS Scheme to it?
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> writes: > Iver Odin Kvello <iv...@hfstud.uio.no> writes:
> > >>>>> "EN" == Erik Naggum <e...@naggum.no> writes:
> > EN> lexical, and if Scheme had had DEFMACRO, it would have been > > EN> tremendously dangerous, since it couldn't possibly be safe in > > EN> Scheme, lacking all the machinery.
> > Gambit Scheme has no hygienic macro system built-in; it does however > > have a DEFMACRO-like system with gensym and all the necessary > > machinery. This is essentially no more a problem[1] than it is in CL (and in > > my opinion, this means not a problem at all.).
> Why use Gambit-Scheme if you cannot even port programs written for > a RxRS Scheme to it?
Gambit claims to be R4RS supporting, so I don't see why one could not run, no porting needed, R4RS programs on it. I run R4RS programs on several scheme that support defmacro like extensions and many other additions to RxRS. With packages like SLIB, one can even run defmacro using programs on a large number of scheme implementations without porting. So, I cannot make sense of your rhetorical question.
-- Craig Brozefsky <cr...@red-bean.com> Free Scheme/Lisp Software http://www.red-bean.com/~craig "riot shields. voodoo economics. its just business. cattle prods and the IMF." - Radiohead, OK Computer, Electioneering
* Reini Urban | please not THIS. "Where comes this 'it' from?" a newbie would ask. no | magic names please.
& <37da49ca.182323116@judy> | I do care about newbie's (the AutoLISP crowd) who should be able to | understand a macro system (easy) and write correct code then (hard).
I fail to see why it is necessary or even useful to bring this mythical newbie into design discussions. it's like targeting political campaigns _only_ towards first-time voters, or making TV shows only for people who have never seen the show before. the most common effect of all this focus on beginners is that more experienced users go elsewhere, mostly because in newbie-friendly things you are unable to grow beyond a certain, low point. call it the beginner's glass ceiling, if you want.
#:Erik -- it's election time in Norway. explains everything, doesn't it?
[A good post, with some interesting references; my replies here are not so much to you personally as to the thread generally based on a few things you said. Please don't take any of this as me jumping on you personally; I'd like to avoid another go-around like the last one.]
> Also, in the R5RS under 6.3.3, Symbols: "Some implementations have > 'uninterned symbols' ...".[2]
The formal meaning of this (since I think the Schemer community is big on formal meaning) is that "Scheme does not require uninterned symbols". In case it's not obvious, the set of things Scheme does not require is quite large (one might say "unbounded"); if one can count ever non-required feature of Scheme to its credit, then let's count every non-required feature of CL to its credit, too. Now we're comparing infinities. What fun.
The fact is that there exist some quality Scheme implementations. I have always felt that the quality of Scheme implementations far exceeded the quality of the Scheme language. In oh so many cases, Scheme the Language is fully silent on things that are absolutely necessary for any kind of portably useful outcome; that doesn't mean there aren't useful programs you can write in portable Scheme, but it means that that set is much, much smaller than the set of useful programs you can write in non-portable Scheme. By the same metric, every feature of the Lisp Machine can be counted as a feature of "common lisp", since the Lisp Machine is compliant and just has "a few extra bells and whistles". But what's the point of that?
> The 'problem of unintentional capture' still remains if you accept, as > some must have done, that the possibility of this is a problem in and > of itself
All languages are inherently a problem if people don't use the language primitives in ways that avoid bugs. You should be careful with this. Even without appealing to macros, Scheme is no more safe the Common Lisp against "fencepost errors" either (even with tail recursion :-).
Scheme is not immune to "unintentional capture", it's only immune to a specific kind of unintentional capture that occurs when you arrange things just so. For example, in Scheme you can write: (define (foo list) (list list list)) and if you didn't mean to capture the list function, you've unintentionally captured it. People have in the literature defined this form to mean "intentional capture"(TM) but that's idealizing the world to assume people will make no programming mistakes. I think the whole English meaning of "unintentional" has to include the possibility tht the programmer will space out and don the wrong thing sometimes. If it does not, then unintentional capture will never happen anyway since he will never use macros in the first place in any situation that has the potential for unintentional capture.
* Reini Urban | i really don't know if the expansion of LET* (into to nested lambdas) is | a good thing or if it should be a special form instead, which can bind | in sequence internally without having to call nested lambdas.
I don't think we're in Scheme-land, anymore, Toto.
LET* _is_ a special operator in Common Lisp.
#:Erik -- it's election time in Norway. explains everything, doesn't it?
>>>>> "MA" == Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> writes:
MA> Why use Gambit-Scheme if you cannot even port programs written MA> for a RxRS Scheme to it?
You can though, since there is some stuff available that implements one of the hygienic systems, I forget which. And it has some pretty good other features too - nice FFI and so on. My kind of macros. Compiles to C, portable. Could be useful if you ever needed continuations or something like that.
But I don't use it; I use CL. Not that I can port RxRS programs to *that*, but hey, I'll live.
>>>>> "EN" == Erik Naggum <e...@naggum.no> writes:
EN> * Iver Odin Kvello <iv...@hfstud.uio.no> EN> | Gambit Scheme ... EN> | Also, in the R5RS under 6.3.3, Symbols: "Some EN> | implementations have 'uninterned symbols' ...".[2]
EN> we're talking about the _language_ Scheme, here. you just EN> can't base a _language_ feature on something that only exists EN> in some implementations, and you certainly can't dismiss it as EN> if the existence of implementations that go way beyond the EN> standard is a feature of the language. quite the contrary in EN> my view. so I'm being anal and discuss the language as per EN> specification.
Well, I'll accept that at least for the sake of this argument. I'm only arguing that this construct is possible; that is compatible with the standard. This is of course a pretty remote what-if scenario, but I still think one could fit a DEFINE-MACRO into scheme-as-described: uninterned symbols are explicitly allowed; and the resulting expanded list (data) created could 'represent' code in the same way as the expression argument to eval.
It would be a bit harder to get this to seem neat though - I'm not prepared to defend this aspect of Scheme at all, so feel free to rip it up.
Gambit, by the way, doesn't cheat at this; it really treats programs according to the standard. This is what Gambit does when given non-program-syntax input:
> '(cons 'a . ('b)) (cons 'a 'b) > (cons 'a . ('b)) *** ERROR IN (stdin)@13.1 -- Ill-formed procedure call
This is Allegro CL for comparison:
USER(1): (cons 'a . ('b)) (A . B)
Here is Gambit again, doing eval (Gambit allows omitting the enviroment argument)
> (eval '(cons 'a . ('b))) (a . b)
and again, define-macro:
> (define-macro (boing x y) `(cons ',x . (',y))) > (boing a b) (a . b)
* Iver Odin Kvello <iv...@hfstud.uio.no> | But I don't use it; I use CL. Not that I can port RxRS programs to | *that*, but hey, I'll live.
would it really be useful to do that? SIOD (Scheme In One DEFUN) was a Scheme-in-Common-Lisp. maybe there's still something around that can do it for you.
#:Erik -- it's election time in Norway. explains everything, doesn't it?
On 11 Sep 1999 15:34:24 +0000, Erik Naggum <e...@naggum.no> wrote:
> we're talking about the _language_ Scheme, here. you just can't base a > _language_ feature on something that only exists in some implementations, > and you certainly can't dismiss it as if the existence of implementations > that go way beyond the standard is a feature of the language. quite the > contrary in my view. so I'm being anal and discuss the language as per > specification.
One of the major goals with Common Lisp was portability between different lisps, so features that only exist in some implementations weighs lightly when one is assessing that language.
RxRS, however, has partially different goals. From the "Backgroud" section:
>As Scheme became more widespread, local dialects began to diverge until students and researchers occasionally found it difficult to >understand code written at other sites. Fifteen representatives of the major implementations of Scheme therefore met in October >1984 to work toward a better and more widely accepted standard for Scheme.
Thus, the purpose of RxRS is not to define a langage rich enough that all interesting programs can be written portably in it, but rather to define a common subset, so that programs written in the different dialects of Scheme that is defined by the different Scheme implementations are intelligable to all members of the Scheme community.
And so, a discussion of Scheme not only can, but must, take into account the different features that exists in the various dialects. Most comparisons between the "pure", "standard", RxRS version and other programming languages will be to Scheme's disadvantage, since almost no real programs can be written in that bare-bones intersection between living languages (and almost none are).
Erik Naggum <e...@naggum.no> writes: > * Iver Odin Kvello <iv...@hfstud.uio.no> > | But I don't use it; I use CL. Not that I can port RxRS programs to > | *that*, but hey, I'll live.
> would it really be useful to do that? SIOD (Scheme In One DEFUN) was a > Scheme-in-Common-Lisp. maybe there's still something around that can do > it for you.
Jonathan Rees's pseudoscheme runs fine in CL. We use intermixed Scheme and CL for our projects.
Erik Naggum <e...@naggum.no> wrote: > * Iver Odin Kvello <iv...@hfstud.uio.no> > | But I don't use it; I use CL. Not that I can port RxRS programs to > | *that*, but hey, I'll live.
> would it really be useful to do that? SIOD (Scheme In One DEFUN) was a > Scheme-in-Common-Lisp. maybe there's still something around that can do > it for you.
* Kent M Pitman <pit...@world.std.com> | It's also "cambridge common lisp" (an old name for Hqn's lisp, I think; | lots of Harlequin system code uses #+ccl/#-ccl. sigh.)
OK, I know what I want for the "revision" of ANSI Common Lisp: the specification of a registry of feature symbols, to be handled by a registration authority. this could also be an additional standard.
the registry would have to pre-register all known feature symbols and accept collisions but also list how to disambiguate, but no new features should collide.
#:Erik -- it's election time in Norway. explains everything, doesn't it?
vilh...@home.se (Vilhelm Sjöberg) writes: > Thus, the purpose of RxRS is not to define a langage rich enough that > all interesting programs can be written portably in it, but rather to > define a common subset, so that programs written in the different > dialects of Scheme that is defined by the different Scheme > implementations are intelligable to all members of the Scheme > community. > And so, a discussion of Scheme not only can, but must, take into > account the different features that exists in the various dialects.
No. It needn't must. It could and I think should just assume that the Scheme people had no interest in those features and any argument that hinges on things in implementations but not the spec should be lost by default.
> Most comparisons between the "pure", "standard", RxRS version and > other programming languages will be to Scheme's disadvantage,
As well it should be, since the Scheme community voluntarily elected this.
> since > almost no real programs can be written in that bare-bones intersection > between living languages (and almost none are).
That's the bed that the Scheme designers made and now they must lie in it. This is not some after-the-fact trap they didn't anticipate and are being unfairly tossed into. This is a set of issues they knew would come up and said they were comfortable not addressing.
I was at those design meetings. I suggested the language should be more detailed in order to be more portable but that didn't enthuse anyone. I would characterize the issue as overzealous pride in the shortness of the document and a stubborn unwillingness to risk increasing the size of the document in order to make it more clear. My specific recollection is of how proud some of them were that they had had to pad the document with other text not related to the spec in order to make it thick enough to bind. I found that ridiculous and more than a little objectionable since I disagreed with some of the extra filler text they jammed into some of the documents, which appeared by its placement in a document with my name on it to have my endorsement. No vote was taken to do that--someone just made that decision without actually asking the group. I just double-checked and there's a note on page 45 of R3RS which mentions this issue of the pagecount.
So it's possible that some individual designers objected, as I did, and I don't mean to speak for them as individuals, but it seems to me that as a body of the whole, the Scheme designers elected the "shortness of the document" as a primary design criterion, and IMO they ought to be judged on the basis of this as a primary criterion, not given a pass on it. They had other options and voluntarily and knowingly elected not to pursue them.
At one of the later meetings, I think, after CL had been deployed for a while, I recall specifically cited the bad experiences we'd had with porting CL in the early days and suggested that Scheme should learn form this and nail things down. People were more concerned with Scheme as a vehicle for targeting textbooks, at which they succeeded well. If you think Scheme is about "concepts", then maybe it's succeeded; if you think it's about sharing programs across implementations, I think it's not done as well. I think it's a shame that those concepts don't translate themselves into portable practice when they easily could have.
In general, the Scheme design committee bogged down on the simplest of issues because it had a terribly conservative voting process that required all designers to agree. For years we were deadlocked over whether to accept (define (foo x) x) as a synonym for (define foo (lambda (x) x)), because some weren't sure that the former was conservative enough. And, of course, there was a split for years about NIL vs (). So you can imagine the difficulty of getting other changes in...
If the Scheme community wants as a body of the whole to care about PRACTICAL effects in languages, like porting issues, they have to write a document that addresses that. IMO, to date, they have not. Individual Scheme dialects do care about practicalities, and as I've said, I have a great deal of respect for the work some vendors have put into their implementations. But the language/spec is a different matter from implementations.
Or so I think. And we all know that people don't always agree with me. I've been at the Scheme meetings and listed as an author since R2RS, but it's fair to say my opinions on most topics are not always regarded as the "mainstream" point of view. I'm sure there's another point of view to be had on all of this--but I'm afraid mine is the only one I have easy access to offer... Just don't think I speak for the committee; I speak only for myself and whatever peculiar bias I bring to the table based on my experiences over here in CL-land.
> So it's possible that some individual designers objected, as I did, > and I don't mean to speak for them as individuals, but it seems to me > that as a body of the whole, the Scheme designers elected the > "shortness of the document" as a primary design criterion, and IMO > they ought to be judged on the basis of this as a primary criterion, > not given a pass on it. They had other options and voluntarily and > knowingly elected not to pursue them.
Hey! You stole my idea for a posting. :)
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
>> I have no problem with this kind of characterization of >> Scheme. Scheme is indeed unusable for many, nay, most >> purposes. As I said earlier, my response to Kent is >> not a defense of Scheme or the Scheme community at all. >> Heck, it is not even a defense of hygienic macro >> systems.
>> Something very strange is going on in this thread.
>It is a simple Internet phenomena. I got caught in it myself. Your >post in reply to KMP, "sounded" horrifying to a lot of the readers of >CLL. That's all.
>Now we can all go and have a bottle of Chianti.
Thanks, Marco. And sorry for calling you Mario. It was an unintent (I guess I tend to visualize you as a Cipollini rather than a Pantani. :-> )
