Tim Bradshaw <t...@tfeb.org> writes: > Kent M Pitman <pit...@world.std.com> writes:
> > Anything strikes *me* as hard to serialize because Lisp is a > > language that cares about identity. Just because you can make a > > new object doesn't mean it's the same object. Object sharing is > > often critical for any object, and there is no backpointer from an > > objecto to the things tha tpoint into it. I marvel that people > > are able to do as much serialization as they do in other > > languages, and find myself wondering if this is because they are > > told not to rely on object identity when doing their programming > > originally.
> I've always been terrified by this kind of thing. Java makes > serialisation claims, and I really have now idea what it does. Either > it does it wrong, or as far as I can see you need to keep something > like an EQL hashtable of everything-you-have-ever-serialised and use > that to maintain EQLness on the far side. Which is expensive.
> I suspect - like you perhaps - that object identity is not so much > relied-on in some other languages. Perhaps this is because > object-ownership issues are so bad in a non-GCd language that it's > less painful to copy things all the time. Presumably this has > persisted in java for cultural reasons...
> (a CORBA person is now going to explain how it solves all these > problems at a stroke, I can feel it...)
Perhaps they (either Java or CORBA or anything else that thinks serialization can work reliably) take as axiomatic the idea that serialization does or must work and consider that any data structure you make that cannot be serialized is the error.
In article <sfwn17d7hho....@world.std.com>, Kent M Pitman <pit...@world.std.com> wrote:
>Perhaps they (either Java or CORBA or anything else that thinks >serialization can work reliably) take as axiomatic the idea that >serialization does or must work and consider that any data structure >you make that cannot be serialized is the error.
I think this is a likely case for any distributed data architecture. It's also pretty common in database architectures. Rather than worrying about object identity provided at the language level, data is often self-identifying; for instance, in a banking application, the object representing an account will include an account number slot, and a relational database used to manage the accounts would probably declare this as a unique index.
A serialization libary could be designed to know which slots in an instance correspond to the unique index, and it could then automatically intern objects in a hash table as it serializes them, and look them up when reading them back in (this would be a good use of weak hash tables -- if all other local references to the instance have been discarded, it doesn't matter whether the reader returns a new object, as there's nothing to compare EQL to).
-- Barry Margolin, bar...@genuity.net Genuity, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> Perhaps they (either Java or CORBA or anything else that thinks > serialization can work reliably) take as axiomatic the idea that > serialization does or must work and consider that any data structure > you make that cannot be serialized is the error.
Maybe they are even right, I'm not sure. A system which does not rely on object identity can scale to platforms - like shared-nothing machines - where object identity is hard to maintain. On the other hand, at the platform level, shared-memory machines, which can maintain identity at the this-points-to-that level, have pretty much demolished non-shared-memory machines, so I guess *someone* cares.
Sometimes I think that Lisp people have a distorted view because we use a lasnguage which is *so* good at dealing with enormous complex datastructures, that we've been spoiled. After all everything is a string...
Ray Blaak <bl...@infomatch.com> writes: > Yes there is an echo. Sorry. That's what I get for too much speed reading of > large Usenet feeds.
Heh, no sweat.
> Do you have some pointers discussing the Bawden "syntactic closure" route?
I don't. Maybe a web search would find something. But I develoepd the same concept for myself around the same time and never published anything on it, so I can sketch what *I* meant; I'm pretty sure Bawden's was similar. The essential difference between in and painting was to place the burden on the macro implementor for "closing" certain terms.
In effect, what you want to do "conceptually" is (defmacro first (x) `(,#'car ,x)) That is, you want to grab the "meaning" of car and expand into that. Since this doesn't work for special forms, you would probably really need something like (defmacro first (x &environment env) `(,(meaning-of #'car env) ,x)) In that way, (first car) => (#<meaning-of #'car #<macro-env>> car) and you don't get confusion. It may feel a lot like painting, but it does no tree-walking and no invasion of quoted structure. It also means you could have a mention of meaning-of that was suppressed by quotation until the right evaluation context.
There are various kinds of syntactic sugar you can put on this, like having a code-walker that can turn `(car ,x) into (list (meaning-of 'car env) x) But this would again not walk quoted structure becuase it would want to stop at quoted levels.
Yet another way for it to work is to have (defmacro first (x) `(car ,x)) receive as an argument not CAR in the case of (FIRST CAR), but instead a gensym or other special-typed object which was opaque to the macro and which was, in effect, pre-painted. In that way, `(car ,x) => (CAR #:FIRST-ARG-7383) What this makes difficult is the building of macros that care about the "shape" of the actual argument; you cannot have a macro system that receives proxies as args instead of the real arg UNLESS you also have a function on the proxy that returns the ACTUAL argument also, thus letting you pierce the veil of abstraction if you want.
So you can see there are about a half-dozen different ways you can implement this, but the basic idea is to allow programmer-managed resolution of the name-closing instead of system-managed resolution.
Tim Bradshaw <t...@tfeb.org> writes: > I've always been terrified by this kind of thing. Java makes > serialisation claims, and I really have now idea what it does. Either > it does it wrong, or as far as I can see you need to keep something > like an EQL hashtable of everything-you-have-ever-serialised and use > that to maintain EQLness on the far side. Which is expensive.
I think that's exactly what they do. A lot of the work on Java's RMI came from Modula-3 and in the paper at http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-... you'll find a description of how this works. At page 10 you'll find the algorithm used to do this serializing (or pickling in Modula-3 terminology). Research report 116 describes the distributed garbage collection that allows objects to be gc-ed after all references on all servers are gone.
-- Lieven Marchand <m...@wyrd.be> Making laws appears to win votes. Enforcing them doesn't. See Rule One. Roger Burton West in the monastery.
On Tue, 12 Jun 2001 13:31:03 GMT, Kent M Pitman <pit...@world.std.com> wrote:
> Anything strikes *me* as hard to serialize because Lisp is a language that > cares about identity. Just because you can make a new object doesn't mean
Hasn't Lisp been doing it right all the time with image dumping? :)
Tim Bradshaw <t...@tfeb.org> writes: > Kent M Pitman <pit...@world.std.com> writes:
> I suspect - like you perhaps - that object identity is not so much > relied-on in some other languages. Perhaps this is because > object-ownership issues are so bad in a non-GCd language that it's > less painful to copy things all the time. Presumably this has > persisted in java for cultural reasons...
> (a CORBA person is now going to explain how it solves all these > problems at a stroke, I can feel it...)
I don't know if I'd call myself a "CORBA person", but, FWIW, I've been using for a couple of years. My take is CORBA solves this by not solving it; i.e. you don't actually serialize the object; you just pass a _reference_ to an object to another process. But there's still only 1 object¹, in one image, somewhere, on 1 computer, which _is_ the object (the Servant, in CORBA terms).
There's this method is_equivalent (if memory serves right) that you can call on any 2 corba references which pretty much means what the lisp EQ means.
Or am I just adding to the confusion? :-)
¹ Yes, I know that one servant can be made to mimic the identity of several corba objects, but that's just a distraction for this argument.
-- It would be difficult to construe Larry Wall, in article this as a feature. <1995May29.062427.3...@netlabs.com>
Alain Picard <apic...@optushome.com.au> writes: > I don't know if I'd call myself a "CORBA person", but, FWIW, I've > been using for a couple of years. My take is CORBA solves this > by not solving it; i.e. you don't actually serialize the object; > you just pass a _reference_ to an object to another process. > But there's still only 1 object¹, in one image, somewhere, on 1 > computer, which _is_ the object (the Servant, in CORBA terms).
So this is kind of shared-memory at the application level?
Alain Picard <apic...@optushome.com.au> writes: > I don't know if I'd call myself a "CORBA person", but, FWIW, I've > been using for a couple of years. My take is CORBA solves this > by not solving it; i.e. you don't actually serialize the object; > you just pass a _reference_ to an object to another process. > But there's still only 1 object¹, in one image, somewhere, on 1 > computer, which _is_ the object (the Servant, in CORBA terms).
Good points, but ...
If the original discussion was about how to offload resources from one machine to another, CORBA doesn't really do that, does it? The IOR has a pointer to machine and port and process, or some such, no? [Disclaimer: I've not used CORBA myself; I just took a several day seminar in its concepts. I think I'm conversational in it, but please do correct any confusions I might be displaying...]
I gather there is a migratable object substrate you can plug into CORBA but... (1) does this require the server you're trying to free up to handle forwarding service for this object? and (2) if you migrate the thing from its normal home, you have to refer to all other CORBA objects it thought were neighbors as remote handles, which might need migration, too, right? (3) And objects which are not addressed by IOR are assumed by "something you have to arrange for migration of", right? Which kind of begs the current question, right? Not to mention that even if you did migrate it, it might take as much network traffic to do that (CORBA being pretty network heavyweight) as it would take to finish out the burdensome pending request for HTTP service that you were trying to quickly offload... no?
> There's this method is_equivalent (if memory serves right) that > you can call on any 2 corba references which pretty much means > what the lisp EQ means.
But CORBA does not forbid machine-native references within the actual workerbee instance of the agent, right? So it still is up against the same question of "can this process migrate" unless it has built its entire programming framework on corba objects, which I had understood to be generally thought by CORBA users to be computationally too much overhead for anyone to do.
ap> My take is CORBA solves this by not solving it; i.e. you don't ap> actually serialize the object; you just pass a _reference_ to an ap> object to another process. But there's still only 1 object¹, in ap> one image, somewhere, on 1 computer, which _is_ the object (the ap> Servant, in CORBA terms).
tb> So this is kind of shared-memory at the application level?
at the middleware level, rather. Apart from latency and failure semantics, the fact that the invoked object is remote rather than local is transparent to the application level.
>>>>> "kmp" == Kent M Pitman <pit...@world.std.com> writes:
kmp> If the original discussion was about how to offload resources kmp> from one machine to another, CORBA doesn't really do that, does kmp> it? The IOR has a pointer to machine and port and process, or kmp> some such, no?
you can do simple load balancing at the time a client aquires the IOR, from a naming or trading service. Once an IOR has been aquired, an overloaded server can also redirect requests to another machine+port using a LOCATION_FORWARD message. The tricky bit is the state transfer between servants, which is done by the programmer (possibly assisted by the persistent state service).
kmp> But CORBA does not forbid machine-native references within the kmp> actual workerbee instance of the agent, right? So it still is kmp> up against the same question of "can this process migrate"
sure, CORBA doesn't magically make object migration transparent; the degree of explicit programmer support will depend on the programming language and operating system. In Lisp for example, how do you serialize network connections? Are threads which were waiting on semaphores restored correctly?
> at the middleware level, rather. Apart from latency and failure > semantics, the fact that the invoked object is remote rather than > local is transparent to the application level.
Sorry, I meant `application level' as meaning `not OS + hardware'.
> If the original discussion was about how to offload resources from one > machine to another, CORBA doesn't really do that, does it?
To my knowledge, it does not.
> The IOR has > a pointer to machine and port and process, or some such, no?
Correct.
I think a very common paradigm is that a CORBA object really reflects some state in a database somewhere. So in overload conditions, you might forward the request (as some other poster mentioned) and the other server would be able to instantiate a "copy" of the servant which pretends to have (or really has, depending on your viewpoint) the same identity as the one you were trying to talk to.
Which just punts on the hard issue: how do you replicate and load share the database? (Answer: you let your vendor do it).
To recapitulate: Lisp doesn't do proper serialization (with object identity) because it's too hard; and CORBA doesn't do it either. And I suspect, Kent, that your intuition is correct, Java (and Python, actually) people *think* they do proper serialization because they're not used to thinking of the identity of objects (the EQness) as lisp people are.
Maybe "lisp provides EQ", "Java only gives you EQUALP" ?
-- It would be difficult to construe Larry Wall, in article this as a feature. <1995May29.062427.3...@netlabs.com>
Alain Picard <apic...@optushome.com.au> writes: > To recapitulate: Lisp doesn't do proper serialization (with object > identity) because it's too hard; and CORBA doesn't do it either. > And I suspect, Kent, that your intuition is correct, Java (and Python, > actually) people *think* they do proper serialization because they're > not used to thinking of the identity of objects (the EQness) as lisp > people are.
> Maybe "lisp provides EQ", "Java only gives you EQUALP" ?
I think it's subtler than that.
Obviously Java passes pointers, even tagged ones, when it does function call. It's got EQ. However, there's probably something in the pain of type declaring that causes it not to be as densely interconnected as Lisp is, and this probably results in correspondingly less work in figuring out what to serialize. I bet it causes them to typically hold onto one "big" object with lots of parts rather than a lot of little objects, so when they seralize it's fewer things you have to make sure handle a "seralize" message.
It may also be that Java typically results in smaller and less complex programs than Lisp does, giving up on the larger ones or quietly giving up on serialization as a core technology of the larger ones.
> So, if you have an idea for a better way to write macros, > or a better way to teach how to write macros, please tell us.
No, I think in CL macros should remain the way they are. Standards should move slowly, and the last word is definitely not yet out on macro writing.
There are a few changes I would argue for if there had been no standard as yet, but then who hasn't :-)
The way of teaching that has worked best for me is: - explain the basics, - have people write a macro - write a context in which the macro fails - discuss. - repeat the above till macros start being in shape.
I have found this to work better than the other way around (discussing the pitfalls first).
Of course this does trigger the eternal question: but if Lisp is so much about "the programmer shouldn't have to care" (as with memory management and the like), then why do we have to care with all that here?
To which my answer is: research is still ongoing, and until it settles on a clear plateau, it is no use changing the standard. (Pointing to a few explorative implementations of different macro systems helps here. It helps people get a feeling of the issues that play.)
> It might not be an all-or-none thing, but I think it can't be argued > that the probabilities of collision are higher.
Yes, it is a difference of degree. As far as I can fathom, the real problem is what RPG calls the "Worse is better" vs. "The right thing".
I suppose no-one will seriously disagree with the statement that Scheme is more in the "The right thing" camp, and CL in the "worse is better" camp. Even a low probability is wrong if it can be reduced to zero, and the programmer shouldn't have to deal with that explicitly, a Schemer would argue. The probability is pretty low to start with, the CL replies, it is even lower because we have a second namespace, and to make it still lower we have introduced a third namespace, packages. (For a Schemer, these are basically glorified let constructs, of course, so this is a partial implementation of lexical scoping for macro variables.)
Oh, and you know this, of course, but probably some others don't: lexical scoping and hygiene are two separate issues in macrology.
> I suppose no-one will seriously disagree with the statement that > Scheme is more in the "The right thing" camp, and CL in the "worse > is better" camp.
I don't think the "worse is better" argument applies here at all.
> "David Thornley" <thorn...@visi.com> wrote in message > news:13bU6.10022$Dd5.2846360@ruti.visi.com... > > So, if you have an idea for a better way to write macros, > > or a better way to teach how to write macros, please tell us.
> No, I think in CL macros should remain the way they are. Standards > should move slowly, and the last word is definitely not yet out on > macro writing.
> There are a few changes I would argue for if there had been no > standard as yet, but then who hasn't :-)
Such as?
> The way of teaching that has worked best for me is: > - explain the basics, > - have people write a macro > - write a context in which the macro fails > - discuss. > - repeat the above till macros start being in shape.
There is no standard for teaching.
However, as I recall, some work in automated teaching the Open University agrees with you at least to some extent, for programming in general. I vaguely recall that they did some tests in how to explain programmer errors to people. As I recall, they found that saying "you have a fencepost error", however nice that feels to an experienced programmer, left the programmer confused. I think, if I remember this right, the issue is that for any new concept a user is struggling to use, the user is not fluent in the terminology which precisely describes and bounds the issues of that concept, so appealing to that terminology only begs the questions they have, and adds little insight. They found, I believe, that just saying "Your program fails for the following input: ...", while less abstract, was more reliably going to cause a lightbulb to go on in the new programmer's head.
I would add as an aside that this is probably a restatement of the claim by, I believe, Minsky, which goes something like "you can't learn a thing unless you almost already know it". You probably have to have seen the bug in practice in order to really internalize a name for it.
> I have found this to work better than the other way around (discussing the > pitfalls first).
Could be. But this IS a statement about teaching technique, not language definition, so is not at odds with anything in the language.
The language specification itself is not written to newbies. It is only a fortunate accident that as much of it as is readable is readable by newbies. And while other people may name their books using names like "ANSI Common Lisp", that doesn't mean they have an ANSI-approved teaching style.
> Of course this does trigger the eternal question: but if Lisp is so > much about "the programmer shouldn't have to care" (as with memory > management and the like), then why do we have to care with all that > here?
I can make no sense of "all that" in this context.
Bernie Greenberg, at the MIT Multics Group, used to teach a course in Lisp in which he used to always assert "a cons is an object that cares". But while programmers might not be supposed to care about GC and might be supposed to feel warm and fuzzy about conses going around caring for the things they point to, I don't think it would be reasonable to generalize it to say "programmers must always care" or "programmers must never care".
> To which my answer is: research is still ongoing, and until it settles on a > clear plateau, it is no use changing the standard.
You've spoken only about teaching in this message, yet you have made frequent use of the term "standard". I see no relation, either in practice nor any you've attempted to draw in the text. I'll stop short of drawing the perhaps-unwarranted conclusion that you are confusing the standard with some teaching text or that you think there can only be one way to teach it or that you think the standard somehow inhibits the way it can be taught.
Instead I'll just ask: what's your point?
> (Pointing to a few explorative implementations of different macro > systems helps here. It helps people get a feeling of the issues > that play.)
Implementations != languages.
Implementations don't decide languages.
Languages aren't decided on the basis of implementations.
One cannot have an "explorative implementation" of a language. A language is a fixed thing.
One CAN explore the possibility of using a different language by allowing an implementor to free him/herself of any concern about implementing any particular language.
One CAN allow the implementor the freedom to believe it's their right or responsibility to implement a macro system because someone forgot to.
But I think the truth is that there are several macro systems with pretty well-defined semantics that each language shops among when choosing which, if any, they will offer. We can discuss the features of those in the abstract, but we cannot discuss the efficacy of those in the abstract; that is, we need to see how they work in the context of the language environment where we might deploy them. Consequently, you can't just point to an "explorative implementation of a different macro system" unless it's in an otherwise-CL base and get really useful data about whether that system would be good for CL. The evaluation of what's good for CL should be done in the context of other features.
To do otherwise is to say "the arctic gets along fine without mosquitos, so we should really try that in the rainforests of central america." Ecologies don't work that way. And languages are ecologies. Linguistic features do not exist in isolation; they make other language features easier and harder to get to, they aggravate problems or enhance strengths. But the way in which they do this is language/ecology-specific, not general to all languages and all ecologies.
> Schemers bind variable-bind "car" and "list", etc., > about as often as CL'ers FLET them -- practically never.
Except, of course, to change the meaning of the primitives (e.g. to install a tracing version).
> (such as the above-mentioned inlining).
I think to a Schemer, inlining is something the compiler should worry about, and cutting'n'pasting of code is "writing the same thing twice" -- an absolute no-no in Scheme. If you feel tempted to write the same code twice, refactor!
r...@rigden.engr.sgi.com (Rob Warnock) writes: > Kent M Pitman <pit...@world.std.com> wrote: > +--------------- > | You mean to say that no Lisp1-er, even in the automobile industry, > | ever does: > | (defun foo (car) ...) / (define (foo car) ...) > | without fear that some macro will use CAR free? > +---------------
> I'm afraid that sounds like a "Have you stopped beating your wife?" > question to me. No sane Schemer would ever bind "car", with or without > macros!
> Using the term "macro" here [and other places in your argument] is mostly > a red herring. Binding "car" with a "let" or as a formal parameter (which > in Scheme are equivalent) is *ALREADY* a such a problem in a Lisp1 that > everyone who writes Scheme seriously *already* has to worry about it, > completely independently of macros. In Scheme, you simply *MUST* memorize > the entire set of builtin primitives and refrain from naming variables > with the same names, or your code -- even if it runs correctly when written > initially -- will be totally unmaintainable. Can we just *stipulate* that, > please?
Nope.
To get an independent point of view on this, I approached Jonathan Rees. I have known him personally for many years, and know him to be both a competent CL programmer who understands "the CL way" and a well-respected and competent Scheme programmer who understands "the Scheme way". He's also a stickler for proper programming aesthetics.
Here's the reply I got from him...
- - - - -
It's ridiculous to say that every Scheme programmer must memorize the names of all Scheme builtins, just so that he can avoid using them for his own purposes. A very important goal was to make such memorization or even knowledge unnecessary -- that's why the ability to redefine or rebind the builtins is so carefully protected. I know that I rebind builtins often, and so does Sussman (he loves to rebind the arithmetic operators); but I suppose neither of us is particularly "sane", so you might want to take a broader poll to try to refute the claim about "no sane Schemer".
Sussman articulated this idea from 1984 or earlier, and it is one reason he refused to admit non-lexically-scoped macros to the language -- he really wants to reserve the right to redefine anything at all, including macros and special operators. Hygiene solves the macro redefinition problem, which is why he likes it.
It's unfortunate that the hygiene stuff has had such bad PR and poor exposition - it and the pattern language both actually work (except that I've never seen a happy escape syntax for use by macro-defining macros). I've recently put my Scheme of Things column on implementing the hygiene part (not the pattern part) on line, by the way -- see http://mumble.net/jar/pubs/. If you combine hygiene with a module system, you really don't need to keep track of internal details of anyone else's code such as what names they define or bind.
And using macros for inlining is a big mistake. You lose the ability to trace, to easily pass as argument or return as result, and so on. Scheme 48 has automatic cross-module inlining, so there are other ways to achieve the same effect.
Scheme without a module system is a pain in the butt -- namespace isolation is pretty important for building large systems. I suppose that you do have to exercise vigilance and write unnatural code if you want to be able to combine subsystems written by different people (or the same person at different times) in the same Lisp1 namespace. I'm glad I don't live in that world.
> "Kent M Pitman" <pit...@world.std.com> wrote in message > news:sfwiti6s21e.fsf@world.std.com... > [About name clashes in macros.] > > It might not be an all-or-none thing, but I think it can't be argued > > that the probabilities of collision are higher.
> Yes, it is a difference of degree. As far as I can fathom, the real > problem is what RPG calls the "Worse is better" vs. "The right > thing".
Probably. We mostly get beaten up for being called The Right Thing by other languages, so it's refreshing to see we sometimes, even if only relatively, employ the strategy touted to win in practice, rather than only the one touted to lose in practice, as we are more commonly accused of. :-)
> I suppose no-one will seriously disagree with the statement that > Scheme is more in the "The right thing" camp, and CL in the "worse > is better" camp. Even a low probability is wrong if it can be > reduced to zero, and the programmer shouldn't have to deal with that > explicitly, a Schemer would argue.
Correctly written CL code has probability zero. Not near zero. IF you follow the appropriate style guidelines, you do not risk a problem. Period.
I agree there are ways you can use the operators to make trouble for yourself, but those are just opportunities for tightening what is and is not legal in a future standard. (We have the independent problem that the text of the standard needs not to be changed right now, for economic reassons, because there is nothing sufficiently wrong with it. But it is practically sufficient to say "consult a style guide".)
> The probability is pretty low to start with, the CL replies, it is > even lower because we have a second namespace, and to make it still > lower we have introduced a third namespace, packages. (For a > Schemer, these are basically glorified let constructs, of course, so > this is a partial implementation of lexical scoping for macro > variables.)
The issues is not probilistic.
Probabilities were raised in an unrelated area.
> Oh, and you know this, of course, but probably some others don't: lexical > scoping and hygiene are two separate issues in macrology.
But lexical scoping + namespacing + correct style is adequate to implement reliable hygiene.
Yes, I think that our positions are actually very close, the main perceived differences being linguistic rather than positional.
I look at a macro from a user point of view, because macros are written for users. I am under the impression that when a user calls a macro, <generic inclusive> he generally has an idea of what the construct means rather than what it does. If I call the loop macro, I am telling the macro what it should do with my data, not how it should transform what I tell it. (The "telling" being all the stuff I put in the macro call.)
If I am right in that supposition, what the macro system is providing (source transformations) is not what people normally use it for (meaning transformation). That was the sense in which I used "fighting the system".
I expect it to be rare that a programmer, using (gensym) when writing a macro, is actually interested in creating a nice fresh symbol. Most of the time, what he is really interested in (I presume) is that his variable doesn't clash. Now luckily you can implement that behaviour in a sufficiently rich code transformation system, but it is not the same thing, just like implementing a call stack with local variable values is not the same thing as recursion. The one can implement the other, but it is an amount of extra work.
All I said originally was that this was the reason that some code was a bit more complicated than people might at first thought expect - because you are implementing things rather than simply using them.
This is of course no problem at all, because you can easily load a package with tools that do this for you, so there we agree as well. (My computer speaking iX86 binary is no problem either, because I can install and run this nice CL - life still has its rewards :-)
> Which is why I was surprised by your assertion that writing macros > involves a lot of "fighting the system", which I take to mean that you > have to circumvent _restrictions_ in the system to reach your goals.
O.K. I hope I cleared that up
> If your claim were to be that the macro system itself provides too > little guidance and support to the writer of "simple" syntactical > convenience macros, I'd actually quite possibly agree.
It must be something with my English, because it feels as if everybody in this newsgroup thinks I have some claim that something or other with CL is wrong. Maybe standardising some simple safe system is useful, I am not sure. I am always scary of adding something to a standard - it is quite hard to get rid of later on.
> It is not a kludge, it is a lower-level tool, a building-block out of > which the higher-level tool will be built.
O.K., I used "kludge" in the meaning of "parts that don't quite match at the place where they meet" - the use vs. implementation discrepancy again.
> And since "problems" only occur when you break that contract, which > requires direct action from you, this is a completely stable > situation. When you override the definition of #'cl:list, you have to > expect the consequences.
Oh, with my CL mindset this is obvious. But with my general Lisp mindset, having such a contractual restriction in the first place is not completely obvious. But again: I definitely don't propose any change in the CL standard. Maybe I am sounding paranoid, but I have said this maybe about ten times now, and still at times people seem to think I am proposing changes, or simply attacking CL, or telling people to use another language.
> Not at all. Fighting the system means having to work around > restrictions in the system, in order to achieve the results intended.
Oh, that is a difference in semantics then. For me it means "applying energy to go one way whereas the natural inclination of the system would move me in another way. As in "fighting the Nazi army", or "fighting the current". The energy here being the explicit (gensym)s, etc. Sorry for the misconception.
> BTW I don't think that your description of what the macro writer wants > to is clearly defined. The moment words like "MEAN" etc. crop up in a > definition of what a system should enable, we enter the land of DWIM > it seems to me.
I hope I did a bit better above. "Mean" as in operational semantics of the resulting program, "say" as in source transformation.
I kind of liked DWIM, by the way, even though it had a nasty habit of forgetting a mistake just before I remade it.. :-(
> You like it that Biep is starting to insult Erik > and in an attempt to get him going?
On the contrary. I made a mistake in replying to him (and probably now in replying about him). I spent a tedious discussion trying to find out how he associates meanings with words and expressions, and besides long off-topic ramblings all I got was ricochet name calling (Instead of saying "you are retarded", saying "anybody who does that is retarded" when he thinks I do that).
In comp.org.lisp-users someone asked about Lisp versions, and (in line with the FAQ of the ALU, whose group it is as far as I know), I mentioned CL and Scheme. Erik took me to task for mentioning Scheme (for some reason this article has dropped out of the thread on Google). Here is the ensuing conversation: http://groups.google.com/groups?hl=nl&lr=&newwindow=1&safe=off&ic=1&t... 34014a8,35.
While he made it abundantly clear that he does not consider Scheme a Lisp (in the given context), I still don't know what grounds he uses in determining what I (or the ALU, or the person asking the original question) should mean when saying "a Lisp".
So I decided to ignore him - I love debating issues, but debating with someone who can only deal with the person, and gets nervous when he doesn't know WHO it was who said something simply doesn't interest me.
Kent, I know that you have disclaimed at some point that you don't read threads, but in this case the relevant part of the thread is still in YOUR post even :-)
Mr. Thornley asked a double question (1) If I have an idea for a better way to write macros, please tell us --> To which my answer was: No, I think in CL macros should remain the way they are. (2) If I have an idea for a better way to teach how to write macros, please tell us --> To which my answer was a short explanation of how I tend to teach CL macro writing.
The two parts are different issues, addressing different parts of the double question. -- Biep Reply via http://www.biep.org
> > "David Thornley" <thorn...@visi.com> wrote in message > > news:13bU6.10022$Dd5.2846360@ruti.visi.com... > > > So, if you have an idea for a better way to write macros, > > > or a better way to teach how to write macros, please tell us.
> > No, I think in CL macros should remain the way they are. Standards > > should move slowly, and the last word is definitely not yet out on > > macro writing.
> > There are a few changes I would argue for if there had been no > > standard as yet, but then who hasn't :-)
> Such as?
I would argue for scoping rules within macros and outside of macros that are as alike as possible, i.e. lexical scope as the default, but with the possibility of special declarations. This of course raises some name-space issues (special variables having their own namespace outside of macros, whereas - in a simplistic form of this proposal - special macro symbols would match lexical items in other namespaces, but I am not going to start a discussion of that. I have already burned my fingers enough simply answering a question that I am not going into a serious discussion of what I might have proposed if..
> There is no standard for teaching.
No, obviously.. Did anyone suggest there is one? Sorry, I cannot connect this remark to anything else in a meaningful way..
> > I have found this to work better than the other way around (discussing the > > pitfalls first).
> Could be. But this IS a statement about teaching technique, not language > definition, so is not at odds with anything in the language.
Indeed. See above.
> The language specification itself is not written to newbies. [etc.]
I suppose the remainder of your message is a result of the misunderstanding I tried to clear up above, so I'll refrain from commenting on it. If I am wrong, I'll no doubt hear it.. :-)
