Re: Understanding #' and function variables

From: Pascal Costanza (costanza_at_web.de)
Date: 02/11/04 

Date: Wed, 11 Feb 2004 23:34:27 +0100

Erann Gat wrote:

> In article <c0e1av$gl$1@newsreader2.netcologne.de>, Pascal Costanza
> <costanza@web.de> wrote:
>
>
>>Exactly. That's the reason for my statement that I don't care whether a
>>change is standard compliant or not. The real question is whether you
>>can implement your own abstractions and make them interoperate with
>>other Common Lisp code. If that's possible for a particular abstraction,
>>then everything is fine IMHO.
>>
>>There are possible extensions that would need fundamental changes to the
>>standard, such as switching to Lisp-1 or integration of call/cc.
>
> When you get right down do it you can do anything within the standard by
> shadowing defun and writing a code walker. So a reasonable interpretation
> of "cannot be done within the standard" is "cannot be done within the
> stanard except with a code walker."

I don't think that this is the only issue.

> On this definition, Lisp-1 can be done within the standard using symbol
> macros (and in fact it has been done -- see my locales paper). Call/cc
> cannot. Neither can ((foo) ...). And, I believe (I could be wrong about
> this), neither can Joe's proposed model of how dynamic bindings interact
> with threads.

OK, let's see:

- Lisp-1 would have problems wrt to interoperability. When referring to
Lisp-1 definitions from within Lisp-2 code, you could just use the same
value for both function and value namespaces. (Functions only when they
are lambda expressions.) When referring to Lisp-2 definitions from
within Lisp-1 code, would you mean the function or the value namespace
by default? What would be the effect when you set the symbol-value of a
Lisp-2 symbol? What would happen if you passed Lisp-1 symbols to Lisp-2
code and vice versa? It seems to me that these issues are not
straightforward to solve.

- Likewise, call/cc has problems wrt unwind-protect, as Kent has
explained in his paper. The fact that unwind-protect can be implemented
on top of dynamic-wind doesn't seem to matter much in this regard
AFAICS. Also, Duane has explained before that call/cc is hard to
integrate with FFIs, IIRC.

- I think I have provided code that allows one to use Joe's model for
dynamic bindings across threads. You cannot directly use Common Lisp's
internal defvar and so on for that, but you can redefine / shadow it and
have the "legacy" code recompiled, maybe with some minor tweaks. I don't
see any real interoperability problems here.

I really don't think it matters how things are implemented. What matters
is how seamless you can make it. But maybe I am missing something...

>>It's
>>hard to make these things interoperate with the rest of the CL world.
>>However, since these features don't seem to add substantial advantages,
>>there is no point in doing that.
>
> Reasonable people could disagree (and they do, which is why Scheme has a
> user community.)

Sure. Continuations are an important abstraction, at least from a
computer scientist's point of view. That's why it is natural that there
are languages that support them. BTW, there are also implementations of
Turing machines out there. Worthwhile to understand those models, isn't
it? ;)

>>It is really hard to come up with anything that would require a
>>substantial revision of ANSI Common Lisp and would provide equally
>>substantial benefits at the same time. As long as this is the case, it
>>is absolutely sufficient to work within the boundaries set by ANSI CL.
>
> This seems to me to be at odds with your earlier statement:
>
>>I don't care whether a change is standard compliant or not.

No, not really. There are essentially four possibilies:

- Someone will invent a strictly better language for my purposes.
- I will find out about an already existing language that is strictly
better for my purposes.
- I will understand that of the languages I know but currently despise,
there is one that is indeed strictly better for my purposes, but I
simply haven't gotten it yet.
- I will die beforehand. ;)

In the first three cases, I will happily switch to the better language.
It wouldn't matter to me if Common Lisp also made the switch or not in
those cases.

The point is, as far as I can see, it is really very hard to beat Common
Lisp in terms of fundamental feature set, at least from my subjective
point of view. There are many minor details that could be improved in
one way or the other, but these aren't things that couldn't be added
seamlessly with a bunch of macros. Changing the standard for those minor
improvements would be gratuitous, especially because it will be hard to
agree upon them. (For example, remember a recent discussion here whether
global variables should always use the asterisk convention or not.) An
agreement upon a certain way to combine features that is somewhat
accidental to a certain degree is better than none. Given the
circumstances under which Common Lisp was developed it is really amazing
how well balanced it is. I don't see any language that really comes close.

So, no I don't care whether a change to the standard would be compliant
or not. There just don't seem to be strong enough reasons to make
non-compliant changes.

> Not that this necessarily matters.

Sure. ;)

Pascal 

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

Relevant Pages

  • Re: How Common Lisp sucks
    ... necessities in today's world. ... getting acceptance of a considerable number of members in the Common Lisp community. ... Now you are apparently invoking a defacto standard. ... If we don't find a single example for changing the language in a fundamental way that would actually make the language easier to understand for newbies without loosing expressiveness, ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... in the Common Lisp community. ... libraries that work across implementations that provide de facto ... This is one of the very few instances of behavior outside the standard ... to the language at all. ...
    (comp.lang.lisp)
  • Re: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... but having third party libraries to support the new ... ideas come along doesn't mean that the language itself will grow. ... Having in mind that the CL standard is rather old, ...
    (comp.lang.lisp)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... post came across very critical of Common Lisp (that is, ... > to be explicit on this and there was no money to do that project. ... > when you don't see something in the formal standard written and ... No reason why I won't try to do so in the future. ...
    (comp.lang.lisp)
  • Re: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... ideas come along doesn't mean that the language itself will grow. ... Having in mind that the CL standard is rather old, ... , I think that though libraries will be ...
    (comp.lang.lisp)
Loading