From: Fernando D. Mato Mira
Subject: Re: How to make a mutually recursive macro and function
Date:
Message-ID: <38BD0719.38B66D8@iname.com>
With the constraint of not using a top-level fun definition,
and so it also works for MACROLETs.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Fernando D. Mato Mira
Subject: Re: How to make a mutually recursive macro and function
Date:
Message-ID: <38BD6793.93660772@iname.com>
Detail: those seemingly redundant funcalls are not in the case SERIES implementation.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Fernando D. Mato Mira
Subject: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38BE9543.5D65CF29@iname.com>
"Fernando D. Mato Mira" wrote:
> Detail: those seemingly redundant funcalls are not in the case SERIES implementation.
Of course they don't even seem so now that no global functions are used. This is CL,
not Scheme!
Hm. If now one is allowed to do ((lambda (x) x) 1) why not ((function expr) args), too?
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Barry Margolin
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <dJBv4.13$NC6.189@burlma1-snr2>
In article <·················@iname.com>,
Fernando D. Mato Mira <········@iname.com> wrote:
>Hm. If now one is allowed to do ((lambda (x) x) 1) why not ((function
>expr) args), too?
I don't understand the question. Your use of "now" implies that there was
some time when the lambda form wasn't allowed, but my understanding is that
the lambda form has a very long history; effectively you've *always* been
allowed to do ((lambda (x) x) 1).
The function position of an expression has always been treated specially in
the sequence of Lisp dialects that lead up to and include Common Lisp. If
it's a symbol, its functional binding is used; if it's not a symbol it can
only be a lambda expression; it's *not* simply evaluated as a normal
expression.
Some Lisp dialects have expanded on this. For instance, Lisp Machine Lisp
has DEFINE-LAMBDA-MACRO -- it creates symbols that are recognized similarly
to the way LAMBDA is; if you do (define-lambda-macro foo ...) then you can
do ((foo ...) args...). But notice that FOO is still handled specially --
it's not simply looked up as a function to call.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, 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.
From: Fernando D. Mato Mira
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38BFA000.FE6D8056@iname.com>
Barry Margolin wrote:
> the sequence of Lisp dialects that lead up to and include Common Lisp. If
> it's a symbol, its functional binding is used; if it's not a symbol it can
> only be a lambda expression; it's *not* simply evaluated as a normal
> expression.
In the interest of increased Scheme compatibility, it would be nice if the first
form were evaluated when it's not a symbol.
Also, for this case, it would be cool if one colud do `(,#'foo args). I'm not sure
if in Scheme it's legal something like
[choose your syntax here]
(define (bar x y z) ..)
(define-macro (foo . args)
`(,bar ,@args))
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Barry Margolin
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <t9Tv4.59$NC6.1674@burlma1-snr2>
In article <·················@iname.com>,
Fernando D. Mato Mira <········@iname.com> wrote:
>In the interest of increased Scheme compatibility, it would be nice if the first
>form were evaluated when it's not a symbol.
The Common Lisp designers made a conscious decision *not* to copy this
aspect of Scheme, so this would be a fundamental philosophical change in
the language. If you want to compute the function call, you must use
FUNCALL.
If you want Scheme, you know where to find it.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, 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.
From: Fernando D. Mato Mira
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38C00DBF.ED8CF15@iname.com>
Barry Margolin wrote:
> If you want Scheme, you know where to find it.
Well, OK, it's not cool to ask everybody to implement this, but it's
a valuable extension if you're trying to reuse Scheme code not going crazy about
call/cc.
It's one of those features that might make acceptable the "Vendor Lock-In"
antipattern.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Barry Margolin
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <utVv4.75$NC6.1918@burlma1-snr2>
In article <················@iname.com>,
Fernando D. Mato Mira <········@iname.com> wrote:
>Barry Margolin wrote:
>
>> If you want Scheme, you know where to find it.
>
>Well, OK, it's not cool to ask everybody to implement this, but it's
>a valuable extension if you're trying to reuse Scheme code not going crazy about
>call/cc.
Good point. Even Maclisp had a parameter that enabled evaluation of the
function position.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, 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.
From: Fernando D. Mato Mira
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38C271A2.F5C6D7B8@iname.com>
"Fernando D. Mato Mira" wrote:
> Well, OK, it's not cool to ask everybody to implement this, but it's
> a valuable extension if you're trying to reuse Scheme code not going crazy about
> call/cc.
While we are at it, it's pretty amazing no implementor has added call/cc yet.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <ey366v1ihen.fsf@cley.com>
* Fernando D Mato Mira wrote:
> While we are at it, it's pretty amazing no implementor has added call/cc yet.
Alternatively, it's a splendid confirmation that it was indeed right
to leave call/cc out of common lisp...
--tim
Centuries ago, Nostradamus foresaw a time when Tim Bradshaw would say:
>* Fernando D Mato Mira wrote:
>> While we are at it, it's pretty amazing no implementor has added
>> call/cc yet.
>
>Alternatively, it's a splendid confirmation that it was indeed right
>to leave call/cc out of common lisp...
I don't think so.
What it *really* says is that Scheme has some significant differing
underlying assumptions from Common Lisp.
a) There's the 'Lisp-1' versus 'Lisp-2' "thing;" Scheme only has one
namespace, whilst CL has multiple namespaces for different kinds of
objects.
b) The "call/cc thing" parallels the "tail recursion thing" where
Scheme requires that implementations have some common primitives.
CL requires no such thing, which provides implementors greater
flexibility, but which diminishes some of the expectations on how
things work that can be made with Scheme.
c) The *problem* with Scheme (which the SRFI process may help remedy)
that the "call/cc" thing shows off is that call/cc was intended to
be treated as a *primitive* that would be used to implement control
structures.
Parallel the situation with TeX and LaTeX document styles: Leslie
Lamport built some *sample* styles, as did Donald Knuth. These
systems provide primitives (not unlike call/cc) that they hoped
would be used to implement higher level document structures.
Unfortunately, this hasn't happened. Lots of people gripe about
the overfamiliarity of LaTeX document styles, when the problem is
that nobody has taken the functionality the step further that the
creators intended. Likewise, there hasn't grown out a "standard
function library" for Scheme to provide many of the things it is
missing. (A particular complaint of mine is that there's not a
"standard" way of dealing with hash tables. Every implementation
has a *different* implementation.)
In short, it's not that call/cc is particularly bad, it's that call/cc
is merely a primitive, and isn't widely useful until you use the
primitive to build specifically useful structures.
--
If all the economists in the world were laid end to end, it would
probably be a good thing.
········@ntlug.org - - <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Tim Bradshaw
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <ey38zzx5ee4.fsf@cley.com>
* Christopher Browne wrote:
> Centuries ago, Nostradamus foresaw a time when Tim Bradshaw would say:
>> * Fernando D Mato Mira wrote:
>>> While we are at it, it's pretty amazing no implementor has added
>>> call/cc yet.
>>
>> Alternatively, it's a splendid confirmation that it was indeed right
>> to leave call/cc out of common lisp...
> I don't think so.
> What it *really* says is that Scheme has some significant differing
> underlying assumptions from Common Lisp.
Right, and I meant that in the context of those assumptions, leaving
call/cc out was the right thing to do.
--tim
From: Barry Margolin
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <%FEw4.20$eW.447@burlma1-snr2>
In article <·······················@knuth.brownes.org>,
Christopher Browne <········@hex.net> wrote:
>In short, it's not that call/cc is particularly bad, it's that call/cc
>is merely a primitive, and isn't widely useful until you use the
>primitive to build specifically useful structures.
And CL's philosophy is that the "specifically useful structures" should be
provide as high-level features already in the language. We already have
TAGBODY/GO, UNWIND-PROTECT, CATCH/THROW, and a condition system. And many
implementations provide a threading system. These are the things that
Schemers typically implement using call/cc; since they're already there, no
one is clamoring for the primitive.
I think the only time CL'ers notice the lack of call/cc is when they're
trying to implement a Scheme compatibility package....
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, 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.
From: Erik Naggum
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <3161299902310489@naggum.no>
* Christopher Browne
| What it *really* says is that Scheme has some significant differing
| underlying assumptions from Common Lisp.
we all know this to be a deep and fundamental truth, already.
| b) The "call/cc thing" parallels the "tail recursion thing" where
| Scheme requires that implementations have some common primitives.
| CL requires no such thing, which provides implementors greater
| flexibility, but which diminishes some of the expectations on how
| things work that can be made with Scheme.
this is also one of the differences between the Scheme and the Common
Lisp communities. the Scheme community uses the specification as the
source for its expectations and when it can't find something in the
specification for Common Lisp, claims that Common Lisp cannot expect it.
the Common Lisp community uses the specification and the common sense of
vendors and the functioning of the market as its source of expectations,
and consequently doesn't have a problem with any of the things that
Scheme people have problems with in Common Lisp. on the other hand, the
Common Lisp community recognizes the Scheme community's need for its very
thin specification, and argues that the Scheme community cannot expect to
have any useful functions in a Scheme environment at all, to which the
Scheme community always responds that every Scheme implementation has a
lot of goodies that you can rely on, and then there's slib and whatnot,
so in the end it seems rather specious of the Scheme adherents to argue
that the Common Lisp community cannot expect tail-call merging, which
every implementation offers given sufficent optimization settings.
| c) The *problem* with Scheme (which the SRFI process may help remedy)
| that the "call/cc" thing shows off is that call/cc was intended to
| be treated as a *primitive* that would be used to implement control
| structures.
and Common Lisp has all those control structures that Scheme people
implement with call/cc. it's like giving programmers access to a
primitive of creating, linking, and unlinking call frames, but no
function call primitive. (Scheme doesn't have funcall, as you know. :)
| In short, it's not that call/cc is particularly bad, it's that call/cc is
| merely a primitive, and isn't widely useful until you use the primitive
| to build specifically useful structures.
which implies that the usefulness of implementing these control
structures with call/cc has to be questioned, since none of the Common
Lisp implementations even use the primitive operation call/cc underneath,
and they also don't generally heap-allocate call frames, but remain with
the stack-allocation paradigm. in short, call/cc is a primitive that is
too primitive for its own good: it demands a particular way to do things
that doesn't reflect how people have come to conclude they should be
done. the same is true of Scheme's tail calls. it doesn't make sense to
force every tail call to be a jump, as it messes with argument passing
conventions and stack unwinding and many forms of debuggability and a
host of other issues tha makes communication with other languages hard.
so in my view, Scheme's core function call model is simply a mistake, and
both tail calls and call/cc make the design mistakes explicitly visible
to the users. learning from such mistakes is an important part of moving
forward in language design, and this may indeed be why no other language
has picked up on these ideas, despite having picked up on a number of
other valuable contributions from Scheme. some of this reflects badly on
"adjacent ideas" in Scheme, too.
again in my view, there are probably mistakes in Common Lisp's design
that makes it hard for people to pick up on adjacent ideas, too. for one
thing, I have started to believe that the use of upper-case symbol names
is a serious communications bottleneck with other languages that we need
to talk to these days. it's not that we can't overcome it, it's that
it's such a hassle to overcome it. and it's not a technical issue, just
like start-up time is not a technical issue, it's a matter of perception
and how we approach contrary views when they necessarily come up.
#:Erik
From: Rob Warnock
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <89vdc4$i1bj1$1@fido.engr.sgi.com>
Erik Naggum <····@naggum.no> wrote:
+---------------
| (Scheme doesn't have funcall, as you know. :)
+---------------
(define (funcall func . args)
(apply func args))
Now it does. ;-} ;-}
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
"Fernando D. Mato Mira" <········@iname.com> writes:
> "Fernando D. Mato Mira" wrote:
>
> > Well, OK, it's not cool to ask everybody to implement this, but
> > it's a valuable extension if you're trying to reuse Scheme code
> > not going crazy about call/cc.
>
> While we are at it, it's pretty amazing no implementor has added
> call/cc yet.
Given that many Scheme implementations either haven't implemented
call/cc or have implemented it very inefficiently, I don't find it
amazing at all that CL implementors don't want to carry this burden
needlessly.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Fernando D. Mato Mira
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38C3A3E1.6A5E8834@iname.com>
"Pierre R. Mai" wrote:
> Given that many Scheme implementations either haven't implemented
> call/cc or have implemented it very inefficiently, I don't find it
> amazing at all that CL implementors don't want to carry this burden
> needlessly.
What burden? If you don't use call/cc, you should suffer no penalty.
They shouldn't use _that_ to implement CL's standard control structures.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Joe Marshall
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <uwvnf7wct.fsf@alum.mit.edu>
"Fernando D. Mato Mira" <········@iname.com> writes:
> "Pierre R. Mai" wrote:
>
> > Given that many Scheme implementations either haven't implemented
> > call/cc or have implemented it very inefficiently, I don't find it
> > amazing at all that CL implementors don't want to carry this burden
> > needlessly.
>
> What burden? If you don't use call/cc, you should suffer no penalty.
> They shouldn't use _that_ to implement CL's standard control structures.
It is hard to correctly implement stack-allocated objects or
mutable variables when cwcc is possible. This is a penalty you get
even if you *don't* use cwcc.
~jrm
From: Tim Bradshaw
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <ey3ya7w1d2k.fsf@cley.com>
* Fernando D Mato Mira wrote:
> What burden? If you don't use call/cc, you should suffer no penalty.
> They shouldn't use _that_ to implement CL's standard control structures.
other than the penalty of choosing internal representations that allow
call/cc to work reasonably well, possibly in the presence of arbitrary
foreign code on the stack and so on.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Fernando D Mato Mira wrote:
>
> > What burden? If you don't use call/cc, you should suffer no penalty.
> > They shouldn't use _that_ to implement CL's standard control structures.
>
> other than the penalty of choosing internal representations that allow
> call/cc to work reasonably well, possibly in the presence of arbitrary
> foreign code on the stack and so on.
And prohibiting stack allocation of mutable variables and data structures...
From: Dorai Sitaram
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <8a0mlk$lni$1@news.gte.com>
In article <················@alum.mit.edu>,
Joe Marshall <·········@alum.mit.edu> wrote:
>Tim Bradshaw <···@cley.com> writes:
>
>> * Fernando D Mato Mira wrote:
>>
>> > What burden? If you don't use call/cc, you should suffer no penalty.
>> > They shouldn't use _that_ to implement CL's standard control structures.
>>
>> other than the penalty of choosing internal representations that allow
>> call/cc to work reasonably well, possibly in the presence of arbitrary
>> foreign code on the stack and so on.
>
>And prohibiting stack allocation of mutable variables and data structures...
Waitaminute! Didn't that go out the window already
the moment we had procedures returning
procedures?
--d
From: Michael Livshin
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <s3wvngf33j.fsf@verisity.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <················@alum.mit.edu>,
> Joe Marshall <·········@alum.mit.edu> wrote:
> >
> >And prohibiting stack allocation of mutable variables and data structures...
>
> Waitaminute! Didn't that go out the window already
> the moment we had procedures returning
> procedures?
no. you just stuff the pointers to closed-over lexicals into the
"display closure". which, of course, means indirection when accessing
said lexicals from the closure code, but at least you didn't pay for
something you didn't ask for ;).
> --d
--mike
--
only legal replies to this address are accepted.
Those who do not learn from history, loop.
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3k8jg11ql.fsf@cley.com>
* Dorai Sitaram wrote:
> Waitaminute! Didn't that go out the window already
> the moment we had procedures returning
> procedures?
As far as I can see, in the current situation there are a whole bunch
of places where you can stack-allocate, for instance:
(let ((x (list ...)))
... functions which don't take bits of x ...
... don't return anything that catches bits of x ...
)
then X can be stack allocated (with suitable additional caveats and
more precision in my definitions which I'm sure someone will complain
at). In particular a compiler should be able to lexically tell if it
is safe to stack allocate X. But with call/cc it can't because any of
those functions might call call/cc and grab the whole stack. So you
have to do analysis on the whole program as far as I can see.
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C3F52E.C100BAA1@iname.com>
Joe Marshall wrote:
> Tim Bradshaw <···@cley.com> writes:
>
> > * Fernando D Mato Mira wrote:
> >
> > > What burden? If you don't use call/cc, you should suffer no penalty.
> > > They shouldn't use _that_ to implement CL's standard control structures.
> >
> > other than the penalty of choosing internal representations that allow
> > call/cc to work reasonably well, possibly in the presence of arbitrary
> > foreign code on the stack and so on.
>
> And prohibiting stack allocation of mutable variables and data structures...
Say you forbid calling cwcc in exception handlers, then you could use something
like
(declare (without-full-continuations))
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C3F64A.E634C82@iname.com>
"Fernando D. Mato Mira" wrote:
> Say you forbid calling cwcc in exception handlers, then you could use something
> like
> (declare (without-full-continuations))
I meant calling full continuations.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Joe Marshall
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <uzosb7wj7.fsf@alum.mit.edu>
"Fernando D. Mato Mira" <········@iname.com> writes:
> "Fernando D. Mato Mira" wrote:
>
> > Say you forbid calling cwcc in exception handlers, then you could use something
> > like
> > (declare (without-full-continuations))
>
> I meant calling full continuations.
>
Still no good. You have to know if any function that might be called,
directly or indirectly, could cwcc.
--
~jrm
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C4BCB7.48B40686@iname.com>
Joe Marshall wrote:
> "Fernando D. Mato Mira" <········@iname.com> writes:
>
> > "Fernando D. Mato Mira" wrote:
> >
> > > Say you forbid calling cwcc in exception handlers, then you could use something
> > > like
> > > (declare (without-full-continuations))
> >
> > I meant calling full continuations.
> >
>
> Still no good. You have to know if any function that might be called,
> directly or indirectly, could cwcc.
What do you think (declare (without-full-continuations)) means?
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Joe Marshall
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <u7lfeivhh.fsf@alum.mit.edu>
"Fernando D. Mato Mira" <········@iname.com> writes:
> Joe Marshall wrote:
>
> > "Fernando D. Mato Mira" <········@iname.com> writes:
> >
> > > "Fernando D. Mato Mira" wrote:
> > >
> > > > Say you forbid calling cwcc in exception handlers, then you could use something
> > > > like
> > > > (declare (without-full-continuations))
> > >
> > > I meant calling full continuations.
> > >
> >
> > Still no good. You have to know if any function that might be called,
> > directly or indirectly, could cwcc.
>
> What do you think (declare (without-full-continuations)) means?
Silly me, I *assumed* that it meant that you are making some promise
about certain properties of the code in which the declaration appears.
Then the compiler could safely stack allocate variables in this
segment of code.
But it seems to me that if this code calls any other functions,
I can invalidate that particular declaration by calling cwcc.
After all, the called function doesn't know anything about the
callers' declarations.
--
~jrm
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C641C7.BF3BD9D7@iname.com>
Joe Marshall wrote:
> But it seems to me that if this code calls any other functions,
> I can invalidate that particular declaration by calling cwcc.
> After all, the called function doesn't know anything about the
> callers' declarations.
It's no worse than dynamic-extent.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey31z5lsi8k.fsf@cley.com>
* Fernando D Mato Mira wrote:
> It's no worse than dynamic-extent.
Yes, it's much worse.
Consider this code:
(defun foo (y)
(let ((x (list 1 2 3)))
(declare (dynamic-extent x))
(if (member (bar y) x)
t
nil)))
That dynamic-extent declaration is completely safe in current CL. In
CL with call/cc it is not.
(actually, since this list isn't changed, it is, but you can invent a
hairier example).
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C66489.1337C5F9@iname.com>
Tim Bradshaw wrote:
> * Fernando D Mato Mira wrote:
>
> > It's no worse than dynamic-extent.
>
> Yes, it's much worse.
What about this?
(defvar *grr* nil)
(defun bar (x)
(setq *grr* x))
(defun foo ()
(let ((x (list 1 2 3)))
(declare (dynamic-extent x))
(bar x)))
(foo)
*grr*
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3sny1r07x.fsf@cley.com>
* Fernando D Mato Mira wrote:
> (defun foo ()
> (let ((x (list 1 2 3)))
> (declare (dynamic-extent x))
> (bar x)))
You're passing X into BAR. cwcc can invalidate things *even if you
don't do that*, because BAR can grab the whole stack. No allocation,
however local, is safe with call/cc.
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C671FE.3BD2574B@iname.com>
Tim Bradshaw wrote:
> * Fernando D Mato Mira wrote:
>
> > (defun foo ()
> > (let ((x (list 1 2 3)))
> > (declare (dynamic-extent x))
> > (bar x)))
>
> You're passing X into BAR. cwcc can invalidate things *even if you
> don't do that*, because BAR can grab the whole stack. No allocation,
> however local, is safe with call/cc.
What about:
(defmacro baz () `(bar x))
(defun foo ()
(let ((x (list 1 2 3)))
(declare (dynamic-extent x))
(baz)))
Still looking good?
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Fernando D. Mato Mira" <········@iname.com> writes:
> What about:
>
> (defmacro baz () `(bar x))
>
> (defun foo ()
> (let ((x (list 1 2 3)))
> (declare (dynamic-extent x))
> (baz)))
>
> Still looking good?
Where's the issue? To the compiler this is the same as your
previous example, i.e. he sees that x is passed out to function bar,
and so based on his knowledge of bar can decide locally whether x can
be stack allocated safely or not.
There's a very important difference between macros and functions: The
effects of macros are apparent at compile-time, those of functions
not.
And if you were thinking of the user:
a) He deserves to lose, since writing such dain-bramaged code will get
him into trouble in any of a thousand ways,
b) he can just press the key that does macro expansion in his
favourite implementation.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C68534.20F19716@iname.com>
"Pierre R. Mai" wrote:
> "Fernando D. Mato Mira" <········@iname.com> writes:
>
> > What about:
> >
> > (defmacro baz () `(bar x))
> >
> > (defun foo ()
> > (let ((x (list 1 2 3)))
> > (declare (dynamic-extent x))
> > (baz)))
> >
> > Still looking good?
>
> Where's the issue? To the compiler this is the same as your
> previous example, i.e. he sees that x is passed out to function bar,
> and so based on his knowledge of bar can decide locally whether x can
> be stack allocated safely or not.
Really? Then what's the point of writing dynamic-extent declarations?
> There's a very important difference between macros and functions: The
> effects of macros are apparent at compile-time, those of functions
> not.
All effects? (see above). Anyway, not for the user. See below:
> And if you were thinking of the user:
>
> a) He deserves to lose, since writing such dain-bramaged code will get
> him into trouble in any of a thousand ways,
But that `baz' thing might be a huge complicated thing he did not write.
Of course one hopes nontrivial 3rd party macros will be well-behaved.
> b) he can just press the key that does macro expansion in his
> favourite implementation.
That could translate into hundreds of lines of code. Of course you can ctrl-s.
I just hope you won't have many hits due to local variables, especially when
indentation
makes things wrap around.
Whatever. For all practical purposes, it _is_ worse, indeed.
[Err.. I didn't say continuations were not practical, OK? :)]
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3n1o9qxkc.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Still looking good?
No. Same problem, obviously (and the compiler wouldn't even care
about this since macros will have been expanded before this stage).
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C66B26.472226CA@iname.com>
Tim Bradshaw wrote:
> Consider this code:
>
> (defun foo (y)
> (let ((x (list 1 2 3)))
> (declare (dynamic-extent x))
> (if (member (bar y) x)
> t
> nil)))
>
> That dynamic-extent declaration is completely safe in current CL. In
> CL with call/cc it is not.
You mean that bar is something like:
(defun bar (y)
(call/cc (k)
(y k)))
where y is a continuation?
Then it means that for backward-compatibility purposes, dynamic-extent
declarations
must be ignored in a continuable context.
So you need yet another declaration: continuable-dynamic-extent or
whatever.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3put5qyne.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Then it means that for backward-compatibility purposes, dynamic-extent
> declarations
> must be ignored in a continuable context.
Right. And you can't tell locally what a continuable context is, so
you're doomed.
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C68024.1AB3696E@iname.com>
Tim Bradshaw wrote:
> * Fernando D Mato Mira wrote:
> > Then it means that for backward-compatibility purposes, dynamic-extent
> > declarations
> > must be ignored in a continuable context.
>
> Right. And you can't tell locally what a continuable context is, so
> you're doomed.
If you want to play declaration games, you play declaration games.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3put5l7e3.fsf@cley.com>
* Fernando D Mato Mira wrote:
> If you want to play declaration games, you play declaration games.
Well, I guess it's safe to say the case is made when the person on the
other side of the argument stops making technical points and starts
replying with cryptic and meaningless comments and replying with
obfuscated code, so I'll stop now.
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C6A204.395E2DC6@iname.com>
Tim Bradshaw wrote:
> * Fernando D Mato Mira wrote:
>
> > If you want to play declaration games, you play declaration games.
>
> Well, I guess it's safe to say the case is made when the person on the
> other side of the argument stops making technical points and starts
> replying with cryptic and meaningless comments and replying with
> obfuscated code, so I'll stop now.
? That's "Fernando style". One liners and quotes. The antithesis of EN!
;)
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Erik Naggum
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <3161537045930526@naggum.no>
* "Fernando D. Mato Mira" <········@iname.com>
| ? That's "Fernando style". One liners and quotes. The antithesis of EN!
| ;)
I can't wait for the continuation.
#:Erik
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C77A9B.A0C3E3ED@iname.com>
Erik Naggum wrote:
> I can't wait for the continuation.
See? Even Erik wants it now! ;)
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Joe Marshall
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <uog8p8pda.fsf@alum.mit.edu>
"Fernando D. Mato Mira" <········@iname.com> writes:
> Joe Marshall wrote:
>
> > But it seems to me that if this code calls any other functions,
> > I can invalidate that particular declaration by calling cwcc.
> > After all, the called function doesn't know anything about the
> > callers' declarations.
>
> It's no worse than dynamic-extent.
Yes, it is. If I declare something to be dynamic extent, I
can locally guarantee that the declaration will not be violated
by not passing the dynamic object to an unsafe function (where
I'll define safe as only those built-in functions that are
known not to squirrel away pointers). This is restrictive,
but there are a lot of functions in common lisp that I can
still use in a completely safe manner.
And of course, I can call any function I want if I don't
pass the dynamic object in, or I can copy the dynamic object
in those cases.
There are many places where I can use `dynamic-extent' in a
manner that it is a)useful, and b) completely safe (in that
no change to third-party code can break my use of
dynamic-extent).
I can't make the same promises about cwcc: the only
way I can guarantee that cwcc won't be invoked is to call only
those built-in functions that don't invoke it (and I'll be
generous in assuming no built-in functions call it). But
code that never calls anything but common-lisp built-in
functions is rather rare.
So if your function calls *any* function other than a built-in,
then cwcc is a potential problem, and there is no simple way
to avoid the problem as there is with dynamic-extent.
--
~jrm
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3aekc0vyf.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Say you forbid calling cwcc in exception handlers, then you could use something
> like
> (declare (without-full-continuations))
But this has to be listened to *at run time*! If I'm compiling some
function F, I can't know at compile time if I might be called in a
context where it is safe to stack-allocate or not, because I'd need
complete information about every function I might call. So I have to
either never stack-allocate or compile two different versions and
switch at runtime or something equally horrible.
Having a global proclamation doesn't help much either, because it
still doesn't avoid the needing-two-versions of everything issue.
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C4BDE4.B6AB5EFD@iname.com>
Tim Bradshaw wrote:
> complete information about every function I might call. So I have to
> either never stack-allocate or compile two different versions and
> switch at runtime or something equally horrible.
Yes. And if you don't want continuations at all, make sure your
command-line switches [or boot parameters ;-)] are set appropriately.
> Having a global proclamation doesn't help much either, because it
> still doesn't avoid the needing-two-versions of everything issue.
You could also have something like (declare (noncontinuable foo))
[(declare (continuable foo)) would be useful if you wanted to default the other way]
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Fernando D. Mato Mira" <········@iname.com> writes:
> Tim Bradshaw wrote:
>
> > complete information about every function I might call. So I have to
> > either never stack-allocate or compile two different versions and
> > switch at runtime or something equally horrible.
>
> Yes. And if you don't want continuations at all, make sure your
> command-line switches [or boot parameters ;-)] are set appropriately.
And don't forget to send that cheque for the now doubled maintenance
and licence fees to your vendor of choice...
What I'd seriously want to know is what uses call/cc has been put to,
(besides implementing yet another multi-/co-processing package, yet
another condition system, or the ilk).
The only thing that I've seen where continuations would probably have
been really helpful in CL, would be Screamer.
What other uses have there been in the Scheme community?
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
>>>>> "prm" == Pierre R Mai <····@acm.org> writes:
prm> What I'd seriously want to know is what uses call/cc has been
prm> put to, (besides implementing yet another multi-/co-processing
prm> package, yet another condition system, or the ilk). The only
prm> thing that I've seen where continuations would probably have
prm> been really helpful in CL, would be Screamer.
well besides coroutines, user-level threading systems and condition
systems in Scheme and SML, first-class continuations can be used to
implement backtracking and failure constructs as in Prolog and Icon
(and Screamer). They can also be used for distributed computing; for
example see Kali Scheme:
<URL:http://www.neci.nj.nec.com/PLS/Kali.html>
--
Eric Marsden
Eric Marsden <········@mail.dotcom.fr> writes:
> >>>>> "prm" == Pierre R Mai <····@acm.org> writes:
>
> prm> What I'd seriously want to know is what uses call/cc has been
> prm> put to, (besides implementing yet another multi-/co-processing
> prm> package, yet another condition system, or the ilk). The only
> prm> thing that I've seen where continuations would probably have
> prm> been really helpful in CL, would be Screamer.
>
> well besides coroutines, user-level threading systems and condition
> systems in Scheme and SML, first-class continuations can be used to
> implement backtracking and failure constructs as in Prolog and Icon
> (and Screamer).
Which were the things I'd already mentioned...
> They can also be used for distributed computing; for
> example see Kali Scheme:
>
> <URL:http://www.neci.nj.nec.com/PLS/Kali.html>
This was the kind of thing I was looking for. Thanks, I'll look into
this...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
····@acm.org (Pierre R. Mai) writes:
> What I'd seriously want to know is what uses call/cc has been put to,
> (besides implementing yet another multi-/co-processing package, yet
> another condition system, or the ilk).
If it has not been mentioned already, this paper might be of interest:
Matthew Fuchs:
Escaping the event loop:
an alternative control structure for multi-threaded GUIs
<http://cs.nyu.edu/phd_students/fuchs/index.html>
Regards,
Ole
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3vh2zypfj.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Tim Bradshaw wrote:
>> complete information about every function I might call. So I have to
>> either never stack-allocate or compile two different versions and
>> switch at runtime or something equally horrible.
> Yes. And if you don't want continuations at all, make sure your
> command-line switches [or boot parameters ;-)] are set
> appropriately.
So really, if this was part of CL, implementors either need to spend a
lot of time and money doing this two strategies thing (complete with
possibly two versions of everything they compile, meaning bigger
images and so on), or they need to never stack-allocate, and thus
rule out any efficiency wins that might be gained by doing so.
Which do you think they would do?
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C50FF7.606ADE95@iname.com>
Tim Bradshaw wrote:
> So really, if this was part of CL, implementors either need to spend a
> lot of time and money doing this two strategies thing (complete with
> possibly two versions of everything they compile, meaning bigger
> images and so on), or they need to never stack-allocate, and thus
> rule out any efficiency wins that might be gained by doing so.
>
> Which do you think they would do?
Did I say `part of CL'? Continuations would match very well
some vendor's "KnowledgeStuff" toolkit. [But of course continuations
could cannibalize a bit their `stuff' sales]
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3zosastp5.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Did I say `part of CL'? Continuations would match very well
> some vendor's "KnowledgeStuff" toolkit. [But of course continuations
> could cannibalize a bit their `stuff' sales]
You probably didn't and I'm sorry if I implied you did.
But I think then the lack of call/cc clearly implies that vendors
aren't getting asked for it too much.
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C64254.9CDB3CC9@iname.com>
Tim Bradshaw wrote:
> But I think then the lack of call/cc clearly implies that vendors
> aren't getting asked for it too much.
Sure. Like a real C++ FFI. It should be easier, though :->
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Tim Bradshaw
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <ey3ya7tr2ne.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Sure. Like a real C++ FFI. It should be easier, though :->
I don't understand what you're implying here. Do you think vendors
are getting asked for both real C++ FFIs and call/cc and ignoring
both?
--tim
From: Fernando D. Mato Mira
Subject: Re: cwcc in CL [was Re: That place.. ]
Date:
Message-ID: <38C66394.381DF8CE@iname.com>
Tim Bradshaw wrote:
> > Sure. Like a real C++ FFI. It should be easier, though :->
>
> I don't understand what you're implying here. Do you think vendors
> are getting asked for both real C++ FFIs and call/cc and ignoring
> both?
No. The only thing I might be implying is that one CL vendor had a real
(but broken) C++ FFI, they dropped it and now they propose using CORBA,
as if that would be the same. Obviously, with that kind of approach,
full continuations
enabled the whole time would be just fine!
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Erik Naggum
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <3161257553467929@naggum.no>
* "Fernando D. Mato Mira" <········@iname.com>
| While we are at it, it's pretty amazing no implementor has added call/cc
| yet.
maybe, but much less amazing than that some still believe in call/cc.
#:Erik
From: Fernando D. Mato Mira
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38C3A44F.1D94D54D@iname.com>
Erik Naggum wrote:
> * "Fernando D. Mato Mira" <········@iname.com>
> | While we are at it, it's pretty amazing no implementor has added call/cc
> | yet.
>
> maybe, but much less amazing than that some still believe in call/cc.
And even less amazing than that some believe call/cc is useless
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Erik Naggum
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <3161342090902304@naggum.no>
* "Fernando D. Mato Mira" <········@iname.com>
| And even less amazing than that some believe call/cc is useless
and who would that be? why exaggerate a technical argument into rampant
stupidity?
_nobody_ who understands it believes call/cc is _useless_. that's not
just way too strong a word, it's missing the point _entirely_. given a
particular choice of function calling model, call/cc is very definitely
elegant and the right implementation choice. the question is whether
that model is _productive_ in a much greater context than just whatever
you can cram into a thin, elegant specification.
no model is _useless_, either, as Scheme's model has certainly explored
territory that otherwise would not be explored. all in all, a valuable
contribution to computer science. that doesn't mean we have to _do_ it
that way in practical implementations. research is _supposed_ to produce
a lot of "known dead ends" so other researchers and practitioners alike
know where _not_ to go. in this particular instance, Scheme's function
call model is where you must _not_ go.
that it's time to discard a model doesn't mean it's useless in every or
even many respects, but there might well be some particular respect in
which some jerk would find it completely useless and extrapolate from
that to the general case. I find such arguments completely useless and
excessively disrespectful towards the research activity that led to it.
in short: being wrong is _not_ being useless. being stupid is, however.
#:Erik
From: Dorai Sitaram
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <89uobb$k50$1@news.gte.com>
In article <·················@iname.com>,
Fernando D. Mato Mira <········@iname.com> wrote:
>"Fernando D. Mato Mira" wrote:
>
>> Well, OK, it's not cool to ask everybody to implement this, but it's
>> a valuable extension if you're trying to reuse Scheme code not going crazy about
>> call/cc.
>
>While we are at it, it's pretty amazing no implementor has added call/cc yet.
Well, call/cc is not so cheap that you can just throw
it in. It does something nontrivially beyond
first-order control, and even in pay-only-if-you-use
implementations, this ends up extracting a price by,
at the very least, limiting implementation
choice. That price may not be worth it for CL, and
even for some Schemes.
--d
From: Robert Monfera
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38C0C8C8.8FAC8326@fisec.com>
Barry Margolin wrote:
> The Common Lisp designers made a conscious decision *not* to copy
> this aspect of Scheme, so this would be a fundamental philosophical
> change in the language.
You mean "... _because_ it would be a fundamental philosophical change"?
I recall I've read the reasons for this decision. Maybe it was
something to do with the names, i.e., it is encouraged to have a proper
name for a function that's being invoked, or perhaps that CL has
separate name spaces for variables and functions, and FUNCALL is an
explicit sign of trespassing, showing that a value will be used as the
function. I'd appreciate a pointer to that write-up if someone knows.
AFAIK Rainer implemented this Schemeful feature in his environment.
Robert
From: Barry Margolin
Subject: Re: That place.. (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <5wVv4.76$NC6.1919@burlma1-snr2>
In article <·················@fisec.com>,
Robert Monfera <·······@fisec.com> wrote:
>
>Barry Margolin wrote:
>
>> The Common Lisp designers made a conscious decision *not* to copy
>> this aspect of Scheme, so this would be a fundamental philosophical
>> change in the language.
>
>You mean "... _because_ it would be a fundamental philosophical change"?
Both are true, IMHO. I believe that the philosophy at the time still
exists. So it would have been a change then that they didn't want to make,
and changing it now would also be a philosophical change.
>I recall I've read the reasons for this decision. Maybe it was
>something to do with the names, i.e., it is encouraged to have a proper
>name for a function that's being invoked, or perhaps that CL has
>separate name spaces for variables and functions, and FUNCALL is an
>explicit sign of trespassing, showing that a value will be used as the
>function. I'd appreciate a pointer to that write-up if someone knows.
This sounds like Kent's Lisp1-vs-Lisp2 paper. It's probably on the web
someplace.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, 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.
From: Fernando D. Mato Mira
Subject: Missing special forms? (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38BFA338.D2177D78@iname.com>
While the previous one exhibits a space inefficiency (duplication of macro
code, if it needs to be available at run-time),
trying to implement parallel bindings for a function and a macro can
create a time inefficiency, if the compiler is not good
enough [note that at least one major commercial CL implementation wouldn't
be].
Say you want something like this:
(oplet ((f (lambda (x y) ..))
(m (mlambda (u v) ..)))
m is not visible in f, anf f is not visible in the m macroexpander
You have to do this:
(flet ((#:f (x y) ..))
(declare (inline #:f))
(macrolet ((m (u v) ..))
(flet ((f (x y) (#:f x y)))
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Fernando D. Mato Mira
Subject: Re: Missing special forms? (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38BFC956.B216C8DA@iname.com>
You can also do
(flet ((f (x y) ..)
(#:m <simplified arglist> ..))
(declare (inline #:m)
(macrolet ((m <arglist w/o &aux> (#:m <vars>))
to shift the efficiency issue to macroexpansion time.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Reini Urban
Subject: Re: Missing special forms? (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38bfe64f.15281944@judy>
Fernando D. Mato Mira wrote:
>While the previous one exhibits a space inefficiency (duplication of macro
>code, if it needs to be available at run-time),
>trying to implement parallel bindings for a function and a macro can
>create a time inefficiency, if the compiler is not good
>enough [note that at least one major commercial CL implementation wouldn't
>be].
which one?
--
Reini
From: Fernando D. Mato Mira
Subject: Re: Missing special forms? (was: How to make a mutually recursive macro and function)
Date:
Message-ID: <38BFFBEB.EE09D1A4@iname.com>
Reini Urban wrote:
> which one?
Well, actually, that's regarding the INLINE declaration. Whether it might
automatically inline FLETs
used a single time, and in an operator position, I don't know.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html