Announcing a new release of Lisp1.
Located at: http://blake.mcbride.name
From the documentations:
Lisp1
A portable (ANSI) Common Lisp program that makes Common Lisp operate
as a LISP1 Lisp.
Written and placed in the public domain by:
Blake McBride
·····@mcbride.name
================================================================================
The problem:
Common Lisp (CL) is a LISPn language. This means that symbols can
hold normal values, functions, property lists, etc. at the same time.
Different functions are used to manipulate these different qualities
associated to a given symbol. The problem with this is that code
becomes more complex and API's become large just to support these
concurrent aspects.
In real life using the same symbol to represent a function _and_ a
value (in the form of a variable) at the same time would be really bad
practice. It would make the code very difficult to understand. For
this reason, programmers rarely do this. So, in effect, CL has a lot
of extra facilities and complexity just to support a feature that
programmers generally avoid.
LISP1 dialects associate a symbol with a single value. This single
value can be any value e.g. a number, a list, or a function. Since
functions are treated just like any other value, they can be passed or
assigned as is any other value. In effect, functions become first
class citizens.
(Historical note: CL is a LISPn language mainly for historical reasons
- to be compatible with Lisp's that came before it, not necessarily
because it was generally believed that LISPn was better - although
opinions vary widely as to which is better.)
For example, in CL one would have to write the following:
--------------------------------------------------------------------------------
(defun add (a b)
(+ a b))
(defun subtract (a b)
(- a b))
(defun perform-function (fun a b)
(funcall fun a b))
(perform-function (function add) 5 6)
(perform-function (function subtract) 10 3)
--------------------------------------------------------------------------------
If, on the other hand CL was a LISP1 language you could just do the
following:
--------------------------------------------------------------------------------
(defun add (a b)
(+ a b))
(defun subtract (a b)
(- a b))
(defun perform-function (fun a b)
(fun a b))
(perform-function add 5 6)
(perform-function subtract 10 3)
--------------------------------------------------------------------------------
Note the differences between the definition of perform-function, and
note the difference in how perform-function is used. In fact, in a
LISP1 dialect you can even do the following:
--------------------------------------------------------------------------------
(defun add (a b)
(+ a b))
(setq myadd add)
(myadd 5 6)
(let ((a 5)
(b 10)
(fun (lambda (x y) (+ x y))))
(fun a b))
(setq another-add (lambda (a b) (+ a b)))
(another-add 5 6)
--------------------------------------------------------------------------------
There shouldn't be a need for flet, function, symbol-value, funcall or
even defun.
================================================================================
Lisp1 has been tested with the following Lisp systems:
CLISP
SBCL
ABCL
ECL
Dear Blake McBride,
Thanks for your post.
Please ignore Rainer Joswig, he's one of those old Common Lisp warden
that perpetually smite any progress on innovation that lisp might
have.
Also, from my personal view, please don't use the jargon “lisp1”,
“lisp2”. Instead, say multi-meaning-space and single-meaning-space, or
Common Lisp's model of symbol cell or Scheme's lisp's model of symbol
cell. This, will communicate the concept clearly, and can have some
effect in lessening this old political gash among the lisp factions.
During recent debate here, i outline the reasons here:
• The Jargon “Lisp1” vs “Lisp2”
http://xahlee.org/emacs/lisp1_vs_lisp2.html
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On Jan 27, 12:19 am, Blake McBride <·····@mcbride.name> wrote:
> Announcing a new release of Lisp1.
>
> Located at: http://blake.mcbride.name
>
> From the documentations:
>
> Lisp1
>
> A portable (ANSI) Common Lisp program that makes Common Lisp operate
> as a LISP1 Lisp.
>
> Written and placed in the public domain by:
>
> Blake McBride
> ·····@mcbride.name
http://blake.mcbride.name/software/lisp1/index.html
Den Sun, 27 Jan 2008 06:32:23 -0800 skrev Xah Lee:
> Also, from my personal view, please don't use the jargon “lisp1”,
> “lisp2”. Instead, say multi-meaning-space and single-meaning-space, or
> Common Lisp's model of symbol cell or Scheme's lisp's model of symbol
> cell. This, will communicate the concept clearly, and can have some
> effect in lessening this old political gash among the lisp factions.
Right, because personal made-up terminology will be perfectly clear from
get-go just by the virtue of being invented by the infallible Xah Lee,
and calling names is a well-known technique widely applied for lowering
political tensions. Ad-hominem attacks on Rainer are not even worth
commenting on.
You, sir, are a flaming idiot and it never ceases to amaze me how
competent people I respect find the time and energy to put up with your
offensively arrogant ignorance. Guess I'm not becoming saint anytime soon.
Maciej
In article <··············@news.supernews.com>,
Blake McBride <·····@mcbride.name> wrote:
> Announcing a new release of Lisp1.
>
> Located at: http://blake.mcbride.name
>
> From the documentations:
>
>
> Lisp1
>
> A portable (ANSI) Common Lisp program that makes Common Lisp operate
> as a LISP1 Lisp.
>
> Written and placed in the public domain by:
>
> Blake McBride
> ·····@mcbride.name
>
> ================================================================================
>
> The problem:
>
> Common Lisp (CL) is a LISPn language. This means that symbols can
> hold normal values, functions, property lists, etc. at the same time.
> Different functions are used to manipulate these different qualities
> associated to a given symbol. The problem with this is that code
> becomes more complex and API's become large just to support these
> concurrent aspects.
Symbols are a feature. Get over it.
Where do APIs (!!!) become large because of a Lisp2? I don't
see that.
>
> In real life using the same symbol to represent a function _and_ a
> value (in the form of a variable) at the same time would be really bad
> practice. It would make the code very difficult to understand. For
> this reason, programmers rarely do this. So, in effect, CL has a lot
> of extra facilities and complexity just to support a feature that
> programmers generally avoid.
FUD and incorrect.
>
> LISP1 dialects associate a symbol with a single value. This single
> value can be any value e.g. a number, a list, or a function. Since
> functions are treated just like any other value, they can be passed or
> assigned as is any other value. In effect, functions become first
> class citizens.
FUNCTIONS are first class citizens in Common Lisp, thank you.
>
> (Historical note: CL is a LISPn language mainly for historical reasons
> - to be compatible with Lisp's that came before it, not necessarily
> because it was generally believed that LISPn was better - although
> opinions vary widely as to which is better.)
>
> For example, in CL one would have to write the following:
>
> --------------------------------------------------------------------------------
>
> (defun add (a b)
> (+ a b))
>
> (defun subtract (a b)
> (- a b))
>
> (defun perform-function (fun a b)
> (funcall fun a b))
>
> (perform-function (function add) 5 6)
>
> (perform-function (function subtract) 10 3)
>
> --------------------------------------------------------------------------------
>
> If, on the other hand CL was a LISP1 language you could just do the
> following:
>
> --------------------------------------------------------------------------------
>
> (defun add (a b)
> (+ a b))
>
> (defun subtract (a b)
> (- a b))
>
> (defun perform-function (fun a b)
> (fun a b))
>
> (perform-function add 5 6)
>
> (perform-function subtract 10 3)
From a readability standpoint, the Common Lisp code looks
much more readable, since the FUNCTIONal aspects
are explicit in the code. I can see that a function
is involved and I can see that a function passed
in as a variable is called.
This is one of the worst aspects of Scheme, that code tends
to obfuscated: (((foo a) (((foo b))))) What is it?
> --------------------------------------------------------------------------------
>
> Note the differences between the definition of perform-function, and
> note the difference in how perform-function is used. In fact, in a
> LISP1 dialect you can even do the following:
>
> --------------------------------------------------------------------------------
>
> (defun add (a b)
> (+ a b))
>
> (setq myadd add)
>
> (myadd 5 6)
>
> (let ((a 5)
> (b 10)
> (fun (lambda (x y) (+ x y))))
> (fun a b))
>
> (setq another-add (lambda (a b) (+ a b)))
>
> (another-add 5 6)
In a Lisp2 I write:
(defun add (a b)
(+ a b))
(deff myadd (function add))
(myadd 5 6)
(let ((a 5)
(b 10)
(fun (lambda (x y) (+ x y))))
(funcall fun a b))
(deff another-add (lambda (a b) (+ a b)))
(another-add 5 6)
Hardly much worse.
>
> --------------------------------------------------------------------------------
>
> There shouldn't be a need for flet, function, symbol-value, funcall or
> even defun.
I don't agree with the stuff you are writing. Plus, Common Lisp
is the way it is. Better swim with the water, not against it.
If you want a Lisp1, use Scheme.
I think it is also not correct to write above while not listing
any advantages of Lisp2.
>
> ================================================================================
>
> Lisp1 has been tested with the following Lisp systems:
> CLISP
> SBCL
> ABCL
> ECL
Rainer Joswig escribi�:
>
> In a Lisp2 I write:
>
> (defun add (a b)
> (+ a b))
>
> (deff myadd (function add))
>
> (myadd 5 6)
>
> (let ((a 5)
> (b 10)
> (fun (lambda (x y) (+ x y))))
> (funcall fun a b))
>
> (deff another-add (lambda (a b) (+ a b)))
>
> (another-add 5 6)
>
> Hardly much worse.
Hi Rainer,
Where can I find a definition for deff? I made up my own:
(defmacro deff (name definition)
`(setf (symbol-function ',name) ,definition))
It seems to work, but I fear I could be forgetting something.
Thanks,
Leandro
In article <························@reader.greatnowhere.com>,
Leandro Rios <··················@gmail.com> wrote:
> Rainer Joswig escribi�:
> >
> > In a Lisp2 I write:
> >
> > (defun add (a b)
> > (+ a b))
> >
> > (deff myadd (function add))
> >
> > (myadd 5 6)
> >
> > (let ((a 5)
> > (b 10)
> > (fun (lambda (x y) (+ x y))))
> > (funcall fun a b))
> >
> > (deff another-add (lambda (a b) (+ a b)))
> >
> > (another-add 5 6)
> >
> > Hardly much worse.
>
> Hi Rainer,
>
> Where can I find a definition for deff? I made up my own:
>
> (defmacro deff (name definition)
> `(setf (symbol-function ',name) ,definition))
>
> It seems to work, but I fear I could be forgetting something.
There are two additional things:
1) You can use (SETF FDEFINITION) instead of
(SETF SYMBOL-FUNCTION) .
The latter sets only functions that have a symbol name.
The former also sets functions that for example
have other names - not just symbols.
2) You may want to include an implementation dependent
mechanism to record the source location.
That's also the reason why this is a macro. It uses
side-effects in the compile-time environment to
do this.
For example Genera does:
Command: (macroexpand '(deff myfoo 'foo))
(PROGN
(EVAL-WHEN (COMPILE)
(COMPILER:FUNCTION-DEFINED 'MYFOO))
(FDEFINE 'MYFOO 'FOO T))
Above uses FDEFINE, where (SETF FDEFINITION) would be used nowadays.
>
> Thanks,
>
> Leandro
Blake McBride <·····@mcbride.name> writes:
> Announcing a new release of Lisp1.
[...]
> A portable (ANSI) Common Lisp program that makes Common Lisp operate
> as a LISP1 Lisp.
Not to diminish your efforts, but I wonder why you would bother doing this, or
why one would bother using this.
If the use of Lisp1 is important to a programmer, they should just use a real
Lisp1 language. Pick a decent scheme implementation.
If the use of Common Lisp is important, than it makes no sense but to use
anything else but the real thing. CL is LispN, and you need to get your head
around that to use it properly.
Otherwise all one is doing is creating an artificial problem to work around,
and that seems like a waste of time to me.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Doing it is important, because it provides a solution that people may
want. e.g. people who wants to use Common Lisp but want Scheme lisp's
model of the symbol cell.
If it so happens that enough people use it, it paves way for future
change for Common Lisp.
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On Jan 27, 10:43 am, Ray Blaak <········@STRIPCAPStelus.net> wrote:
> Blake McBride <·····@mcbride.name> writes:
> > Announcing a new release of Lisp1.
> [...]
> > A portable (ANSI) Common Lisp program that makes Common Lisp operate
> > as a LISP1 Lisp.
>
> Not to diminish your efforts, but I wonder why you would bother doing this, or
> why one would bother using this.
>
> If the use of Lisp1 is important to a programmer, they should just use a real
> Lisp1 language. Pick a decent scheme implementation.
>
> If the use of Common Lisp is important, than it makes no sense but to use
> anything else but the real thing. CL is LispN, and you need to get your head
> around that to use it properly.
>
> Otherwise all one is doing is creating an artificial problem to work around,
> and that seems like a waste of time to me.
>
> --
> Cheers, The Rhythm is around me,
> The Rhythm has control.
> Ray Blaak The Rhythm is inside me,
> ········@STRIPCAPStelus.net The Rhythm has my soul.
Xah Lee wrote:
> Doing it is important, because it provides a solution that people may
> want. e.g. people who wants to use Common Lisp but want Scheme lisp's
> model of the symbol cell.
>
> If it so happens that enough people use it, it paves way for future
> change for Common Lisp.
>
> Xah
> ···@xahlee.org
> ∑ http://xahlee.org/
>
Well put.
In article <···············@news.supernews.com>,
Blake McBride <·····@mcbride.name> wrote:
> Xah Lee wrote:
> > Doing it is important, because it provides a solution that people may
> > want. e.g. people who wants to use Common Lisp but want Scheme lisp's
> > model of the symbol cell.
> >
> > If it so happens that enough people use it, it paves way for future
> > change for Common Lisp.
> >
> > Xah
> > ···@xahlee.org
> > ∑ http://xahlee.org/
> >
>
> Well put.
But bullshit. The 'Symbol Cell' has nothing to do with that.
(lambda (b)
(let ((foo 10))
(flet ((foo (bar)
(+ bar 10)))
(foo (+ foo b)))))
This is Lisp2 (Common Lisp) code. In the code the name
FOO is used to reference a variable and a function.
THERE ARE NO SYMBOLS INVOLVED. ZERO. Not even one.
+ can be open-coded by the compiler. Symbol gone.
FOO will be replaced by references. Symbol gone.
BAR will be replaced by a reference. Symbol gone.
b will be replaced by a reference. Symbol gone.
CL-USER> (disassemble *)
48782EF0: .ENTRY "LAMBDA (B)"(b) ; (FUNCTION (T) NUMBER)
F08: POP DWORD PTR [EBP-8]
F0B: LEA ESP, [EBP-32]
F0E: CMP ECX, 4 ; [:NON-LOCAL-ENTRY]
F11: JNE L0
F13: MOV [EBP-12], EDX
F16: MOV EDX, [EBP-12] ; No-arg-parsing entry point
; [:NON-LOCAL-ENTRY]
F19: MOV EDI, 40
;;; [12] (+ FOO B)
F1E: CALL #x100001D0 ; #x100001D0: GENERIC-+
; [:CALL-SITE]
F23: MOV ESP, EBX ; [:SINGLE-VALUE-RETURN]
;;; [6] (FLET ((FOO (BAR)
;;; (+ BAR 10))) ..)
F25: MOV EDI, 40 ; [:BLOCK-START]
;;; [10] (+ BAR 10)
F2A: CALL #x100001D0 ; #x100001D0: GENERIC-+
; [:CALL-SITE]
F2F: MOV ESP, EBX ; [:SINGLE-VALUE-RETURN]
F31: MOV ECX, [EBP-8] ; [:BLOCK-START]
F34: MOV EAX, [EBP-4]
F37: ADD ECX, 2
F3A: MOV ESP, EBP
F3C: MOV EBP, EAX
F3E: JMP ECX
F40: L0: BREAK 10 ; Error trap
F42: BYTE #x02
F43: BYTE #x1A ; INVALID-ARGUMENT-COUNT-ERROR
F44: BYTE #x4F ; ECX
;
Do you see any SYMBOL in the compiled code? I don't see any.
The compiler will compile it to machine code and no
lookup whatsoever will be done on symbols. This
is in Common Lisp. There are no 'Symbol Cells' that
will be used here.
Please get this straight before you guys talk again over
symbols.
Symbols come into play when one uses symbols in a Lisp2.
For example as global names for functions.
Lisp1 or Lisp2 is an issue that exists independent of symbols.
Den Sun, 27 Jan 2008 22:06:51 +0100 skrev Rainer Joswig:
> The compiler will compile it to machine code and no lookup whatsoever
> will be done on symbols. This is in Common Lisp. There are no 'Symbol
> Cells' that will be used here.
>
> Please get this straight before you guys talk again over symbols.
>
> Symbols come into play when one uses symbols in a Lisp2. For example as
> global names for functions.
>
> Lisp1 or Lisp2 is an issue that exists independent of symbols.
And, as has been recently explained in great detail, Scheme symbols don't
even have cells. So no matter how hard you try, you can't get the "Scheme
model of the symbol cell".
Cheers,
Maciej
On Jan 27, 11:26 am, Xah Lee <····@xahlee.org> wrote:
> Doing it is important, because it provides a solution that people may
> want. e.g. people who wants to use Common Lisp but want Scheme lisp's
> model of the symbol cell.
Wanting some other model of the symbol cell is just idle nonsense
which has nothing to do with shipping an application.
A different model of the symbol cell doesn't help you write software
in any way, it's just different.
You gain absolutely no expressive power, nor do you lose any.
What you do lose is your personal effort by thinking about this and
dicking around with bullshit code to do it.
Ray Blaak wrote:
> Blake McBride <·····@mcbride.name> writes:
>> Announcing a new release of Lisp1.
> [...]
>> A portable (ANSI) Common Lisp program that makes Common Lisp operate
>> as a LISP1 Lisp.
>
> Not to diminish your efforts, but I wonder why you would bother doing this, or
> why one would bother using this.
>
> If the use of Lisp1 is important to a programmer, they should just use a real
> Lisp1 language. Pick a decent scheme implementation.
>
> If the use of Common Lisp is important, than it makes no sense but to use
> anything else but the real thing. CL is LispN, and you need to get your head
> around that to use it properly.
>
> Otherwise all one is doing is creating an artificial problem to work around,
> and that seems like a waste of time to me.
>
I have been using one type of Lisp or another since 1980. I have a
personal preference for a LISP1 Lisp. I have spent most of my Lisp time
with Scheme for the last ten years mainly for this reason. In the
language space offered by Common Lisp and Scheme I have the following
_personal_ opinions. Again these are just personal opinions.
1. LISP1 is the most important thing to me which is why I have been
using Scheme.
2. There are a number of design decisions associated with Scheme which
I strongly disagree with.
3. I find that the only important (to me) design decision I don't like
about CL is the LISPn thing.
This situation leaves me with a number of choices as follows:
A. Just pick one language and use it as-is.
B. Pick one and fix the things I don't like.
C. Write my own language.
I like option C the best but (like everyone else) have time limitations.
I'll probably end up doing this in the very long run.
Option A is just not in my nature.
Ten years ago I picked Scheme and have been fixing it ever since (with
packages similar to the Lisp1 thing I wrote for CL). After all this
time I am now beginning to think that fixing the one thing I don't like
about CL is easier than fixing the N number of things in Scheme.
On another note, I'd sure appreciate not getting beaten up all the time.
I mean no one any harm or ill will. I clearly don't know as much CL as
many of you out there, nor am I capable of wording every comment in the
most technically precise and politically correct way. I have personal
preferences and opinions just like everyone else. I love Lisp as much
as any of you. In my own way I am trying to help the cause so to speak.
I appreciate your help when you care to give it, and I offer what help
I can when I can. Everyone of us has different opinions, levels of
knowledge and experience, and preferences. It would be great if we
could help one another when we can and care to, and allow for those of
us who have less expertise or capability, or a different opinion.
Blake McBride
From: Richard M Kreuter
Subject: Re: Announcing a new release of Lisp1
Date:
Message-ID: <87ejc3gf83.fsf@progn.net>
Blake McBride <·····@mcbride.name> writes:
> Ten years ago I picked Scheme and have been fixing it ever since
> (with packages similar to the Lisp1 thing I wrote for CL). After
> all this time I am now beginning to think that fixing the one thing
> I don't like about CL is easier than fixing the N number of things
> in Scheme.
>
> On another note, I'd sure appreciate not getting beaten up all the
> time.
You cross-posted to a Common Lisp forum (c.l.l) to announce a package
whose declared motivation flies in the face of the day-to-day
experience of Common Lisp users:
| "In real life using the same symbol to represent a function _and_ a
| value (in the form of a variable) at the same time would be really
| bad practice. It would make the code very difficult to understand.
| For this reason, programmers rarely do this. So, in effect, CL has
| a lot of extra facilities and complexity just to support a feature
| that programmers generally avoid."
In point of fact you are mistaken: Common Lisp users do take advantage
of multiple namespaces, and don't avoid the facilities for the
namespace separation (sharp-quote, FLET, etc). Indeed, many of us
enjoy this feature of the language we've chosen, and aren't looking
for anybody to "fix" this for us.
For my part, when I've programmed in Scheme (or C or Javascript), I
have been frustrated by the single namespace, which feels to me more
an impoverishment than a benefit.
> I mean no one any harm or ill will. I clearly don't know as much CL
> as many of you out there, nor am I capable of wording every comment
> in the most technically precise and politically correct way. I have
> personal preferences and opinions just like everyone else. I love
> Lisp as much as any of you. In my own way I am trying to help the
> cause so to speak. I appreciate your help when you care to give it,
> and I offer what help I can when I can. Everyone of us has
> different opinions, levels of knowledge and experience, and
> preferences. It would be great if we could help one another when we
> can and care to, and allow for those of us who have less expertise
> or capability, or a different opinion.
By showing up in a forum for LispN users to announce a "solution" to
the "problem" of multiple namespaces, you appear as if you don't
consider the opinions that are likely to be found in a community of
LispN users. What response other than hostility do you expect to such
an apparently chauvinistic course of action?
(That you've also seconded super-idiot Xah Lee's sentiment that
depriving us of our multiple namespaces is an act of progress doesn't
help your case, either.)
--
RmK
Blake McBride <·····@mcbride.name> writes:
> On another note, I'd sure appreciate not getting beaten up all the time. I
> mean no one any harm or ill will.
Nor do I. I don't believe I was beating up on you, but if you think I was
then, hey, I apologize.
> I have personal preferences and opinions just like everyone else.
And you state them. And responses are stated back.
My opinion is that major language work arounds like trying to make CL to be
Lisp1 are not worth the effort. This is nothing personal against you, but only
based on technical reasons.
Consider that your Lisp1 CL code will have to be used in conjunction with 3rd
party libraries. People have to maintain your code after you have moved on. If
you are doing something different from the fundamental style of the language,
your code will be hard to use for other CL programmers.
In the case of your language preferences, the "correct" thing would be for you
to make your own language. But languages cannot really be used in isolation,
and your code fundamentally will need to work with other programmer's code.
So, in practice, finding the using the language with the least amount of warts
is the only effective solution.
Or just use your Lisp1 CL package. Hey, you might luck out and it might catch
on. But you have to be prepared to be pratical if it doesn't, since you can't
program in isolation.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Den Sun, 27 Jan 2008 13:54:37 -0600 skrev Blake McBride:
> On another note, I'd sure appreciate not getting beaten up all the time.
> I mean no one any harm or ill will. I clearly don't know as much CL as
> many of you out there, nor am I capable of wording every comment in the
> most technically precise and politically correct way. I have personal
> preferences and opinions just like everyone else. I love Lisp as much
> as any of you. In my own way I am trying to help the cause so to speak.
The problem is not with your preferences. The problem is with your widely
inaccurate and plain wrong assessments of how LispN is a problem and a
wart on the language your package fixes. It's not a wart in the opinion
of the overwhelming majority of c.l.l denizens, and so your claims to the
contrary get rightly bashed. Stop claiming things that are demonstrably
false, and you'll stop getting flak for doing that.
Cheers,
Maciej
Interesting.
I'm doing Lispy design too, and I came down with a slightly
different split between the Lisp-1 and Lisp-2 questions. I
guess you might call it a Lisp-H if you have to have names for
things.
I'm using hierarchical naming, where subfields or "attributes"
are name extensions. "vehicle", "vehicle|motor",
"vehicle|motor|displacement", "vehicle|wheels", etc, can all have
different values, but when I pass "vehicle" to a function, and
it gets bound to a local name like "fredscar", all the
hierarchical extensions are automatically available in that
function, as "fredscar|motor", "fredscar|motor|displacement"
etc.
One interesting bit that falls out is that I can pass a
partial hierarchical name instead of a simple name, like
"vehicle|motor", and if it gets bound to a local name like
"vroom", then "vroom" and "vroom|displacement" are available
in the function.
There's no multiplicity of mutators and accessors as in a
typical Lisp-N, because the information about what attribute
(what hierarchical subfield) to set and access is carried in
the extended name rather than in the name of the mutator or
accessor. Even things like scheme's "set-car!" and "set-cdr!"
go away, because (assuming your cons cell is named "place"),
you just call (set! place|car) or (set! place|cdr) instead.
Bear
Blake McBride wrote:
> Ray Blaak wrote:
>
> I have been using one type of Lisp or another since 1980. I have a
> personal preference for a LISP1 Lisp. I have spent most of my Lisp time
> with Scheme for the last ten years mainly for this reason. In the
> language space offered by Common Lisp and Scheme I have the following
> _personal_ opinions. Again these are just personal opinions.
>
> 1. LISP1 is the most important thing to me which is why I have been
> using Scheme.
I would appreciate you to elaborate more on this point and If those
warts may be cured by R6RS?
>
> Blake McBride
Johann
Johann H�chtl wrote:
> Blake McBride wrote:
>> Ray Blaak wrote:
>
>>
>> I have been using one type of Lisp or another since 1980. I have a
>> personal preference for a LISP1 Lisp. I have spent most of my Lisp
>> time with Scheme for the last ten years mainly for this reason. In
>> the language space offered by Common Lisp and Scheme I have the
>> following _personal_ opinions. Again these are just personal opinions.
>>
>> 1. LISP1 is the most important thing to me which is why I have been
>> using Scheme.
>
> I would appreciate you to elaborate more on this point and If those
> warts may be cured by R6RS?
I'd be happy to. In fact I have posted articles about some of the
things in the past. May I suggest that rather than me posting this,
perhaps I can e-mail these comments to you. I can't imagine the beating
I'd take if I posted it. Perhaps you can e-mail me your e-mail address.
If I have to post it, though, I'll just post it to c.l.scheme and not .lisp.
Blake McBride
From: Abdulaziz Ghuloum
Subject: Re: Announcing a new release of Lisp1
Date:
Message-ID: <fnlhu0$vsp$1@aioe.org>
Blake McBride wrote:
> I'd be happy to. In fact I have posted articles about some of the
> things in the past. May I suggest that rather than me posting this,
> perhaps I can e-mail these comments to you. I can't imagine the beating
> I'd take if I posted it. Perhaps you can e-mail me your e-mail address.
I was also going to ask you a similar thing. You said you liked
everything in CL except the lisp-2-ness of it. You also said you
disagreed with some of the design decisions of Scheme but did not
elaborate on those. So, yes, I too am interested in knowing what
those are.
Aziz,,,
PS. I would leave any mention of R6 vs. R5 in the thread if we're
going to get anywhere in c.l.s.
PS2. You can leave c.l.l. out if you think it's better that way.
PS3. Or you can CC me in your email :-)
Abdulaziz Ghuloum wrote:
> Blake McBride wrote:
>
>> I'd be happy to. In fact I have posted articles about some of the
>> things in the past. May I suggest that rather than me posting this,
>> perhaps I can e-mail these comments to you. I can't imagine the
>> beating I'd take if I posted it. Perhaps you can e-mail me your
>> e-mail address.
>
> I was also going to ask you a similar thing. You said you liked
> everything in CL except the lisp-2-ness of it. You also said you
> disagreed with some of the design decisions of Scheme but did not
> elaborate on those. So, yes, I too am interested in knowing what
> those are.
>
>
> Aziz,,,
>
> PS. I would leave any mention of R6 vs. R5 in the thread if we're
> going to get anywhere in c.l.s.
>
> PS2. You can leave c.l.l. out if you think it's better that way.
>
> PS3. Or you can CC me in your email :-)
Okay here is one (which R6 doesn't fix).
Contradiction in separation of NIL and #f
Lisp has long used NIL as "false" or #f. This was very convenient
since lisp is a list processing language, traversing through a list is
very often done. Having NIL and #f equal means one could use:
(while lst ...
or
(if lst ...
With the separation of NIL and #f in scheme one is forced into:
(while (not (null? lst)) ...
or
(if (not (null? lst)) ...
The argument for separating NIL and false was in the name of clarity
as opposed to depending on a coincidence. It would be much more clear
(to a beginner?) what was going on. (Although, if you really want to
be clear, perhaps we should all program in ADA. ADA is a language in
which virtually every line of code has to do with clarity and
virtually none has to do with solving the problem at hand!)
The problem is that scheme has eliminated, rather arbitrarily, one
instance of dependence on a trick but left so many others that it
renders the NIL / false separation no more than a constant annoyance.
For example, if NIL and #f are kept apart, why allow anything except
#f equal true? Yes, I know it is very convenient (just like #f and
NIL being equal), but it is also "unclear". Having:
(if "abc" 6 7)
return 6 is absolute nonsense. Scheme has chosen clarity and
correctness in one instance and convenience in another. It is very
inconsistent. If you wanted to be truly consistent:
(+ "abc" 6)
returns a type error. So:
(if "abc" 6 7)
should also return a type error. The same is true for scheme's:
and
or
not
cond
etc.
Look, ADA already has the market on clarity and correctness. Lisp and
scheme have the elegant, expressiveness, and power market. Why
arbitrarily go down the clarity path with the separation of NIL and #f
- it is a mistake. The only other "consistent" choice is to separate
#t from all else, make all logic operations require #t or #f, and make
scheme the ADA of lisp.
Blake McBride
·····@mcbride.name
Blake McBride <·····@mcbride.name> wrote:
«[Scheme's] Contradiction in separation of NIL and #f»
Great point! I fully agree.
A bit rambling of this issue with regards to Mathematica.
In Mathematica, there's symbols True and False. If a predicate expect
a boolean but something other than True or False is given, then the
expression evaluates to itself. (i.e. without resolving into anything)
Example:
In[1]:=
If[True,3,4]
Out[1]=
3
In[2]:=
If[False,3,4]
Out[2]=
4
In[3]:=
If[something,3,4]
Out[3]=
If[something,3,4]
---------------------
Here's some personal story about how i ventured into lisp.
The path of my computing experience is kinda unusual like most other
things about me. In 1991, i was 23, and was attending a 2-year
community college in California. (DeAnza College and Foothill college)
(i have never had highschool (more or less never had a _chance_ to,
actually.))
During these college years (which is about 1991-1994, rather unusually
long for a 2-year community college), i've took all math courses they
offered (roughly equivalent to math classes of first 2 years in a 4
years university; culminating in multi-var calculus and a intro course
on Differential Equations and Linear Algebra, but no Abstract Algebra
nor Analysis proper), but i've never took any computer science
courses. (i think i might have taken a Pascal course)
It is also during the early 1990s, i started to learn programing on my
own. My first “language” is the one in HP-28s programable scientific
calculator. I remember having wrote a program to solve the 8-queens
problem all on my own. (without knowing or heard of the term back-
tracking) (see http://xahlee.org/prog/hp28s/hp28s.html )
And, during these years i bought Mathematica (because i heard it's the
best math tool and i love math and wanted to have the best tool). I
taught myself Mathematica and wrote some programs for visualizing
plane curves. ( see http://xahlee.org/SpecialPlaneCurves_dir/specialPlaneCurves.html
)
By 1997, i'm one of the world's top Mathematica application-programing
expert. But the curious thing is that, i have absolutely no idea what
is a compiler, parser, lexer, and absolutely have no faintest idea how
Operating System worked or its basic structure or purpose in technical
terms, and have absolutely no idea how networking worked. Do not even
have a practical concept of what's a computing protocol (as in TCP/
IP). Absolutely do not know anything about “unix”, and vividly
remember that i don't know what is “tar” and “gzip” (just know that
these are something in “unix workstations” and some mysterious GNU).
(during all these years up to 1997, i was using Mac, being what a Mac
fan might call a “power user” (as a computer user (as opposed to a
programer); and using the mouse; in the days when Macs are just Finder
and Multi-Finder, and used by Desktop publishing, with MacUser and
MacWorld magazinings publishing tricks and software application
reviews etc. (e.g. Microsoft Word, Word Perfect, Nesus Writer,
Spreadsheets...etc)))
I must stress, i have absolutely no concrete idea about anything that
a normal computer science student would know in his first year. I do
not have any concrete idea what IS a language specification (such as
Java lang spec or Common Lisp “Hyperspec” or Emacs Lisp Reference
Manual, etc) I have close to absolutely no knowledge to how ANY other
computing languages. Put in another way, i wouldn't know how to write
a Hello Word in any other language. I have no notion of what's a
“white paper”, “functional programing”, and DO NOT understand (or even
heard of) the meaning of “side effect” (in the context of functional
programing). (i vividly recall, the first time i heard the term “side
effect”, is in 1995 when i was trying to describe a nature of the code
i wrote in some verbose manner, to Stephen Wolfram (in the sense a
student is trying to present his idea), and he said “[you mean] side
effect”, and i was like “Yeah, exactly, ‘side effect’!” (and feeling
enlightened how the phrase described the situation well).)
The gist of this is that, from my programing experience from 1991 to
about 1997, i learned programing only in HP-28s and Mathematica, by
the shear reading of their manual from cover to cover (practically
several times), while having just about no concept of any programing a
1st year computer science student would know. (I do know, of course
the concept of algorithm, as that is essential to programing and is
also a fundamental concept in math and discrete math, which i have
learned a lot mostly by myself too. (But i do not at the time know
anything actual, typical Algorithms that are taught, such as sorting
algorithms, tree walkers, etc) (i have tried to read Knuth's Art Of
Programing but it was pretty imcomprehensible))
From about 1997 onwards, i started to study most of these things,
starting with unix and perl, by sheer reading of the manuals and
documentations and books and hands on coding in them. (by 2000, i'm
fairly a unix admin and perl expert, with knowledges in SQL/database,
working knowledeg of IP protocols... etc, actually working in start-
ups in Sillicon Valley's tech boom since late 1998.)
Ok, the main point i started to write this personal history, is my
first encounter with Lisp. (the previous paragraphs are just intro.)
Although lacking a formal or conventional education, i'm by birth
fairly intelligent and by nature very curious. This means i have read
a lot of books or texts or literatures i have in contact with and in
library (was a avid library visitor), such as the massive number of
programing FAQs and FAQs of other subjects (such as BDSM) etc. So, it
is very present in my awareness, that there is a language called Lisp,
and is supposed to be extremely powerful and beautiful. And, at the
time, i have heard, that Scheme, is the most beautiful and elegant
language that exists. (this is my reading impression, anyway) And, i
heard that the book “The Structure and Interpretation of Computer
Programs” by Harold Abelson et al, is the best computer science book.
So, i started to read it and learn Scheme.
Remember, at the time i'm a master of Mathematica _the language_
itself, yet do not know much about the basics of computer science.
When i started to learn Scheme, the first thing that hit me is the
cons business. To me, who are accustomed to Mathematica, finding the
cons business weird and unwieldy. It puzzled me. I was thinking, how
can a elegant language have this? Certainly in Mathematica i can
extract and manipulate tree structure far more easily. At the time,
since i barely have basic knowledge of any computer science subjects,
i was greatly puzzled about the situation. (in fact made a newsgroup
post in comp.lang.scheme (and was flamed by one Erik Naggum) (this is
1998 or 1999, i think))
Of course, today, with various levels of expertise in several
languages (Mathematica, emacs lisp, perl, php, javascript, sql, java,
Linden Scripting Lang (Second Life virtual world), inert langs (HTML/
CSS/LaTeX,POV-Ray ...)) and have read countless tech papers and worked
in complex software, data centers, and wallowed in all kinds of
industrial spaghetti code with non-existent documentations, i know for
a certainly, that Mathematica, which perchance to be my first
language, is in fact the world's _most_ advanced and high-level
language, bar none.
(this short personal account is not supposed to be a pitch for
Mathematica. It just came out that way. There are, of course other
langs, depending on context and area of application, are equal quality
as Mathematica. For example, i would think Haskell, erlang, ML/OCaml
family etc would qualify, but i just have not actually learned these)
(gee, i just typed as quickly as possible and it came out to be over 1
thousand words of a brief personal bio of my computing experiences.
Good for me! The orginial intention was just to describe my first
impression of Scheme)
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On Jan 28, 5:48 pm, Blake McBride <·····@mcbride.name> wrote:
> Okay here is one (which R6 doesn't fix).
>
> Contradiction in separation of NIL and #f
>
> Lisp has long used NIL as "false" or #f. This was very convenient
> since lisp is a list processing language, traversing through a list is
> very often done. Having NIL and #f equal means one could use:
>
> (while lst ...
> or
> (if lst ...
>
> With the separation of NIL and #f in scheme one is forced into:
>
> (while (not (null? lst)) ...
> or
> (if (not (null? lst)) ...
>
> The argument for separating NIL and false was in the name of clarity
> as opposed to depending on a coincidence. It would be much more clear
> (to a beginner?) what was going on. (Although, if you really want to
> be clear, perhaps we should all program in ADA. ADA is a language in
> which virtually every line of code has to do with clarity and
> virtually none has to do with solving the problem at hand!)
>
> The problem is that scheme has eliminated, rather arbitrarily, one
> instance of dependence on a trick but left so many others that it
> renders the NIL / false separation no more than a constant annoyance.
> For example, if NIL and #f are kept apart, why allow anything except
> #f equal true? Yes, I know it is very convenient (just like #f and
> NIL being equal), but it is also "unclear". Having:
>
> (if "abc" 6 7)
>
> return 6 is absolute nonsense. Scheme has chosen clarity and
> correctness in one instance and convenience in another. It is very
> inconsistent. If you wanted to be truly consistent:
>
> (+ "abc" 6)
>
> returns a type error. So:
>
> (if "abc" 6 7)
>
> should also return a type error. The same is true for scheme's:
>
> and
> or
> not
> cond
> etc.
>
> Look, ADA already has the market on clarity and correctness. Lisp and
> scheme have the elegant, expressiveness, and power market. Why
> arbitrarily go down the clarity path with the separation of NIL and #f
> - it is a mistake. The only other "consistent" choice is to separate
> #t from all else, make all logic operations require #t or #f, and make
> scheme the ADA of lisp.
>
> Blake McBride
> ·····@mcbride.name
Scheme has many functions which have "unspecified" returns. This is
somewhat arbitrary, and runs contrary to the whole s-expression style
of programming. For example, if you have two variables you want to
set to the same value it would be nice to say:
(set! abc (set! def 55))
like you can in Common Lisp. But in Scheme set! doesn't return a
defined result so you are forced into:
(set! abc 55)
(set! def abc)
In Scheme you would have to write:
(set! abc 55)
(if (> def abc)
......
instead of:
(if (> def (set! abc 55))
.....
If you think it's no big deal then why the heck does "cond" and "if"
return a result? It doesn't in most other languages. The reason "if"
returns a result is to take advantage of the nested s-expression style
of programming that lends itself to lisp style languages rather than a
line by line style of programming like Fortran. If Scheme were
consistent then either "if" would return no result or set! would.
Worse yet, there are many function Scheme which return valid responces
most of the time and "unspecified" values at other times. You don't
know whether you are coming or going.
What do you do if a "case" falls off and returns "unspecified"?
Wouldn't nil be a little more predictable?
The same is true for eqv?, eq?, equal?, set-cdr!, set-car!, memq,
assq, string-set!, pair?, display, etc......
The bottom line is that describing the return of a function as
"unspecified", especially only under certain circumstances, leaves
programs which ultimately run in "unspecified" ways. All functions
should either return a specified, predictable result or they should
signal an error, period.
The issues here are consistency, predictability, and convenience.
Blake McBride
Blake McBride <·····@mcbride.name> wrote:
> Scheme has many functions which have "unspecified" returns. This is
> somewhat arbitrary, and runs contrary to the whole s-expression style
> of programming.
> [full post follows below my sig]
I whole-heartedly agree here.
I feel compelled to show Mathematica's behavior here. (Noting here,
that Mathematica isn't suitable for many computing tasks where Lisp
is)
In Mathematica, everyhing returns a value. And, the value returned by
a particular function always have the same structure (i.e. the shape
of the tree), even if the result is empty. (e.g. If a “list filtering”
function like Cases does not have any matches for items, it returns
the empty list.)
Examples:
In[15]:=
Set[abc,3]
Out[15]=
3
In[16]:=
If[Greater[abc,Set[def,2]],doThis]
Out[16]=
doThis
In[17]:=
Cases[{3,4,5},2]
Out[17]=
{}
The importance that every function always returns the same structure,
regardless what is its arguments, is that when sequencing functions
together, each function can always depends on the un-changing
structure of previous function's output. (as opposed to, having the
programer embedding If statements in his code, as most lang needs to
do)
When i was learned some Scheme lisp, cursorily, in about 1999, and
much more in depth of emacs lisp in 2005, i find that lisps in
general, do not rely on the idea that functions should always return
the same structure. (In fact, i find that in lisps the list/tree isn't
that much important. In Mathematica, the List[] and in general the
form “f[]” is UTMOST important concept in the language. The whole
language MUST rely on the uniform, regular, struture of every
expression. And in Mathematica, EVERYTHING is a expression. (the
heavily reliance on the uniform nested structure is partly because
Mathematica relies on _structural_ pattern matching as its major
computational model) (for lispers trying to get some idea of this:
think of programing everything in lisp using only lisp's macros.
(you'll see that the _form_ is extremely important.)))
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On Jan 29, 3:45 am, Xah Lee <····@xahlee.org> wrote:
> [...] i know for
> a certainly, that Mathematica, which perchance to be my first
> language, is in fact the world's _most_ advanced and high-level
> language, bar none.
On Jan 29, 4:41 am, Xah Lee <····@xahlee.org> wrote:
>
> I feel compelled to show Mathematica's behavior here. (Noting here,
> that Mathematica isn't suitable for many computing tasks where Lisp
> is)
I guess Kenny must be on vacation.
Still...
Bwahahahahaha!
I would further add that Scheme should define argument evaluation order.
Compilers can be written to support a particular order just as well as
another order. This is no argument for unspecified argument evaluations
order. Having the argument evaluation order unspecified is a huge and
totally unnecessary opportunity for porting bugs.
Blake McBride
···········@yahoo.de wrote:
> On Jan 30, 3:12 pm, Blake McBride <·····@mcbride.name> wrote:
>> I would further add that Scheme should define argument evaluation order.
>> Compilers can be written to support a particular order just as well as
>> another order. This is no argument for unspecified argument evaluations
>> order. Having the argument evaluation order unspecified is a huge and
>> totally unnecessary opportunity for porting bugs.
>>
>> Blake McBride
>
>
> As a Scheme lover who used Bigloo for a physics related phd on a daily
> basis for over a couple of years i'd like to comment. after reading
> the thread i really have to agree with xa lee that you got a lot of
> unsubstantiated criticism. but one could understand them too: not yet
> another language.
>
> i used bigloo as it is and have no clue how to write a scheme macro.
>
> HOWEVER, i wonder nobody has reacted to your comment that Scheme
> macros are utterly complicated compared to Lisp macros.
>
> Anyone here who might not agree and believes Lisp macros are fairly
> complicated.
>
> I have never heard of Lisp1 before your postings but let me ask: Lisp1
> compared to Common Lisp is similar to comparing C to C++ "richness"
> wise? Does Lisp1 also share 1000 keywords.
Lips1 vs. Common Lisp is completely different from C vs. C++. See my
Web site (under Dynace) for an article about C++. See:
http://www.nhplace.com/kent/Papers/Technical-Issues.html
for an article talking about the Lisp1 issue.
Blake McBride
http://blake.mcbride.name
On Wed, 30 Jan 2008 09:12:43 -0600, Blake McBride <·····@mcbride.name>
wrote:
>
>I would further add that Scheme should define argument evaluation order.
> Compilers can be written to support a particular order just as well as
>another order. This is no argument for unspecified argument evaluations
>order. Having the argument evaluation order unspecified is a huge and
>totally unnecessary opportunity for porting bugs.
>
The only reason for specifying order is to guarantee sequencing of
side effects. Scheme was originally conceived of as a mostly
functional language ... it was intended that most code should be side
effect free (as much as possible anyway and still be a useful language
in the late 1970s). Other arguments for unspecified order are more
optimization possibilities and parallel evaluation.
I don't particularly agree with Scheme's choice either, but I do
understand why they made it.
George
--
for email reply remove "/" from address
(removed comp.lang.scheme, only relevant to comp.lang.lisp)
On Wed, 30 Jan 2008, Blake McBride wrote:
>
> I would further add that Scheme should define argument evaluation order.
> Compilers can be written to support a particular order just as well as
> another order. This is no argument for unspecified argument evaluations
> order. Having the argument evaluation order unspecified is a huge and
> totally unnecessary opportunity for porting bugs.
>
Scheme is not haskell, so I agree about that.
BTW, does common lisp specify the order of arguments?
In article <·································@notam02.uio.no>,
"Kjetil S. Matheussen" <··············@notam02.no> wrote:
> (removed comp.lang.scheme, only relevant to comp.lang.lisp)
>
> On Wed, 30 Jan 2008, Blake McBride wrote:
>
> >
> > I would further add that Scheme should define argument evaluation order.
> > Compilers can be written to support a particular order just as well as
> > another order. This is no argument for unspecified argument evaluations
> > order. Having the argument evaluation order unspecified is a huge and
> > totally unnecessary opportunity for porting bugs.
> >
>
> Scheme is not haskell, so I agree about that.
> BTW, does common lisp specify the order of arguments?
Yes: evaluation of arguments is left to right in Common Lisp.
On 2008-01-30, Rainer Joswig <······@lisp.de> wrote:
> In article <·································@notam02.uio.no>,
> "Kjetil S. Matheussen" <··············@notam02.no> wrote:
>
>> (removed comp.lang.scheme, only relevant to comp.lang.lisp)
>>
>> On Wed, 30 Jan 2008, Blake McBride wrote:
>>
>> >
>> > I would further add that Scheme should define argument evaluation order.
>> > Compilers can be written to support a particular order just as well as
>> > another order. This is no argument for unspecified argument evaluations
>> > order. Having the argument evaluation order unspecified is a huge and
>> > totally unnecessary opportunity for porting bugs.
>> >
>>
>> Scheme is not haskell, so I agree about that.
>> BTW, does common lisp specify the order of arguments?
>
> Yes: evaluation of arguments is left to right in Common Lisp.
There was a previous discussion of the issue of argument evaluation order in
this newsgroup, March, 2005. In that discussion, two arguments in support of
unspecified argument evaluation order were identified:
1. Potential for optimization given a compiler that could/would re-arrange the
order of argument evaluation (at compile time);
2. (Run-time) support for parallelism (i.e., evaluation of n arguments could
be spun off as n processes without concern for the order in which they
might complete).
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> pointed out that although the
order is unspecified in Scheme the result is required to be consistent with
some sequential ordering.
In Scheme (R5RS) we read:
4.1.3. Procedure calls
[...]
Note: Although the order of evaluation is otherwise unspecified, the effect of
any concurrent evaluation of the operator and operand expressions is
constrained to be consistent with some sequential order of evaluation. The
order of evaluation may be chosen differently for each procedure call.
Alas, the requirement for consistency with some sequential ordering defeats
straightforward support for parallelism.
Aside: C/C++ is like Scheme, the order of argument evaluation is unspecified.
Given the emergence of multi-core processors, I think there's an argument for
an even more relaxed take on the issue of order of argument evaluation. Given
that the order of evaluation is unspecified, what is the rationale for
requiring the ordering to be consistent with some sequential ordering?
Bob Woodham wrote:
> On 2008-01-30, Rainer Joswig <······@lisp.de> wrote:
>> In article <·································@notam02.uio.no>,
>> "Kjetil S. Matheussen" <··············@notam02.no> wrote:
>>
>>> (removed comp.lang.scheme, only relevant to comp.lang.lisp)
>>>
>>> On Wed, 30 Jan 2008, Blake McBride wrote:
>>>
>>>> I would further add that Scheme should define argument evaluation order.
>>>> Compilers can be written to support a particular order just as well as
>>>> another order. This is no argument for unspecified argument evaluations
>>>> order. Having the argument evaluation order unspecified is a huge and
>>>> totally unnecessary opportunity for porting bugs.
>>>>
>>> Scheme is not haskell, so I agree about that.
>>> BTW, does common lisp specify the order of arguments?
>> Yes: evaluation of arguments is left to right in Common Lisp.
>
> There was a previous discussion of the issue of argument evaluation order in
> this newsgroup, March, 2005. In that discussion, two arguments in support of
> unspecified argument evaluation order were identified:
>
> 1. Potential for optimization given a compiler that could/would re-arrange the
> order of argument evaluation (at compile time);
>
> 2. (Run-time) support for parallelism (i.e., evaluation of n arguments could
> be spun off as n processes without concern for the order in which they
> might complete).
If you wanted parallelism you can't just kick off parallel threads at
somewhat arbitrary points (like argument evaluation points). Threads
must be a little more explicit than that in general.
>
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> pointed out that although the
> order is unspecified in Scheme the result is required to be consistent with
> some sequential ordering.
>
> In Scheme (R5RS) we read:
>
> 4.1.3. Procedure calls
> [...]
> Note: Although the order of evaluation is otherwise unspecified, the effect of
> any concurrent evaluation of the operator and operand expressions is
> constrained to be consistent with some sequential order of evaluation. The
> order of evaluation may be chosen differently for each procedure call.
>
> Alas, the requirement for consistency with some sequential ordering defeats
> straightforward support for parallelism.
>
> Aside: C/C++ is like Scheme, the order of argument evaluation is unspecified.
>
> Given the emergence of multi-core processors, I think there's an argument for
> an even more relaxed take on the issue of order of argument evaluation. Given
> that the order of evaluation is unspecified, what is the rationale for
> requiring the ordering to be consistent with some sequential ordering?
My complaint here is that the Scheme macro system is so complicated
and difficult to use that most of the power of lisp macros is lost. I
also contend that it has important limitations.
Scheme's macro system is theoretically pure in some sense related to
capturing of variables. But for that advantage you end up with:
1. While the Scheme macro system is simple and easy to use for simple
macros it quickly becomes inordinately complicated for more complex
macros. I believe that a very large percentage of Common Lisp
programmers are able to create and understand moderately complex macros
with a lot of ease. On the other hand I think the number of people in the
world who understand complex macros in Scheme are extremely rare. Fully
understanding Scheme's macro facility basically requires a Phd.
You can pick up virtually any language, learn a "Hello World" program
and then pick up various pieces as you begin to understand the
language incrementally. Each particular piece typically takes a
couple of minutes to understand. Because of their abstraction, macros
might take a bit longer. You could probably get a pretty good working
knowledge of lisp macros in a day. Scheme macros, on the other hand,
in all except the simplest cases, are unbelievably complex. I doubt
you could get a good handle on it in less than a week. Scheme macros
are too complex.
If you doubt my "complexity" arguments try taking a look at the
portable Scheme macro system available on the net. I haven't seen
much that was more complicated that that in my life.
2. I understand why you don't want variable capture - usually.
Sometimes you do. Until R6 Scheme had no standard who of capturing
variables. It seems like they've added this capability in R6. One
problem is that it is unbelievably complicated to use. You really have
to understand what is going on under the covers. Common Lisp makes
this sort of thing easy and straight forward.
3. I am under the impression that there are levels of complexity in
macros that the Scheme macro system flat out can't handle - at least
not in a portable way. In my own experience trying to use the Scheme
macro system I often and quickly hit a wall in which the complexity of
the solution exceeds my understanding. In nearly every case I asked
an expert and I almost always get one of two answers. They either
tell me to use some implementation specific facility or they tell me
it can't be done with it. I've never experienced this with Common
Lisp macros.
4. Understand that Lisp macros suffer from variable capture. It's
amazing how we've lived with this for 30+ years now. Having to deal
with variable capture is a small price to pay for the power, ease of
use, and flexibility of Common Lisp macros.
The bottom line is that the Scheme macro system is more of an
experiment in complexity than a useful too.
Blake McBride
Blake McBride wrote:
>
> The bottom line is that the Scheme macro system is more of an
> experiment in complexity than a useful too.
>
That should be "useful tool"
Two issues here.
The first is Scheme's lack of an object oriented system (OO). In
today's world OO programming is as fundamental to programming as
"while" loops are instead of goto statements. OO concepts are
probably the biggest and most important addition to computer languages
since structured programming (multithreading is next!!). Not having a
standard OO facility renders Scheme somewhat archaic.
And, if/when one is added it has got to be powerful - like CLOS. It
has got to have multiple inheritance. It has got to have a full MOP.
I started to write a CLOS like OO system in very portable Scheme. I
am about 80% done but haven't worked on it in a long time. I get
discouraged about adding a good and portable OO system to Scheme
because of Scheme's many other issues.
The second issue has to do with a standard module system. I know R6
has defines a library system. This is fine. The problem is that
virtually none of the Scheme implementations has implemented it and
virtually all of the Scheme implementors has publicly stated that
they will not support R6RS! Where exactly does that leave us?
Blake McBride
From: Abdulaziz Ghuloum
Subject: Re: Announcing a new release of Lisp1 #4
Date:
Message-ID: <fnm8ac$266$1@aioe.org>
Blake McBride wrote:
> And, if/when one is added it has got to be powerful - like CLOS. It
> has got to have multiple inheritance. It has got to have a full MOP.
I'm not familiar with the various CLOS systems out there. Does
TinyCLOS suffice? It was already ported to R6RS in
http://code.launchpad.net/r6rs-clos
> The second issue has to do with a standard module system. I know R6
> has defines a library system. This is fine. The problem is that
> virtually none of the Scheme implementations has implemented it and
> virtually all of the Scheme implementors has publicly stated that
> they will not support R6RS! Where exactly does that leave us?
It leaves us with two optimizing compilers that were made available
long time ago and four implementation in the making as we speak
(one of which happens to be very influential and has the most Scheme
users, and another happens to have industrial/commercial influence).
Additionally, we have two portable implementations of the library
system that any Scheme implementor can pick and use. (I personally
tested mine under 10 different R4RS/R5RS Scheme implementations)
How many of the other Scheme implementations that are not going to
support R6RS anytime soon do you care about?
Abdulaziz Ghuloum wrote:
> Blake McBride wrote:
>
>> And, if/when one is added it has got to be powerful - like CLOS. It
>> has got to have multiple inheritance. It has got to have a full MOP.
>
> I'm not familiar with the various CLOS systems out there. Does
> TinyCLOS suffice? It was already ported to R6RS in
> http://code.launchpad.net/r6rs-clos
It is my understanding that the original TinyCLOS is a proof of concept
and not really usable for the following reasons:
1. No method cache and other speed issues - slow dispatching - very slow
2. It retains pointers to object so they can never be GC'd
Numerous people have fixed some of these issues in TinyCLOS but each fix
was done in implementation specific ways. The bottom line is that there
is no portable, fast, practical implementation of TinyCLOS.
Does the TinyCLOS you refer me to fix these in a portable way?
>
>> The second issue has to do with a standard module system. I know R6
>> has defines a library system. This is fine. The problem is that
>> virtually none of the Scheme implementations has implemented it and
>> virtually all of the Scheme implementors has publicly stated that
>> they will not support R6RS! Where exactly does that leave us?
>
> It leaves us with two optimizing compilers that were made available
> long time ago
R6RS? I am unaware of these.
> and four implementation in the making as we speak
> (one of which happens to be very influential and has the most Scheme
> users, and another happens to have industrial/commercial influence).
Please name names!
> Additionally, we have two portable implementations of the library
> system that any Scheme implementor can pick and use. (I personally
> tested mine under 10 different R4RS/R5RS Scheme implementations)
I think I know of one. Please provide pointers.
>
> How many of the other Scheme implementations that are not going to
> support R6RS anytime soon do you care about?
Well, R6RS does fix the library issues as I stated. I don't believe the
object system issue is solved. That, of course, leaves us with the
remaining issues.
Blake McBride
From: Abdulaziz Ghuloum
Subject: Re: Announcing a new release of Lisp1 #4
Date:
Message-ID: <fo3jhv$ogh$1@aioe.org>
Blake McBride wrote:
> Does the TinyCLOS you refer me to fix these in a portable way?
As I said, I don't know much about CLOS. But from the description of
the project, it seems to be the case.
>> It leaves us with two optimizing compilers that were made available
>> long time ago
>
> R6RS? I am unaware of these.
Yes. Ikarus and Larceny.
>> and four implementation in the making as we speak
>> (one of which happens to be very influential and has the most Scheme
>> users, and another happens to have industrial/commercial influence).
>
> Please name names!
I thought this was common knowledge. Anyways, Chez Scheme, MzScheme,
and Scheme48 are hoped to be R6RS sometime within this year. There's
also IronScheme, which is already available in alpha stage.
>> Additionally, we have two portable implementations of the library
>> system that any Scheme implementor can pick and use. (I personally
>> tested mine under 10 different R4RS/R5RS Scheme implementations)
>
> I think I know of one. Please provide pointers.
http://www.cs.indiana.edu/~aghuloum/r6rs-libraries/
http://www.het.brown.edu/people/andre/macros/
Aziz,,,
Blake McBride <·····@mcbride.name> writes:
> Abdulaziz Ghuloum wrote:
>> Blake McBride wrote:
>>
>>> And, if/when one is added it has got to be powerful - like CLOS.
>>> It has got to have multiple inheritance. It has got to have a
>>> full MOP.
>>
>> I'm not familiar with the various CLOS systems out there. Does
>> TinyCLOS suffice? It was already ported to R6RS in
>> http://code.launchpad.net/r6rs-clos
>
> It is my understanding that the original TinyCLOS is a proof of
> concept and not really usable for the following reasons:
>
> 1. No method cache and other speed issues - slow dispatching - very
> slow
>
> 2. It retains pointers to object so they can never be GC'd
Both of these are easy to fix -- the first using hash tables, and the
second using either a weak hash table or applicable structs. All
serious implementations will have both of these, and writing the
necessary glue to make it portable should not be difficult.
(But yes, if by "portable" you mean "plain r5rs only", then things
become difficult.)
> Numerous people have fixed some of these issues in TinyCLOS but each
> fix was done in implementation specific ways. The bottom line is
> that there is no portable, fast, practical implementation of
> TinyCLOS.
>
> Does the TinyCLOS you refer me to fix these in a portable way?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Hi all,
Hi all,
I think Eli and Aziz defended the case quite well allready, but as the
author of the r6rs tiny-clos i think i should leave a comment or two
here too:
> > It is my understanding that the original TinyCLOS is a proof of
> > concept and not really usable for the following reasons:
>
> > 1. No method cache and other speed issues - slow dispatching - very
> > slow
> >
> > 2. It retains pointers to object so they can never be GC'd
>
> Both of these are easy to fix -- the first using hash tables,
currently for simple benchmarks (fib anyone? ;) I'm somewhere arround
10 times
slower than native application.
(swindle ~90, LispWorks claims to befaster than normal application
which i find highly confusing, haven't checked for others yet)
> and the
> second using either a weak hash table or applicable structs.
currently I only use a normal hash-table here, but it only retains
pointers
to generic functions, should be an easy fix if needed
(just to clarify: "normal" instances are not held in any way ...)
> All
> serious implementations will have both of these, and writing the
> necessary glue to make it portable should not be difficult.
>
> (But yes, if by "portable" you mean "plain r5rs only", then things
> become difficult.)
>
> > Numerous people have fixed some of these issues in TinyCLOS but each
> > fix was done in implementation specific ways. The bottom line is
> > that there is no portable, fast, practical implementation of
> > TinyCLOS.
>
> > Does the TinyCLOS you refer me to fix these in a portable way?
define portable, show me your portable (as in doesn't use
"implementation specific ways")
CL CLOS implementation and we can talk ;)
(bonus points if you show me a *fast* CL CLOS that doesn't use
"implementation specific ways")
On 29 Jan., 09:49, Pascal Costanza <····@p-cos.net> wrote:
> Abdulaziz Ghuloum wrote:
> > Blake McBride wrote:
> [ ... ]
>
> The only Scheme object system that comes somewhat close that I am aware
> of is STklos.
How does STKlos do speed wise? (also what about Gauche's clos, GOOPS?
I think these three are somehow
based on each other)
>
> [1] Yes, I am aware of Swindle. No, that's not the real deal.
>
Whats missing in Swindle then?
--
Greets
Christian
Slom wrote:
> Hi all,
>
> Hi all,
>
> I think Eli and Aziz defended the case quite well allready, but as the
> author of the r6rs tiny-clos i think i should leave a comment or two
> here too:
>
>>> It is my understanding that the original TinyCLOS is a proof of
>>> concept and not really usable for the following reasons:
>>> 1. No method cache and other speed issues - slow dispatching - very
>>> slow
>>>
>>> 2. It retains pointers to object so they can never be GC'd
>> Both of these are easy to fix -- the first using hash tables,
>
> currently for simple benchmarks (fib anyone? ;) I'm somewhere arround
> 10 times
> slower than native application.
>
> (swindle ~90, LispWorks claims to befaster than normal application
> which i find highly confusing, haven't checked for others yet)
(Huge) CLOS should generally be faster than the derivatives based on
Tiny CLOS you typically find in Scheme implementations. The reason is
that Tiny CLOS was mostly a pedagogical tool that leaves out important
aspects of typical CLOS implementations.
One important element in Tiny CLOS is that the body of a method is
capture in a 'method function', and method combination is achieved by
applying the method functions in the right order, possibly passing 'next
methods' as lists of method objects from which you need to fetch the
method functions and apply them in turn if necessary.
In CLOS, this is typically done differently: There, the actual code of
the method bodies are kept and method combination resembles more a macro
expansion process. Look at the specification of
define-method-combination: In user-defined method combinations, you
return lists (s-expressions) that specify how applicable methods are
combined, an in there, you can use 'call-method and 'make-method as
markers that tell CLOS where to expand or create method bodies. (The
specification states that 'call-method and 'make-method are macros, but
they are not, they are actually just markers.)
The way how method combination is specified in CLOS thus ensures that
you don't have the overhead of looking up and applying method functions
while methods are executed anymore.
Next is the fact that the discriminating functions are stored directly
in the generic function objects, which themselves can be directly
applied. Here you need an extra access step in Tiny CLOS as well. More
importantly, though, the CLOS MOP is specified in such a way that
discriminating functions can be (and typically are) very clever about
how they perform method dispatch: For example, if you have only one
method defined on a generic function, and that method is not specialized
in any of its arguments, the discriminating function _is_ then just that
method. If there is only one method defined, and it is specialized in
some arguments, the discriminating function performs a type check on
those arguments: If it succeeds, the one method is just called, and
other and error is signaled that no applicable methods have been found.
You can generalize from that approach: Depending on the number of
methods defined on a generic function, you can actually compile a
discrimination network and avoid having to put (effective) methods in
hashtables indexed on their specializers.
In general, this means that generic functions can be as fast (or
probably even faster) than manual dispatch using cond or typecase in
regular functions.
What's misssing, though, is that generic functions cannot be easily
inlined in call sites. There is also no really good scheme for
performing call site optimizations. (Jonathan Bachrach has done some
work on that for Dylan. The problem with CLOS is that the MOP
specification for generic function invocation does not really fit the
idea of call site optimizations very well, as far as I can tell. Common
Lisp and Scheme are lagging behind in that regard anyway, unfortunately.)
> On 29 Jan., 09:49, Pascal Costanza <····@p-cos.net> wrote:
>> Abdulaziz Ghuloum wrote:
>>> Blake McBride wrote:
>> [ ... ]
>>
>> The only Scheme object system that comes somewhat close that I am aware
>> of is STklos.
>
> How does STKlos do speed wise? (also what about Gauche's clos, GOOPS?
> I think these three are somehow
> based on each other)
>
>> [1] Yes, I am aware of Swindle. No, that's not the real deal.
>
> Whats missing in Swindle then?
See above.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Feb 13, 12:48 pm, Pascal Costanza <····@p-cos.net> wrote:
> Slom wrote:
> > Hi all,
>
> > Hi all,
>
> > I think Eli and Aziz defended the case quite well allready, but as the
> > author of the r6rs tiny-clos i think i should leave a comment or two
> > here too:
>
> >>> It is my understanding that the original TinyCLOS is a proof of
> >>> concept and not really usable for the following reasons:
> >>> 1. No method cache and other speed issues - slow dispatching - very
> >>> slow
>
> >>> 2. It retains pointers to object so they can never be GC'd
> >> Both of these are easy to fix -- the first using hash tables,
>
> > currently for simple benchmarks (fib anyone? ;) I'm somewhere arround
> > 10 times
> > slower than native application.
>
> > (swindle ~90, LispWorks claims to befaster than normal application
> > which i find highly confusing, haven't checked for others yet)
>
> (Huge) CLOS should generally be faster than the derivatives based on
> Tiny CLOS you typically find in Scheme implementations. The reason is
> that Tiny CLOS was mostly a pedagogical tool that leaves out important
> aspects of typical CLOS implementations.
>
> One important element in Tiny CLOS is that the body of a method is
> capture in a 'method function', and method combination is achieved by
> applying the method functions in the right order, possibly passing 'next
> methods' as lists of method objects from which you need to fetch the
> method functions and apply them in turn if necessary.
>
> In CLOS, this is typically done differently: There, the actual code of
> the method bodies are kept and method combination resembles more a macro
> expansion process. Look at the specification of
> define-method-combination: In user-defined method combinations, you
> return lists (s-expressions) that specify how applicable methods are
> combined, an in there, you can use 'call-method and 'make-method as
> markers that tell CLOS where to expand or create method bodies. (The
> specification states that 'call-method and 'make-method are macros, but
> they are not, they are actually just markers.)
>
> The way how method combination is specified in CLOS thus ensures that
> you don't have the overhead of looking up and applying method functions
> while methods are executed anymore.
>
> Next is the fact that the discriminating functions are stored directly
> in the generic function objects, which themselves can be directly
> applied. Here you need an extra access step in Tiny CLOS as well. More
> importantly, though, the CLOS MOP is specified in such a way that
> discriminating functions can be (and typically are) very clever about
> how they perform method dispatch: For example, if you have only one
> method defined on a generic function, and that method is not specialized
> in any of its arguments, the discriminating function _is_ then just that
> method. If there is only one method defined, and it is specialized in
> some arguments, the discriminating function performs a type check on
> those arguments: If it succeeds, the one method is just called, and
> other and error is signaled that no applicable methods have been found.
>
> You can generalize from that approach: Depending on the number of
> methods defined on a generic function, you can actually compile a
> discrimination network and avoid having to put (effective) methods in
> hashtables indexed on their specializers.
>
> In general, this means that generic functions can be as fast (or
> probably even faster) than manual dispatch using cond or typecase in
> regular functions.
>
> What's misssing, though, is that generic functions cannot be easily
> inlined in call sites. There is also no really good scheme for
> performing call site optimizations. (Jonathan Bachrach has done some
> work on that for Dylan. The problem with CLOS is that the MOP
> specification for generic function invocation does not really fit the
> idea of call site optimizations very well, as far as I can tell. Common
> Lisp and Scheme are lagging behind in that regard anyway, unfortunately.)
>
> > On 29 Jan., 09:49, Pascal Costanza <····@p-cos.net> wrote:
> >> Abdulaziz Ghuloum wrote:
> >>> Blake McBride wrote:
> >> [ ... ]
>
> >> The only Scheme object system that comes somewhat close that I am aware
> >> of is STklos.
>
> > How does STKlos do speed wise? (also what about Gauche's clos, GOOPS?
> > I think these three are somehow
> > based on each other)
>
> >> [1] Yes, I am aware of Swindle. No, that's not the real deal.
>
> > Whats missing in Swindle then?
>
> See above.
>
> Pascal
>
> --
> 1st European Lisp Symposium (ELS'08)http://prog.vub.ac.be/~pcostanza/els08/
>
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
Impressive....
Abdulaziz Ghuloum wrote:
> Blake McBride wrote:
>
>> And, if/when one is added it has got to be powerful - like CLOS. It
>> has got to have multiple inheritance. It has got to have a full MOP.
>
> I'm not familiar with the various CLOS systems out there. Does
> TinyCLOS suffice? It was already ported to R6RS in
> http://code.launchpad.net/r6rs-clos
No, TinyCLOS is not sufficient. None of the CLOS derivatives for Scheme
implementations comes close to 'proper' CLOS. CLOS is both the most
complete object system for any Lisp dialect, and at the same time has
the most efficient implementations available (which is far from trivial
given all its opportunities to tweak things).
The only Scheme object system that comes somewhat close that I am aware
of is STklos.
User-defined method combinations? Anyone? [1]
Pascal
[1] Yes, I am aware of Swindle. No, that's not the real deal.
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In conclusion, Scheme has, IMO, many important shortcomings. I
understand that I don't set the standards and these are just basically
my opinions. Although I believe these shortcomings are relatively
easy to fix, the real problem is the political element. No matter
what you think there is always someone out there who thinks the
opposite. The net result is that language development ends up
unnecessarily slow.
Common Lisp, again IMO, did a lot of the right things. The one big
technical error (IMO) was the LISPn thing. I know a bunch of you guys
want to jump on me about this with all kinds of technical BS trying to
rationalize your view. The truth of the matter is that the highest
and most respected experts on Common Lisp are utterly unclear about
the issue. So how does that make you an expert? You are more of a
fan club than a technical expert (again read the articles from the
authors of Common Lisp). The real truth is that the number one reason
Common Lisp is LISPn rather than LISP1 is historical and for purposes
of backward compatibility (all of which is hardly applicable anymore).
It isn't technically better. The experts were able to point out
trade-offs with either design. They even stated that LISP1 encouraged
more elegant programming style.
I would bet that the number one reason so many people use Scheme
instead of Common Lisp is the LISP1 reason. It is Scheme's biggest
appeal. (My guess is that Common Lisp is more popular than Scheme. I
am just trying to explain the large number of Scheme users.)
Just some opinions.
Blake McBride
From: Kent M Pitman
Subject: Re: Announcing a new release of Lisp1 #5
Date:
Message-ID: <utzkxxi2l.fsf@nhplace.com>
[ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html
Cross-posting a bunch of similarly-named threads seems especially extreme
and inappropriate, btw. ]
Blake McBride <·····@mcbride.name> writes:
> The real truth is that the number one reason Common Lisp is LISPn
> rather than LISP1 is historical and for purposes of backward
> compatibility (all of which is hardly applicable anymore).
The real truth? Where do you get your data? This phrasing seems to
me to be crying out to be called flamebait.
I imagine it was indeed a contributing factor. There were a number of
contributing factors. I don't think you'll find any documentation
that itemizes how the people voting made up their minds. I sat in the
committee meetings where this was decided and while I certainly
acknowledge that not breaking existing programs was on some people's
minds, I don't think you could by any means say that this was the
primary concern.
No natural (i.e., human) language takes the Lisp1 approach of having
only one meaning for a word that is the same in all situations.
Hence, if you're looking for data on what's natural to people, you're
going to have a hard time supporting the notion that the Lisp1 style is
so universally preferred that no one could consider it for reasons other
than compatibility.
If I were designing an all new language from scratch, I would probably
not even consider making it a Lisp1... Well, ok, I can think of one
reason why I might grudgingly sometimes consider it: for compatibility
with other systems that had made it that way; that is, for backward
compatibility. If you think backward compatibility is a bad thing,
though, maybe you're arguing I should ignore that as a possible
reason to even discuss it.
I find the the disdain that Lisp1 advocates for the idea that others'
way of doing things to be a serious negative. By contrast, I have
invested considerable personal energy in trying to work on the design
of language features for a possible future dialect that would bridge
this gap, allowing either style in the same language. My SPIEL
project at http://www.nhplace.com/kent/Half-Baked/ is an example ...
although I have since then done further exploratory work on this area
that is not yet published.
> I would bet that the number one reason so many people use Scheme
> instead of Common Lisp is the LISP1 reason.
I doubt this. It's more likely the fact that they took a course in
school that offered Scheme. Scheme uses this notation because it
mirrors certain mathy things that its creators and proponents have
traditionally wanted to teach. But at least as important, if not
more, to the course material Scheme classes tend to feature are
well-defined tail calling behavior, the availability of first class
continuations, its small size, and the availability of an articulated
formal semantics.
One reason Scheme has a hygienic macro system is that in a Lisp1 you
veritably have to. CL can get away without one because the combination
of Lisp2 and packages effectively gives you hygiene for free without a
complicated mechanism that many CL programmers have repeatedly said
they would not like.
> It is Scheme's biggest appeal.
Come now--this is selling Scheme seriously short.
While I personally don't prefer Scheme as my language of choice for
day to day work, I would say that it has a lot more of substance going
for it than just this.
Kent M Pitman wrote:
> [ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html
> Cross-posting a bunch of similarly-named threads seems especially extreme
> and inappropriate, btw. ]
>
> Blake McBride <·····@mcbride.name> writes:
>
>> The real truth is that the number one reason Common Lisp is LISPn
>> rather than LISP1 is historical and for purposes of backward
>> compatibility (all of which is hardly applicable anymore).
>
> The real truth? Where do you get your data? This phrasing seems to
> me to be crying out to be called flamebait.
>
> I imagine it was indeed a contributing factor. There were a number of
> contributing factors. I don't think you'll find any documentation
> that itemizes how the people voting made up their minds. I sat in the
> committee meetings where this was decided and while I certainly
> acknowledge that not breaking existing programs was on some people's
> minds, I don't think you could by any means say that this was the
> primary concern.
Quotes from "Technical Issues of Separation in Function Cells and Value
Cells" by Richard P. Gabriel and Kent Pitman:
"While functions, like Y, that directly manipulate other functions can
be written in either Lisp1 or Lisp2, many programmers feel that they can
be written more perspicuously in Lisp1; therefore, the more cumbersome
notation of Lisp2 does nothing to encourage and may even discourage the
writing of such functions."
"In Lisp1 it is easier to define a piece of code that shares
abstractions between data and functions. Again, this is possible in
Lisp2, but it is not an encouraged style. The problem is that it is a
burden to think about which namespace will be used for various variables."
"The bulk of arguments that focus on clean semantics and notational
simplicity tend to favor uniting the function and value namespaces."
"We feel that the time for such radical changes to Common Lisp passed,
and it would be the job of future Lisp designers to take lessons from
Common Lisp and Scheme to produce an improved Lisp."
Blake McBride
From: Kent M Pitman
Subject: Re: Announcing a new release of Lisp1 #5
Date:
Message-ID: <u4pcvn86g.fsf@nhplace.com>
[ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Blake McBride <·····@mcbride.name> writes:
> Quotes from "Technical Issues of Separation in Function Cells and
> Value Cells" by Richard P. Gabriel and Kent Pitman:
You should understand this paper as the written form of a debate. To
at least some extent, Gabriel tried not to remove my text and I tried
not to remove his. The result touches a lot of issues, but I've found
that most people who read it come out with the same kind of opinion as
people who watch a debate--they root for their own position and they
don't tend to hear that there is another side because they've entered
the game as much for the sport of it as for the enlightenment that it
offers to one about how others think.
I recommend a healthy dose of contemplation going into this paper, no
matter which side you agree with or disagree with. If you come out
reading only one side or believing there's only one point of view, you
probably haven't read hard enough. In that case, you can blame me,
and Gabriel too, I guess, for the fact that we made you read hard to
get things that should have been readily apparent... But don't
penalize the community we represent by assuming that there are no
people behind us. In this regard, it reminds me of Kerry or Gore, in
recent elections, when people said they should bow out of the election
before all the votes were counted--as if it were just about them.
Each of them was backed by a large population, and they were right to
stay in the race until the votes were counted because the election
wasn't about them, it was about whether a large constituency of people
supporting them were going to get their choice. Back to this paper,
it contains topics I've argued in certain ways. You may think the
arguments ineffective, but do not conclude from such a fact that there
are no effective arguments to be had. The community may just have had
a poor spokesman. :)
While the paper touches on the various issues, I do NOT think it does
a good job of summing up my positions. It takes liberties in assuming
there is only one conclusion, and I firmly disagree with that.
I don't think Gabriel was trying to be unfair. But I do think he
didn't believe some of the things I said I felt, and so found it
difficult to give some of them the weight that he perhaps should have
(at least according to me).
So, since I didn't get to sum it up as I'd wanted to have in the paper,
permit me to rebut the quoted text here, notwithstanding the fact that
I am technically (pardon pun) an author of the text I'm rebutting.
> "While functions, like Y, that directly manipulate other functions can
> be written in either Lisp1 or Lisp2, many programmers feel that they
> can be written more perspicuously in Lisp1; therefore, the more
> cumbersome notation of Lisp2 does nothing to encourage and may even
> discourage the writing of such functions."
The part of this that is not "spun" is probably strictly true, although
the truth offered is subjective and unsupported, so even my offering that
"admission" doesn't make it true in some absolute sense.
However, the "spin" part of this that is hard for a Lisp1 fanatic to see
because it goes right by them is "not everyone thinks that the functional
programming style here is desired", so they assume this is an "obvious
negative".
First, there were definitely people in the design of CL who ACTIVELY
WANTED it to be the case that a high degree of "functional
programming" would be discouraged. As such, they saw this paragraph as
conveying a benefit of the Lisp2 approach.
I'm not quite so far out on the political spectrum, but my position is
similar. Had I worded this paragraph (which is almost surely due to
Gabriel), I might have said something longer and more heavily qualified
(which Gabriel would have probably thought too unutterably tedious to
publish... he's not been a traditional fan of me running on [*]):
While functions, like Y, that directly manipulate other functions
can be written in either Lisp1 or Lisp2, the choice of linguistic
style implicitly assumes that a particular programming style is more
common. To a programmer who wants to pass a lot of functions as
arguments,
(define (f x y) (x y))
may seem the syntacticaly concise way to say that f simply implements
two-argument funcall. But to someone who does not regularly pass
functions, this might just be a syntax error. Perhaps what was meant
was actually
(define (f x y) (g x y))
and the g was omitted. To programmers who do not commonly pass
functional arguments, it is a favor, not a burden, to use funcall since
it confirms that a function call is intended. Hence the style
(defun f (x y) (funcall x y))
uses the extra word "funcall" to draw attention to the statistically
less common event of actually wanting to call x as a function, and
confirms the intent by visible redundancy. Whereas
(defun f (x y) (x y))
is usually recognizable by the compiler as a syntax error since in many
such cases, x is not a defined function name, and a compile-time error
message can be signaled. In the earlier case of
(define (f x y) (x y))
it is only possible to signal an error at runtime, and even then only if
x is non-functional.
> "In Lisp1 it is easier to define a piece of code that shares
> abstractions between data and functions. Again, this is possible in
> Lisp2, but it is not an encouraged style. The problem is that it is a
> burden to think about which namespace will be used for various
> variables."
To be honest, I don't even remember what this refers to, so I can't even
comment. It probably does refer to something specific, but I can't say.
> "The bulk of arguments that focus on clean semantics and notational
> simplicity tend to favor uniting the function and value namespaces."
IMO, this is bogus. I suppose I should annotate the webbed copy with
my opinion so I can stop repeating myself about this. I have the
feeling I've spoken on this before.
Note that it may have been a structural result of the fact that we
each spent two passes editing this document, with Gabriel having the
last pass, and I actually am not sure I had a chance to review the
final copy before it was finalized in its original form.
The first and most obvious point is: the word "clean" is not
scientific and is closer to flamebait. The most charitable reading of
that term is that it intended to refer to the "hygiene" abstraction.
CL lacks a so-called "hygienic macro system", but many who use CL
regard that as a feature. The very name "hygiene" is an exercise in
spin, because it appears to cast the alternative as unclean.
Second, the paper you read does not present all of the arguments. It
presents only the so-called technical arguments. The original paper
did not have the word "Technical" in it, and (as I recall) contained
additional commentary that Gabriel felt was inappropriate for
publication in LASC. (I'm nearly sure this paper should be regarded
as an abridgement, but I'd have to have the original paper at hand to
make sure. It's on my list to dig it out, but the paper is stored
elsewhere and I was thwarted by my recent cold from making an
expedition to its storage location to see if I could find it and
perhaps scan it. I'll try to do that again one of these days.)
(As to the question of whether non-technical arguments are valid at
all, especially in light of the remarks two paragraphs back where I
remarked that "clean" is an unscientific term: I don't mind people
using unscientific or emotional decision criteria in the language. I
could point to any number of good decisions made in CL that were not
based on anything other than emotional appeal. And, in fact, I
believe the main thing people who are Lisp1 people really like about
Lisp1 is also an emotional matter. I just object to citing
unscientific things with a scientific air. Passion and taste matter.
They just should not be offered as science in the sense of being
incontrovertible. They exist. They must be noted. They may not be
assumed to be compelling to all parties. I do not assert Lisp2 to be
compelling to all parties; I merely reserve the right to claim that
Lisp2 is compelling to me... for some technical and some emotional
reasons. Ironically, backward compatibility is a more
technical/scientific decision criterion than some of the other reasons
offered on either side.)
Third, "clean semantics" should not be assumed to mean anything like
"cannot be explained by a denotational semantics". There are things
in CL that peopel wouldn't like seeing in a denotational semantics. But
this particular decision is quite benign. That's why I created the
Lisp1/Lisp2 distinction--to emphasize that those other features are not
in play in this discussion.
The problem with this paragraph I'm commenting on is that it uses
various "scare words" that are specifically manufactured as spin by
the community of people who have an entire agenda to sell. This is a
little like saying "People who care about 'life' will prefer not to
engage in stem cell research." That's not a statement about "life" in
the dictionary sense (except where a dictionary has been hijacked and
has narrowly forced out any definition of life except the one that is
promoted by the so-called "pro-life" community); it's a statement that
is crafted to alert people reading who self-identify as pro-life that
this political option is consistent with their
self-identification. There are many people who care about "life" who
want stem cell research because it will prolong life, but there is
only one group that identifies its concerns using the word Life in a
way that suggests they have a unique and controlling use of it.
Likewise, "free software" seems to imply that anyone opposing it cares
not a bit about freedom, which is of course silly; the proponents of
free software may wish that use of the term "free" were not so free,
but it is, and it sometimes diverges from their chosen meaning. And,
back to the topic here, "clean semantics" and "notational simplicity"
are offered here to identify the community who thinks these things are
simple notions subject to a canonical definition. I don't think they
are. I use these terms myself in ways dissonant with what's offered
here... there are kinds of cleanliness that are supported equally well
in Lisp2. There are kinds of simplicity supported not just equally
well but better in Lisp2, not Lisp1. That's not to deny the fact that
there are aspects of simplicity and cleanliness that are present in
Lisp1. I just deny the unique/controlling/unambiguous nature of those
aspects. And so I reject these claims made in the paper by way of
summary.
> "We feel that the time for such radical changes to Common Lisp passed,
> and it would be the job of future Lisp designers to take lessons from
> Common Lisp and Scheme to produce an improved Lisp."
And here you see the essence of politics, warmed over in a technical
abridgement made out of context. It is not unusual to make a non-technical
statement like this in the context of a political debate in order to save
face for those who have lost. So they can say to themselves "I may have
lost today, but I can raise my objections another day." And so you may.
But don't expect me to say "I promised you I'd give it to you without
objection."
The first part of the sentence is true. The time had passed. That was the
killer argument, and so there was simply no need to debate the other issues.
It was an incompatible change outside the scope of CL's charter. End of story.
The rest of the sentence, "it would be the job..." does not say "and the
lessons are that there is no other choice in the future but to do otherwise".
It is carefully chosen to leave ambiguous what an improved Lisp is.
If you read my http://www.nhplace.com/kent/Half-Baked/ you'll see
there is a middle ground that addresses another point in the complex
space of choices. I usually call it Lisp Omega. But it is biased
toward neither Lisp1 nor Lisp2 and yet can accommodate both. I have a
much better implementation of parts of it unpublished, but I believe
it is quite doable. It troubles me a great deal that no one wants to
invest time in understanding one another, and that the focus is on
telling people "you are not entitled to your personal preference" and
on the use of logic to somehow "prove" that this is so. That's feeble
and cowardly. It does not confront the one unassailable truth in this
entire debate, which is that there exist people with differing
preferences. It instead attempts to define one camp as "confused and
therefore not worthy of study". Learning to overcome such
dehumanizing approaches to problem solving is critical in many areas,
not just Lisp. I daresay the US political system could use a healthy
dose of same just about now.
- - - -
[*] = In fairness, I learned a great deal from Gabriel about good writing
style in the process of producing ANSI CL. He's a good guy and we have
sparred both technically and personally over many things over the years,
but I've come to really like him, and to appreciate even the parts of his
personality that sometimes cause me angst. He was always trying to come
up with simplifying wording and more consistent word use, and it was very
beneficial. He got me to spell "signaling" the American way (one "l")
and taught me the difference between "which" and "that", among many other
things. On the more humorous end, he explained to me that, when writing
standards, "should do" is a synonym for "don't really have to do" in that
neither has any force of weight in terms of conformance. :)
But, like all things, there are times when simpler wording does not
capture things. So while his wording was simpler and crisper in this
paper, my meaning often got lost in the process. There are reasons
that sometimes things can run legitimately long. (As he himself
illustrated, I believe, since he claims he once turned in a paper for
a class in school that was all one sentence done in a syntactically
valid style, that is, not formally a run-on sentence, just to
illustrate that there was a difference between saying "you shouldn't
write run-on sentences" and "you shouldn't write long sentences.")
Kent M Pitman wrote:
> [ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
>
> Blake McBride <·····@mcbride.name> writes:
>
>> Quotes from "Technical Issues of Separation in Function Cells and
>> Value Cells" by Richard P. Gabriel and Kent Pitman:
>
> You should understand this paper as the written form of a debate. To
> at least some extent, Gabriel tried not to remove my text and I tried
> not to remove his. The result touches a lot of issues, but I've found
> that most people who read it come out with the same kind of opinion as
> people who watch a debate--they root for their own position and they
> don't tend to hear that there is another side because they've entered
> the game as much for the sport of it as for the enlightenment that it
> offers to one about how others think.
I think I should also be clear. I never intended this to become a
debate about Lisp1 vs. Lisp2 or Scheme vs. Common Lisp. I merely
created a facility in Common Lisp which reflected my own personal
programming preferences. As you can easily tell, I got drug into a
debate (perhaps caused be actually sharing a point of view or personal
preference).
Additionally, my quotes weren't meant to prove my view. The quotes were
meant to prove the validity of my view - the fact that it is a viable
view and that Lisp2 isn't clearly better.
Earlier, in a previous post, I referred to a "language fan club" or
something like that. I'd like to elaborate on this. It is common
practice for many people to get excited about a somewhat random group of
guys from all over the country who collect as a sports team associated
with a particular State. People will get all excited about the team for
reasons that are beyond me.
Likewise many (most) programmers I've met become "fan club" members of
various languages - usually because of their popularity. The only real
truth of the language is its popularity and not its technical merits.
Yet, being fan club members, programmers will first rationalize the
features of the language to themselves and than become die hard
supporters of the language without any real sense of clear thinking.
There are so many examples of this I hardly know where to begin. Take
lisp and s-expressions. For years I've loved and tried to push lisp in
work environments. My biggest obstacle has been the parenthesis. No
"truth of the matter" arguments I had had any weight. They didn't want
to hear it. I was from the dark ages interested in arcane languages and
syntaxes. Then along comes XML. The whole world fell in love with it.
It is the answer to everything. I've even seen languages that were
represented as XML! Many programmers are nuts over XML and think it is
the answer to virtually everything. When I point out that XML is
nothing more than a convoluted s-expression that I've been talking about
for years they can't see my point. When I see them trying to actually
make a programming language out of XML I point to lisp and they don't
see it. They are in the XML fan club.
Recently I went to a Microsoft (G-d help me) presentation on the latest
C#. They brought up a brand new concept in the latest C# spec. This
was a fantastic new feature of the language. They even asked if anyone
in the audience (a theater full of people) ever heard of the concept. I
was the only person to raise my hand. This great new feature is called
"lambda"!!! Of course the C# fan club doesn't want to hear about lisp.
I could go on. The point I am trying to make is that lets us not become
the "Common Lisp" fan club. Things aren't right just because "Common
Lisp" did it that way. Use your brain. Expand your thought process and
stop bashing people who bring up alternative views.
More comments below.
>
> I recommend a healthy dose of contemplation going into this paper, no
> matter which side you agree with or disagree with. If you come out
> reading only one side or believing there's only one point of view, you
> probably haven't read hard enough. In that case, you can blame me,
> and Gabriel too, I guess, for the fact that we made you read hard to
> get things that should have been readily apparent... But don't
> penalize the community we represent by assuming that there are no
> people behind us. In this regard, it reminds me of Kerry or Gore, in
> recent elections, when people said they should bow out of the election
> before all the votes were counted--as if it were just about them.
> Each of them was backed by a large population, and they were right to
> stay in the race until the votes were counted because the election
> wasn't about them, it was about whether a large constituency of people
> supporting them were going to get their choice. Back to this paper,
> it contains topics I've argued in certain ways. You may think the
> arguments ineffective, but do not conclude from such a fact that there
> are no effective arguments to be had. The community may just have had
> a poor spokesman. :)
>
> While the paper touches on the various issues, I do NOT think it does
> a good job of summing up my positions. It takes liberties in assuming
> there is only one conclusion, and I firmly disagree with that.
>
> I don't think Gabriel was trying to be unfair. But I do think he
> didn't believe some of the things I said I felt, and so found it
> difficult to give some of them the weight that he perhaps should have
> (at least according to me).
>
> So, since I didn't get to sum it up as I'd wanted to have in the paper,
> permit me to rebut the quoted text here, notwithstanding the fact that
> I am technically (pardon pun) an author of the text I'm rebutting.
>
>> "While functions, like Y, that directly manipulate other functions can
>> be written in either Lisp1 or Lisp2, many programmers feel that they
>> can be written more perspicuously in Lisp1; therefore, the more
>> cumbersome notation of Lisp2 does nothing to encourage and may even
>> discourage the writing of such functions."
>
> The part of this that is not "spun" is probably strictly true, although
> the truth offered is subjective and unsupported, so even my offering that
> "admission" doesn't make it true in some absolute sense.
>
> However, the "spin" part of this that is hard for a Lisp1 fanatic to see
> because it goes right by them is "not everyone thinks that the functional
> programming style here is desired", so they assume this is an "obvious
> negative".
>
> First, there were definitely people in the design of CL who ACTIVELY
> WANTED it to be the case that a high degree of "functional
> programming" would be discouraged. As such, they saw this paragraph as
> conveying a benefit of the Lisp2 approach.
>
> I'm not quite so far out on the political spectrum, but my position is
> similar. Had I worded this paragraph (which is almost surely due to
> Gabriel), I might have said something longer and more heavily qualified
> (which Gabriel would have probably thought too unutterably tedious to
> publish... he's not been a traditional fan of me running on [*]):
>
> While functions, like Y, that directly manipulate other functions
> can be written in either Lisp1 or Lisp2, the choice of linguistic
> style implicitly assumes that a particular programming style is more
> common. To a programmer who wants to pass a lot of functions as
> arguments,
> (define (f x y) (x y))
> may seem the syntacticaly concise way to say that f simply implements
> two-argument funcall. But to someone who does not regularly pass
> functions, this might just be a syntax error. Perhaps what was meant
> was actually
> (define (f x y) (g x y))
> and the g was omitted. To programmers who do not commonly pass
> functional arguments, it is a favor, not a burden, to use funcall since
> it confirms that a function call is intended. Hence the style
> (defun f (x y) (funcall x y))
> uses the extra word "funcall" to draw attention to the statistically
> less common event of actually wanting to call x as a function, and
> confirms the intent by visible redundancy. Whereas
> (defun f (x y) (x y))
> is usually recognizable by the compiler as a syntax error since in many
> such cases, x is not a defined function name, and a compile-time error
> message can be signaled. In the earlier case of
> (define (f x y) (x y))
> it is only possible to signal an error at runtime, and even then only if
> x is non-functional.
You know, I think you are flat out wrong here (with all due respect,
Kent). Programs have two elements as follows:
1. Programs are designed to be expressions of a solution to a problem.
2. Programs have elements to make your intent clear to both programmers
and compilers.
All Turing complete languages can do item 1. One principal
differentiation between languages is the amount of item 2 that they
require. Every language has an element of item 2 but language vary a
lot to the degree. ADA, for example, has probably the strongest element
of item 2. In fact, in ADA there is so much of item 2 that you'd be
hard pressed to tell what the item 1 (problem solution) elements are.
The solution to the problem is lost in the declarations. Other
languages such as Java, C# have much less declarative elements but more
than others such as C. On the extreme opposite side of all of this is
Lisp. Lisp has an absolute minimum of language declarations so that
virtually all of a Lisp program represents the solution to the problem.
Your argument in favor of funcall and function is largely that it is
more clear - more item 2 - more language declarations - and less direct
solution to the problem. This is not Lisp style! If you think funcall
makes it more clear than wouldn't declaring data types make a program
even more clear? In the end you end up with ADA. Again, this is not Lisp.
>
>> "In Lisp1 it is easier to define a piece of code that shares
>> abstractions between data and functions. Again, this is possible in
>> Lisp2, but it is not an encouraged style. The problem is that it is a
>> burden to think about which namespace will be used for various
>> variables."
>
> To be honest, I don't even remember what this refers to, so I can't even
> comment. It probably does refer to something specific, but I can't say.
See my prior point. That is what it is talking about.
>
>> "The bulk of arguments that focus on clean semantics and notational
>> simplicity tend to favor uniting the function and value namespaces."
>
> IMO, this is bogus. I suppose I should annotate the webbed copy with
> my opinion so I can stop repeating myself about this. I have the
> feeling I've spoken on this before.
>
> Note that it may have been a structural result of the fact that we
> each spent two passes editing this document, with Gabriel having the
> last pass, and I actually am not sure I had a chance to review the
> final copy before it was finalized in its original form.
>
> The first and most obvious point is: the word "clean" is not
> scientific and is closer to flamebait. The most charitable reading of
> that term is that it intended to refer to the "hygiene" abstraction.
> CL lacks a so-called "hygienic macro system", but many who use CL
> regard that as a feature. The very name "hygiene" is an exercise in
> spin, because it appears to cast the alternative as unclean.
>
> Second, the paper you read does not present all of the arguments. It
> presents only the so-called technical arguments. The original paper
> did not have the word "Technical" in it, and (as I recall) contained
> additional commentary that Gabriel felt was inappropriate for
> publication in LASC. (I'm nearly sure this paper should be regarded
> as an abridgement, but I'd have to have the original paper at hand to
> make sure. It's on my list to dig it out, but the paper is stored
> elsewhere and I was thwarted by my recent cold from making an
> expedition to its storage location to see if I could find it and
> perhaps scan it. I'll try to do that again one of these days.)
>
> (As to the question of whether non-technical arguments are valid at
> all, especially in light of the remarks two paragraphs back where I
> remarked that "clean" is an unscientific term: I don't mind people
> using unscientific or emotional decision criteria in the language. I
> could point to any number of good decisions made in CL that were not
> based on anything other than emotional appeal. And, in fact, I
> believe the main thing people who are Lisp1 people really like about
> Lisp1 is also an emotional matter.
No, it's based on my previous paragraph and reflected by Gabriel's comments.
I just object to citing
> unscientific things with a scientific air. Passion and taste matter.
> They just should not be offered as science in the sense of being
> incontrovertible. They exist. They must be noted. They may not be
> assumed to be compelling to all parties. I do not assert Lisp2 to be
> compelling to all parties; I merely reserve the right to claim that
> Lisp2 is compelling to me... for some technical and some emotional
> reasons. Ironically, backward compatibility is a more
> technical/scientific decision criterion than some of the other reasons
> offered on either side.)
>
> Third, "clean semantics" should not be assumed to mean anything like
> "cannot be explained by a denotational semantics". There are things
> in CL that peopel wouldn't like seeing in a denotational semantics. But
> this particular decision is quite benign. That's why I created the
> Lisp1/Lisp2 distinction--to emphasize that those other features are not
> in play in this discussion.
>
> The problem with this paragraph I'm commenting on is that it uses
> various "scare words" that are specifically manufactured as spin by
> the community of people who have an entire agenda to sell.
I would say the Common Lisp fan club and the MacLisp fan clubs have more
of an agenda and that the Lisp1 crowd are trying to make a dispassionate
argument. Remember the Europeans and other Lisp1 advocates didn't have
a fan club (leading to "an agenda"). The MacLisp guys certainly did
have a fan club and an agenda.
More comments below.
This is a
> little like saying "People who care about 'life' will prefer not to
> engage in stem cell research." That's not a statement about "life" in
> the dictionary sense (except where a dictionary has been hijacked and
> has narrowly forced out any definition of life except the one that is
> promoted by the so-called "pro-life" community); it's a statement that
> is crafted to alert people reading who self-identify as pro-life that
> this political option is consistent with their
> self-identification. There are many people who care about "life" who
> want stem cell research because it will prolong life, but there is
> only one group that identifies its concerns using the word Life in a
> way that suggests they have a unique and controlling use of it.
> Likewise, "free software" seems to imply that anyone opposing it cares
> not a bit about freedom, which is of course silly; the proponents of
> free software may wish that use of the term "free" were not so free,
> but it is, and it sometimes diverges from their chosen meaning. And,
> back to the topic here, "clean semantics" and "notational simplicity"
> are offered here to identify the community who thinks these things are
> simple notions subject to a canonical definition. I don't think they
> are. I use these terms myself in ways dissonant with what's offered
> here... there are kinds of cleanliness that are supported equally well
> in Lisp2. There are kinds of simplicity supported not just equally
> well but better in Lisp2, not Lisp1. That's not to deny the fact that
> there are aspects of simplicity and cleanliness that are present in
> Lisp1. I just deny the unique/controlling/unambiguous nature of those
> aspects. And so I reject these claims made in the paper by way of
> summary.
>
>> "We feel that the time for such radical changes to Common Lisp passed,
>> and it would be the job of future Lisp designers to take lessons from
>> Common Lisp and Scheme to produce an improved Lisp."
>
> And here you see the essence of politics, warmed over in a technical
> abridgement made out of context. It is not unusual to make a non-technical
> statement like this in the context of a political debate in order to save
> face for those who have lost. So they can say to themselves "I may have
> lost today, but I can raise my objections another day." And so you may.
> But don't expect me to say "I promised you I'd give it to you without
> objection."
We all know there was a MacLisp steam roller. It is clear in all the
text. That statement sounds to me like "Lisp1 might very well be the
better path but we've gone too far with Lisp2 to turn around now and
lose the momentum we have."
Another comment below.
>
> The first part of the sentence is true. The time had passed. That was the
> killer argument, and so there was simply no need to debate the other issues.
> It was an incompatible change outside the scope of CL's charter. End of story.
>
> The rest of the sentence, "it would be the job..." does not say "and the
> lessons are that there is no other choice in the future but to do otherwise".
> It is carefully chosen to leave ambiguous what an improved Lisp is.
>
> If you read my http://www.nhplace.com/kent/Half-Baked/ you'll see
> there is a middle ground that addresses another point in the complex
> space of choices. I usually call it Lisp Omega. But it is biased
> toward neither Lisp1 nor Lisp2 and yet can accommodate both. I have a
> much better implementation of parts of it unpublished, but I believe
> it is quite doable. It troubles me a great deal that no one wants to
> invest time in understanding one another, and that the focus is on
> telling people "you are not entitled to your personal preference" and
> on the use of logic to somehow "prove" that this is so. That's feeble
> and cowardly. It does not confront the one unassailable truth in this
> entire debate, which is that there exist people with differing
> preferences. It instead attempts to define one camp as "confused and
> therefore not worthy of study". Learning to overcome such
> dehumanizing approaches to problem solving is critical in many areas,
> not just Lisp. I daresay the US political system could use a healthy
> dose of same just about now.
>
> - - - -
>
> [*] = In fairness, I learned a great deal from Gabriel about good writing
> style in the process of producing ANSI CL. He's a good guy and we have
> sparred both technically and personally over many things over the years,
> but I've come to really like him, and to appreciate even the parts of his
> personality that sometimes cause me angst. He was always trying to come
> up with simplifying wording and more consistent word use, and it was very
> beneficial. He got me to spell "signaling" the American way (one "l")
> and taught me the difference between "which" and "that",
Oh, please, please help me with that! I'm not kidding. I am writing a
book on philosophy and some people have commented on my use of "which"
and "that". I have talked to several people and I can't figure out the
difference. Someone, please help me!
> among many other
> things. On the more humorous end, he explained to me that, when writing
> standards, "should do" is a synonym for "don't really have to do" in that
> neither has any force of weight in terms of conformance. :)
>
> But, like all things, there are times when simpler wording does not
> capture things. So while his wording was simpler and crisper in this
> paper, my meaning often got lost in the process. There are reasons
> that sometimes things can run legitimately long. (As he himself
> illustrated, I believe, since he claims he once turned in a paper for
> a class in school that was all one sentence done in a syntactically
> valid style, that is, not formally a run-on sentence, just to
> illustrate that there was a difference between saying "you shouldn't
> write run-on sentences" and "you shouldn't write long sentences.")
I enjoyed reading your messages, in particular i think it showed a
clarity of thinking.
Btw, the difference between “which” and “that” in places they are
interchangable, in a nutshell, is that when you use “which”, put a
comman in front. That's about it. e.g.
• i think she's lovely that you can't deny.
• i think she's lovely, which you can't deny.
(as a consequence, “which” tends to emphasize the qualification, and
is useful when a sentence is already long sans a break)
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
Xah Lee wrote:
> I enjoyed reading your messages, in particular i think it showed a
> clarity of thinking.
>
> Btw, the difference between “which” and “that” in places they are
> interchangable, in a nutshell, is that when you use “which”, put a
> comman in front. That's about it. e.g.
>
> • i think she's lovely that you can't deny.
>
> • i think she's lovely, which you can't deny.
>
> (as a consequence, “which” tends to emphasize the qualification, and
> is useful when a sentence is already long sans a break)
>
How about a sentence that isn't a grouping of two ideas like the following.
• It hurts in the part of the body that feels pain.
• It hurts in a part of the body which feels pain.
Thanks for the help, and thanks for the book pointer. I just ordered it.
Blake McBride
Xah Lee wrote:
«Btw, the difference between “which” and “that” in places they are
interchangable, in a nutshell, is that when you use “which”, put a
comman in front. That's about it.»
Blake McBride wrote:
> How about a sentence that isn't a grouping of two ideas like the following.
>
> • It hurts in the part of the body that feels pain.
>
> • It hurts in a part of the body which feels pain.
Same. When using “which”, you just need to put a comma in front, and
that is about the only technical difference. (there are exceptions but
that's more to do with creative writing or stylistic writing)
----------------------------
In your particular contructed exmaple, there are ambiguities that lies
outside the choices between “that” and “which”. In particluar, that
example's semantic structure is this:
• X that is Y.
And the X here (“It hurts in a part of the body”) is subject to
completion. So, reader cannot tell whether the Y qualifies X, or Y
completes X. Further, the “hurt” and “pain” are synonyms, which
doesn't help to resolve the issue where normally it would.
More concretely, the 2 interpretations are:
• It hurts a part of the body, and this hurting feels pain.
• It hurts, at a location L, and L is the part of the body feels pain.
Syntactical ambiguities like this are abound and inherent in English
and just about every natural language. It isn't a practical problem
because often the context resolves the issue (or by questioning or
body lang), however, it also results in many things that is
practically impossible to express with the language. (this one of the
reasons, math notations and programing are unlike natural lang)
The artificial language lojban, based on predicate logic, is meant to
address this. See
• http://xahlee.org/lojban/lojban.html
• http://en.wikipedia.org/wiki/Lojban
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
From: vanekl
Subject: Re: Announcing a new release of Lisp1 #5
Date:
Message-ID: <fnq5bn$sfb$1@aioe.org>
Blake McBride wrote:
> Kent M Pitman wrote:
...
>> beneficial. He got me to spell "signaling" the American way (one
>> "l") and taught me the difference between "which" and "that",
>
> Oh, please, please help me with that! I'm not kidding. I am writing a
> book on philosophy and some people have commented on my use of "which"
> and "that". I have talked to several people and I can't figure out the
> difference. Someone, please help me!
http://en.wikipedia.org/wiki/The_Elements_of_Style
http://www.bartleby.com/141/
It's less than 100 pages. One of the most useful books I've ever
read in my life. It will show you how to go on a "which" hunt.
Disclaimer: this book is not recommended for those in government
or upper-management.
Lou
Kent M Pitman wrote:
> The first and most obvious point is: the word "clean" is not
> scientific and is closer to flamebait. The most charitable reading of
> that term is that it intended to refer to the "hygiene" abstraction.
> CL lacks a so-called "hygienic macro system", but many who use CL
> regard that as a feature. The very name "hygiene" is an exercise in
> spin, because it appears to cast the alternative as unclean.
Yes yes yes yes yes! Clean. Easier to understand. Easier to read.
More natural. These terms really mean "I like this and, therefore, so
should you." Any truth which we bother to declare as self evident must
obviously not be self evident or why would one bother declaring it in
the first place? It seems that the typical second step after having
declared something as being self evident is to start a war in order to
force that self evidence done the throat of someone who happens to not
agree with the "obvious". There are probably very few opinions in this
world about which there has never been any disagreement: without water,
food, and air, people die. I think everything else is trial by combat
(or ballot).
> If you read my http://www.nhplace.com/kent/Half-Baked/ you'll see
> there is a middle ground that addresses another point in the complex
> space of choices. I usually call it Lisp Omega. But it is biased
> toward neither Lisp1 nor Lisp2 and yet can accommodate both.
That sounds interesting. I'll have to try and make time to read that
sometime. But lacking such a flexible solution, I personally find the
following macro, which was posted here in c.l.l, to be a handy
approximation of Lisp1.
;; I got this from <http://tinyurl.com/yknams>.
(defmacro with-fns (bindings &body body)
"Bind each variable in BINDINGS as a function, so you can use Lisp-1
notation - e.g. (with-fns (fn) (fn 3)) is the same as (funcall fn 3).
Each binding is either the name of the function or an (ALIAS
ORIG-NAME) list."
(labels ((pairify (binding)
(if (consp binding) binding (list binding binding))))
` (labels ,(loop for (name fn) in (mapcar #'pairify bindings)
collect `(,name (&rest args)
(apply ,fn args)))
,@body)))
Den Tue, 29 Jan 2008 19:54:01 -0600 skrev Blake McBride:
> Kent M Pitman wrote:
>> Blake McBride <·····@mcbride.name> writes:
>>
>>> The real truth is that the number one reason Common Lisp is LISPn
>>> rather than LISP1 is historical and for purposes of backward
>>> compatibility (all of which is hardly applicable anymore).
>>
>> The real truth? Where do you get your data? This phrasing seems to me
>> to be crying out to be called flamebait.
>>
>> I imagine it was indeed a contributing factor. There were a number of
>> contributing factors. I don't think you'll find any documentation that
>> itemizes how the people voting made up their minds. I sat in the
>> committee meetings where this was decided and while I certainly
>> acknowledge that not breaking existing programs was on some people's
>> minds, I don't think you could by any means say that this was the
>> primary concern.
>
> Quotes from "Technical Issues of Separation in Function Cells and Value
> Cells" by Richard P. Gabriel and Kent Pitman:
>
[snip quotes]
You'd do well by reading a recent discussion in which Kent extensively
explains the history and background behind that paper, including the
perceived "outcome" of it, before handing him quotes from a paper he
wrote himself.
Cheers,
Maciej
In article <···············@news.supernews.com>,
Blake McBride <·····@mcbride.name> wrote:
> In conclusion, Scheme has, IMO, many important shortcomings. I
> understand that I don't set the standards and these are just basically
> my opinions. Although I believe these shortcomings are relatively
> easy to fix, the real problem is the political element. No matter
> what you think there is always someone out there who thinks the
> opposite. The net result is that language development ends up
> unnecessarily slow.
>
> Common Lisp, again IMO, did a lot of the right things. The one big
> technical error (IMO) was the LISPn thing. I know a bunch of you guys
> want to jump on me about this with all kinds of technical BS trying to
> rationalize your view. The truth of the matter is that the highest
> and most respected experts on Common Lisp are utterly unclear about
> the issue. So how does that make you an expert? You are more of a
> fan club than a technical expert (again read the articles from the
> authors of Common Lisp). The real truth is that the number one reason
> Common Lisp is LISPn rather than LISP1 is historical and for purposes
> of backward compatibility (all of which is hardly applicable anymore).
> It isn't technically better. The experts were able to point out
> trade-offs with either design. They even stated that LISP1 encouraged
> more elegant programming style.
Funny, I thought it was exactly the other way: you are
rationalizing your own experience. Anyone claiming to know the 'real
truth' just makes me laugh.
> I would bet that the number one reason so many people use Scheme
> instead of Common Lisp is the LISP1 reason. It is Scheme's biggest
> appeal. (My guess is that Common Lisp is more popular than Scheme. I
> am just trying to explain the large number of Scheme users.)
I'd think it is because Scheme is used as a educational language
and thus the first contact with Lisp for many students. Second
I think is that Scheme (< R6RS) has a somehow elegant / reduced
design, which attracts people.
To your other points (from several postings):
* as a design principle I would reduce the number of uses
of 'unspecified' in a language definition to zero
* (set! foo (set! bar baz))
That's bad programming style and should be discouraged.
Scheme should have defined that nothing (no value) is returned.
Common Lisp has another preference. Still programmers
should not use this, if possible.
* Boolean values
I would prefer to have only two boolean values #t and #f.
Other values should not be treated as #t (unlike
'in most places' in Scheme).
I don't like the Common Lisp way especially. I can
live with it, though.
* Macro system.
I don't like the macro system in R5RS. I find it difficult
to use and not very 'powerful'.
Maybe it's because I'm not used to it. I tried to
use it, but without much success.
* Object-System. Something like Dylan's simplified
CLOS would be fine for Scheme. A MOP should be optional.
Additionally implementors should have the chance to provide
efficient versions. Should have been provided for
R6RS instead of 'records'.
* Module System. Can't say much about that.
>
> Just some opinions.
>
> Blake McBride
Den Tue, 29 Jan 2008 09:39:20 +0100 skrev Rainer Joswig:
> To your other points (from several postings):
>
> * as a design principle I would reduce the number of uses
> of 'unspecified' in a language definition to zero
Sometimes the design needs to specify unspecified, though. It might be
because the correct choice depends on a number of other choices, or
because choosing the "correct" one is hard/impossible and any value would
be really incidental, or to leave some implementation choices open that
would otherwise be excluded whilst being otherwise perfectly sound.
Though of course it's valuable on its own to reduce the number of
unspecified cases as much as possible.
> * Boolean values
> I would prefer to have only two boolean values #t and #f. Other values
> should not be treated as #t (unlike
> 'in most places' in Scheme).
> I don't like the Common Lisp way especially. I can live with it,
> though.
Ugh. That would be horribly ugly and make any kind of boolean logic
unbearable. Generalised booleans are there for a reason, and one of them
is, in fact, clarity and elegance (the shortness of expression has been
given previously as the metric of elegance here, and while not at all
sufficient, it's an important factor for many kinds of elegance).
That is to say, I don't claim that using generalised booleans is
objectively always more elegant and anyone who thinks otherwise is
stupid, but if a language went all the way to disallow them completely,
I'd consider it a huge disservice to me as a user and an important reason
to look elsewhere.
Cheers,
Maciej
Rainer Joswig wrote:
> Funny, I thought it was exactly the other way: you are
> rationalizing your own experience. Anyone claiming to know the 'real
> truth' just makes me laugh.
>
> To your other points (from several postings):
>
> [...]
> * (set! foo (set! bar baz))
> That's bad programming style and should be discouraged.
> Scheme should have defined that nothing (no value) is returned.
> Common Lisp has another preference. Still programmers
> should not use this, if possible.
Hello. Pot? This is Kettle. You are so black.
Blake McBride wrote:
>
> In conclusion, Scheme has, IMO, many important shortcomings. I
> understand that I don't set the standards and these are just basically
> my opinions. Although I believe these shortcomings are relatively
> easy to fix, the real problem is the political element. No matter
> what you think there is always someone out there who thinks the
> opposite. The net result is that language development ends up
> unnecessarily slow.
>
> Common Lisp, again IMO, did a lot of the right things. The one big
> technical error (IMO) was the LISPn thing. I know a bunch of you guys
> want to jump on me about this with all kinds of technical BS trying to
> rationalize your view. The truth of the matter is that the highest
> and most respected experts on Common Lisp are utterly unclear about
> the issue. So how does that make you an expert? You are more of a
> fan club than a technical expert (again read the articles from the
> authors of Common Lisp). The real truth is that the number one reason
> Common Lisp is LISPn rather than LISP1 is historical and for purposes
> of backward compatibility (all of which is hardly applicable anymore).
> It isn't technically better. The experts were able to point out
> trade-offs with either design. They even stated that LISP1 encouraged
> more elegant programming style.
An excellent series of postings, you hit the nails on their heads. ;)
Except for the Lisp-1 vs. Lisp-2 issue. ;)
You say that Scheme macro systems are too complicated. However, there is
an important technical aspect there related to the Lisp-1 vs. Lisp-n
issue: If you go for a Common Lisp-style macro system, a Lisp-1 makes
macro programming more unreliable than a Lisp-n. Since a Lisp-1 squeezes
all names into a single namespace, the likeliness for having accidental
nameclashes is much higher. Lisp-n simply provides more 'air to
breathe', so to speak.
That's why I personally prefer Lisp-n over Lisp-1. In fact, I often have
accidental nameclashes in Scheme completely independent of whether I
define macros or not. In Common Lisp, this almost never happens to me,
including in macros.
There is also an aesthetic point: The car position in a form _is_
treated differently than the cdr positions, in all Lisp dialects. The
car position defines the meaning of a form, while the cdr positions
don't. This is true both for Lisp-1 and Lisp-n. Now, when alongside
'plain' macros you add symbol macros / identifier macros, they become
easier to integrate into a Lisp-n than into a Lisp-1. Lisp-1 'pretends'
that all positions are the same for variable lookup, but the macro
system suddenly has to make the distinction between car and cdr
positions (and there is no way around it!). In a Lisp-n, the distinction
is already there from the start, so there is nothing unnatural about
adding symbol macros / identifier macros. It's actually quite easy and
straightforward.
Note: My preference for Lisp-n is a subjective one. There are some
technical arguments in favor of Lisp-n, and some against Lisp-n. But the
same is true for Lisp-1, there are both arguments in favor and against
Lisp-1. It's fine if you prefer Lisp-1 over Lisp-n, but it would be good
to acknowledge that this is also a subjective choice.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
P� Tue, 29 Jan 2008 10:02:34 +0100, skrev Pascal Costanza <··@p-cos.net>:
>
> You say that Scheme macro systems are too complicated. However, there is
> an important technical aspect there related to the Lisp-1 vs. Lisp-n
> issue: If you go for a Common Lisp-style macro system, a Lisp-1 makes
> macro programming more unreliable than a Lisp-n. Since a Lisp-1 squeezes
> all names into a single namespace, the likeliness for having accidental
> nameclashes is much higher. Lisp-n simply provides more 'air to
> breathe', so to speak.
>
Yes. I seem to hear this a lot.
I have two points.
1. lexical variables seem more important in avoiding naming conflicts than
context sensitive symbol binding. (List-2)
2. packages provide a more robust way of avoiding name conflicts.
in particular in a lisp-1 you could persumably write
(defpackage :my-package) ; no (:use :cl)
(in-package :my-package)
(defmacro sort! (sequence operator)
(lw:rebinding (sequence operator)
`(setf ,sequence (cl:sort ,sequence ,operator))))
(defun test ()
(let ((list (cl:list 3 2 1)))
(cl:print list)
(sort! list cl:<)
list))
and it would output:
(3 2 1)
(1 2 3)
(Ok so it is difficult to demonstrate for such a small example)
--------------
John Thingstad
Stefan Ram wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> The car position defines the meaning of a form,
>> while the cdr positions don't.
>
> The /meaning/ of, for example,
>
> (+ 1 2)
>
> is �The sum of 1 and 2.�. It obviously is
> �defined� by both the car, cadr, and the caddr.
...but the fact that is a function call, and not a macro or a special
form, is determined solely by the car.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Den Mon, 28 Jan 2008 21:39:30 -0600 skrev Blake McBride:
> In conclusion, Scheme has, IMO, many important shortcomings. I
> understand that I don't set the standards and these are just basically
> my opinions.
Which you have argued for quite well, but...
> Common Lisp, again IMO, did a lot of the right things. The one big
> technical error (IMO) was the LISPn thing. I know a bunch of you guys
> want to jump on me about this with all kinds of technical BS trying to
> rationalize your view.
C'mon, now, you really *do* want to get bashed, don't you? How else do
you expect to have a technical discussion where some kind of "real truth"
is established if the first thing you do is to call bullshit on anyone
who isn't you?
> The truth of the matter is that the highest and
> most respected experts on Common Lisp are utterly unclear about the
> issue. So how does that make you an expert? You are more of a fan club
> than a technical expert (again read the articles from the authors of
> Common Lisp).
Oh, I see, so in essence you're saying that:
1) Anyone who posts here is not an expert (sorry, Kent), although you
leave the notion of "experts" ill-specified, really
2) Anyone but experts is by definition unable to have an informed opinion
and only allowed to have bullshit fanboy views?
From 1) and 2), using my amazing powers of logic, I can infer that your
opinions have no merit and are just a bunch of fanboy crap.
> The real truth is that the number one reason Common Lisp
> is LISPn rather than LISP1 is historical and for purposes of backward
> compatibility (all of which is hardly applicable anymore). It isn't
> technically better. The experts were able to point out trade-offs with
> either design. They even stated that LISP1 encouraged more elegant
> programming style.
>
> I would bet that the number one reason so many people use Scheme instead
> of Common Lisp is the LISP1 reason. It is Scheme's biggest appeal. (My
> guess is that Common Lisp is more popular than Scheme. I am just trying
> to explain the large number of Scheme users.)
I would bet that in "formative years" the issue is just not important at
all for choosing, I doubt most people are even aware of the Lisp-arity
issue until they are reasonably proficient in at least one of the
dialects. I for one had used a number of languages (all of them unary, of
course) before Lisp, and never had to do with any Lisp-1 (I started with
Elisp), and I was unaware of the distinction for a number of years. But
when I learnt about the double namespaces in Elisp, I immediately thought
it really neat and elegant, so I'd seriously challenge your claim that
somehow any sane thinking individual has to prefer Lisp-1 unless they had
prior indoctrination.
Cheers,
Maciej
Maciej Katafiasz wrote:
>
> Oh, I see, so in essence you're saying that:
>
> 1) Anyone who posts here is not an expert (sorry, Kent), although you
> leave the notion of "experts" ill-specified, really
Unintended.
>
> 2) Anyone but experts is by definition unable to have an informed opinion
> and only allowed to have bullshit fanboy views?
Unintended.
Blake McBride wrote:
> I would bet that the number one reason so many people use Scheme
> instead of Common Lisp is the LISP1 reason. It is Scheme's biggest
> appeal. (My guess is that Common Lisp is more popular than Scheme. I
> am just trying to explain the large number of Scheme users.)
There's a bit in _Structure_And_Interpretation_Of_Computer_Programs
(chapter 1, I think ... could be a foreword or something) about why
they chose Scheme for the language in which they wanted to present
ideas and algorithms.
Simply put, it was because they didn't have to spend much (hardly any) time
explaining or teaching the language itself. Most bright students would
pick up the basics in a few days, at most, and then the instructor could
concentrate on algorithms and ideas rather than on the language itself. At
the same time the language was capable of making semantic distinctions
sufficiently clear and precise to *show* these ideas, flexible enough
to build systems for programming with a bunch of different paradigms
(Imperative, Functional, Object-Oriented, Unification, Cooperative
Multitasking, etc).
And that explains why scheme was a nearly ideal pedagogic language.
I liked it because it was clean and elegant (Remember this was R3RS
and R4RS scheme, depending on which edition of SICP we're talking about -
well before some of the less fortunate design decisions that have
happened since). It allowed me to write clear, useful, and reasonably
compact code on the basis of knowing just 20 or so constructs.
I probably never would have felt like I had to quit using it and switch
to Common Lisp (or a homebrew lisp) instead if it hadn't been for R6RS.
Bear
Ray Dillinger wrote:
> I probably never would have felt like I had to quit using it and switch
> to Common Lisp (or a homebrew lisp) instead if it hadn't been for R6RS.
Consider ISLISP. It's also reasonably small (smaller than R6RS I think),
and the switch to Common Lisp is not that hard. ;)
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Blake McBride <·····@mcbride.name> writes:
> In conclusion, Scheme has, IMO, many important shortcomings. I
> understand that I don't set the standards and these are just basically
> my opinions. Although I believe these shortcomings are relatively
> easy to fix, the real problem is the political element. No matter
> what you think there is always someone out there who thinks the
> opposite. The net result is that language development ends up
> unnecessarily slow.
>
> Common Lisp, again IMO, did a lot of the right things. The one big
> technical error (IMO) was the LISPn thing. I know a bunch of you guys
> want to jump on me about this with all kinds of technical BS trying to
> rationalize your view.
Don't be an asshole. You complained about getting flak, so don't give it out.
Instead, argue on the technical merits. That's what makes a newsgroup useful
and interesting: discussions.
> The truth of the matter is that the highest and most respected experts on
> Common Lisp are utterly unclear about the issue. So how does that make you
> an expert? You are more of a fan club than a technical expert (again read
> the articles from the authors of Common Lisp).
How do you know our expertise? How do we? By thinking, reasoning, and
discussing. "You don't have a valid opinion because you are not an expert" is
bullshit. Validity is based on the merits of what was said, not who said it.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Blake McBride <·····@mcbride.name> wrote:
> > Common Lisp, again IMO, did a lot of the right things. The one big
> > technical error (IMO) was the LISPn thing. I know a bunch of you guys
> > want to jump on me about this with all kinds of technical BS trying to
> > rationalize your view.
Ray Blaak <········@STRIPCAPStelus.net> wrote:
> Don't be an asshole. You complained about getting flak, so don't give it out.
> ...
The assholes here are the Common Lispers.
In the beginning, the CL fuckheads all attacked Blake.
Now, by request, Blake gave 4 reasons how he didn't like Scheme, and 1
reason why he didn't like Common Lisp's multi-meaning-space. Then, so
far like 5 Common Lisp fuckheads all responded rather hashly. Reading
his message only in the most negative way possible. Note that in
Blake's message where he gave reasons he didn't like the Common Lisp
model, which is itself a reaction from the CL fuckheads who beat him
up before. In my opinion, he can just say “Lisp1 fuckheads, fuck you
and die”, and i would think it is justified. However, he nevertheless
are quite polite in his words, and really effectively just said that
even experts don't agree and he's entitled to his opinions.
Listen, Common Lispers, fuck you and die.
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
Correction:
The phrase “Lisp1 fuckheads, fuck you and die” should have been “Lisp2
fuckheads, fuck you and die”.
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
Blake McBride wrote:
> Ray Blaak wrote:
> 2. There are a number of design decisions associated with Scheme
> which I strongly disagree with.
>
>
I would appreciate you to elaborate more on this point and If those
warts may be cured by R6RS?
> Blake McBride
Ray Blaak wrote:
> Blake McBride <·····@mcbride.name> writes:
>> Announcing a new release of Lisp1.
> [...]
>> A portable (ANSI) Common Lisp program that makes Common Lisp operate
>> as a LISP1 Lisp.
>
> Not to diminish your efforts, but I wonder why you would bother doing this, or
> why one would bother using this.
Common Lisp is a very good basis for multiparadigm programming. It
supports imperative, object-oriented and functional programming really
well. However, a certain higher-order programming style works a bit
better in a Lisp-1 than in a Lisp-n. It would be nice to be able to
switch "worlds" in that regard.
> If the use of Lisp1 is important to a programmer, they should just use a real
> Lisp1 language. Pick a decent scheme implementation.
...or Dylan. If it only had s-expression syntax.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Jan 27, 9:03 pm, Pascal Costanza <····@p-cos.net> wrote:
> Ray Blaak wrote:
> [...]
> > If the use of Lisp1 is important to a programmer, they should just use a real
> > Lisp1 language. Pick a decent scheme implementation.
>
> ...or Dylan. If it only had s-expression syntax.
>
From what I understand, the reason most languages don't have macros is
because they don't have s-exps. Now, IIRC Dylan has that. It'd seem
that's one of the most compelling reasons to use Lisp.
So, what does Dylan offer that CL does not?
(I'm sorry if I come across as offensive, however I'm just curious!)
--
Mikael
http://mikael.jansson.be
··············@gmail.com wrote:
> On Jan 27, 9:03 pm, Pascal Costanza <····@p-cos.net> wrote:
>> Ray Blaak wrote:
>> [...]
>>> If the use of Lisp1 is important to a programmer, they should just use a real
>>> Lisp1 language. Pick a decent scheme implementation.
>> ...or Dylan. If it only had s-expression syntax.
>>
> From what I understand, the reason most languages don't have macros is
> because they don't have s-exps. Now, IIRC Dylan has that. It'd seem
> that's one of the most compelling reasons to use Lisp.
S-expressions are not a strict requirement for having macros in a
language. You can even add a full AST-based macro system to a highly
syntactically irregular language, like Java. The more regular the
syntax, though, the easier it is and, IMHO, the easier it is to actually
define and use macros. S-expressions are as regular as it gets, and thus
make macros very straightforward.
> So, what does Dylan offer that CL does not?
Not much. It has a somewhat nicer integration of its object system with
the base language. Common Lisp distinguishes between generic functions,
plain functions and methods. If I understand correctly, in Dylan they
are all integrated into the same unified notion of a method. On the
other hand, CLOS still has more complete support for metaprogramming in
terms of its metaobject protocol and user-defined method combinations.
(I am not aware of any object system that it as complete as CLOS, not
even any of the CLOS derivatives in other Lisp dialects, like Scheme.)
Apparently, Dylan's iteration framework seems to be very nice (but that
could already be added as a plain library, like
http://common-lisp.net/project/cl-containers/ ).
Maybe there's more, but I wouldn't know off the top of my head.
Nevertheless, I think it would be a much better Scheme than the R6RS
mess, if it only were based on s-expressions. However, some of the Dylan
supporters really like the more mainstream Dylan syntax, so it's not
very likely to happen...
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> ··············@gmail.com wrote:
> > On Jan 27, 9:03 pm, Pascal Costanza <····@p-cos.net> wrote:
> >> Ray Blaak wrote:
> >> [...]
> >>> If the use of Lisp1 is important to a programmer, they should just use a real
> >>> Lisp1 language. Pick a decent scheme implementation.
> >> ...or Dylan. If it only had s-expression syntax.
> >>
> > From what I understand, the reason most languages don't have macros is
> > because they don't have s-exps. Now, IIRC Dylan has that. It'd seem
> > that's one of the most compelling reasons to use Lisp.
>
> S-expressions are not a strict requirement for having macros in a
> language. You can even add a full AST-based macro system to a highly
> syntactically irregular language, like Java. The more regular the
> syntax, though, the easier it is and, IMHO, the easier it is to actually
> define and use macros. S-expressions are as regular as it gets, and thus
> make macros very straightforward.
It also should be noted that ANSI CL lacks the access to
the environment information during macro expansion.
Much of that was in CLtL2, but didn't make it into ANSI CL.
http://lispm.dyndns.org/documentation/cltl2/clm/node102.html#SECTION001250000000000000000
>
> > So, what does Dylan offer that CL does not?
>
> Not much. It has a somewhat nicer integration of its object system with
> the base language. Common Lisp distinguishes between generic functions,
> plain functions and methods. If I understand correctly, in Dylan they
> are all integrated into the same unified notion of a method. On the
> other hand, CLOS still has more complete support for metaprogramming in
> terms of its metaobject protocol and user-defined method combinations.
> (I am not aware of any object system that it as complete as CLOS, not
> even any of the CLOS derivatives in other Lisp dialects, like Scheme.)
>
> Apparently, Dylan's iteration framework seems to be very nice (but that
> could already be added as a plain library, like
> http://common-lisp.net/project/cl-containers/ ).
>
> Maybe there's more, but I wouldn't know off the top of my head.
>
> Nevertheless, I think it would be a much better Scheme than the R6RS
> mess, if it only were based on s-expressions. However, some of the Dylan
> supporters really like the more mainstream Dylan syntax, so it's not
> very likely to happen...
>
>
> Pascal
Rainer Joswig wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> ··············@gmail.com wrote:
>>> On Jan 27, 9:03 pm, Pascal Costanza <····@p-cos.net> wrote:
>>>> Ray Blaak wrote:
>>>> [...]
>>>>> If the use of Lisp1 is important to a programmer, they should just use a real
>>>>> Lisp1 language. Pick a decent scheme implementation.
>>>> ...or Dylan. If it only had s-expression syntax.
>>>>
>>> From what I understand, the reason most languages don't have macros is
>>> because they don't have s-exps. Now, IIRC Dylan has that. It'd seem
>>> that's one of the most compelling reasons to use Lisp.
>> S-expressions are not a strict requirement for having macros in a
>> language. You can even add a full AST-based macro system to a highly
>> syntactically irregular language, like Java. The more regular the
>> syntax, though, the easier it is and, IMHO, the easier it is to actually
>> define and use macros. S-expressions are as regular as it gets, and thus
>> make macros very straightforward.
>
> It also should be noted that ANSI CL lacks the access to
> the environment information during macro expansion.
> Much of that was in CLtL2, but didn't make it into ANSI CL.
>
> http://lispm.dyndns.org/documentation/cltl2/clm/node102.html#SECTION001250000000000000000
That's a bit harsh. Yes, something like what is described in CLtL2 would
be very nice here, but you can already do a lot (really a lot) with what
is already provided in ANSI Common Lisp.
The trick is to use symbol-macrolet / macrolet to pass around
information, and macrolet / macrolet-1 to retrieve that information
again. (It's actually pretty close to expansion-passing style.)
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Rainer Joswig wrote:
> > In article <···············@mid.individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> ··············@gmail.com wrote:
> >>> On Jan 27, 9:03 pm, Pascal Costanza <····@p-cos.net> wrote:
> >>>> Ray Blaak wrote:
> >>>> [...]
> >>>>> If the use of Lisp1 is important to a programmer, they should just use
> >>>>> a real
> >>>>> Lisp1 language. Pick a decent scheme implementation.
> >>>> ...or Dylan. If it only had s-expression syntax.
> >>>>
> >>> From what I understand, the reason most languages don't have macros is
> >>> because they don't have s-exps. Now, IIRC Dylan has that. It'd seem
> >>> that's one of the most compelling reasons to use Lisp.
> >> S-expressions are not a strict requirement for having macros in a
> >> language. You can even add a full AST-based macro system to a highly
> >> syntactically irregular language, like Java. The more regular the
> >> syntax, though, the easier it is and, IMHO, the easier it is to actually
> >> define and use macros. S-expressions are as regular as it gets, and thus
> >> make macros very straightforward.
> >
> > It also should be noted that ANSI CL lacks the access to
> > the environment information during macro expansion.
> > Much of that was in CLtL2, but didn't make it into ANSI CL.
> >
> > http://lispm.dyndns.org/documentation/cltl2/clm/node102.html#SECTION00125000
> > 0000000000000
>
> That's a bit harsh. Yes, something like what is described in CLtL2 would
> be very nice here, but you can already do a lot (really a lot) with what
> is already provided in ANSI Common Lisp.
>
> The trick is to use symbol-macrolet / macrolet to pass around
> information, and macrolet / macrolet-1 to retrieve that information
> again. (It's actually pretty close to expansion-passing style.)
You mean macroexpand/macroexpand-1 I presume.
rg
Ron Garret wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Rainer Joswig wrote:
>>> In article <···············@mid.individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>> ··············@gmail.com wrote:
>>>>> On Jan 27, 9:03 pm, Pascal Costanza <····@p-cos.net> wrote:
>>>>>> Ray Blaak wrote:
>>>>>> [...]
>>>>>>> If the use of Lisp1 is important to a programmer, they should just use
>>>>>>> a real
>>>>>>> Lisp1 language. Pick a decent scheme implementation.
>>>>>> ...or Dylan. If it only had s-expression syntax.
>>>>>>
>>>>> From what I understand, the reason most languages don't have macros is
>>>>> because they don't have s-exps. Now, IIRC Dylan has that. It'd seem
>>>>> that's one of the most compelling reasons to use Lisp.
>>>> S-expressions are not a strict requirement for having macros in a
>>>> language. You can even add a full AST-based macro system to a highly
>>>> syntactically irregular language, like Java. The more regular the
>>>> syntax, though, the easier it is and, IMHO, the easier it is to actually
>>>> define and use macros. S-expressions are as regular as it gets, and thus
>>>> make macros very straightforward.
>>> It also should be noted that ANSI CL lacks the access to
>>> the environment information during macro expansion.
>>> Much of that was in CLtL2, but didn't make it into ANSI CL.
>>>
>>> http://lispm.dyndns.org/documentation/cltl2/clm/node102.html#SECTION00125000
>>> 0000000000000
>> That's a bit harsh. Yes, something like what is described in CLtL2 would
>> be very nice here, but you can already do a lot (really a lot) with what
>> is already provided in ANSI Common Lisp.
>>
>> The trick is to use symbol-macrolet / macrolet to pass around
>> information, and macrolet / macrolet-1 to retrieve that information
>> again. (It's actually pretty close to expansion-passing style.)
>
> You mean macroexpand/macroexpand-1 I presume.
Yes, thanks for the catch.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Rainer Joswig wrote:
> > In article <···············@mid.individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> ··············@gmail.com wrote:
> >>> On Jan 27, 9:03 pm, Pascal Costanza <····@p-cos.net> wrote:
> >>>> Ray Blaak wrote:
> >>>> [...]
> >>>>> If the use of Lisp1 is important to a programmer, they should just use a real
> >>>>> Lisp1 language. Pick a decent scheme implementation.
> >>>> ...or Dylan. If it only had s-expression syntax.
> >>>>
> >>> From what I understand, the reason most languages don't have macros is
> >>> because they don't have s-exps. Now, IIRC Dylan has that. It'd seem
> >>> that's one of the most compelling reasons to use Lisp.
> >> S-expressions are not a strict requirement for having macros in a
> >> language. You can even add a full AST-based macro system to a highly
> >> syntactically irregular language, like Java. The more regular the
> >> syntax, though, the easier it is and, IMHO, the easier it is to actually
> >> define and use macros. S-expressions are as regular as it gets, and thus
> >> make macros very straightforward.
> >
> > It also should be noted that ANSI CL lacks the access to
> > the environment information during macro expansion.
> > Much of that was in CLtL2, but didn't make it into ANSI CL.
> >
> > http://lispm.dyndns.org/documentation/cltl2/clm/node102.html#SECTION001250000000000000000
>
> That's a bit harsh. Yes, something like what is described in CLtL2 would
> be very nice here, but you can already do a lot (really a lot) with what
> is already provided in ANSI Common Lisp.
>
> The trick is to use symbol-macrolet / macrolet to pass around
> information, and macrolet / macrolet-1 to retrieve that information
> again. (It's actually pretty close to expansion-passing style.)
Would you use that to write a portable code walker that would be
able to identify variables, functions, declarations, variable types, ...?
>
>
> Pascal
Rainer Joswig wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Rainer Joswig wrote:
>>> It also should be noted that ANSI CL lacks the access to
>>> the environment information during macro expansion.
>>> Much of that was in CLtL2, but didn't make it into ANSI CL.
>>>
>>> http://lispm.dyndns.org/documentation/cltl2/clm/node102.html#SECTION001250000000000000000
>> That's a bit harsh. Yes, something like what is described in CLtL2 would
>> be very nice here, but you can already do a lot (really a lot) with what
>> is already provided in ANSI Common Lisp.
>>
>> The trick is to use symbol-macrolet / macrolet to pass around
>> information, and macroexpand / macroexpand-1 to retrieve that information
>> again. (It's actually pretty close to expansion-passing style.)
>
> Would you use that to write a portable code walker that would be
> able to identify variables, functions, declarations, variable types, ...?
I'm not sure, because I don't have that much experience with code
walkers, but I guess I would give it a try. My gut feeling is that it
should be doable.
ANSI CL's environment objects are primarily good for passing information
from outer scopes to inner scopes (like "This variable has the following
declared type."), and for that you don't need a code walker, you just
need symbol-macrolet / macrolet and macroexpand. Passing information
from inner scopes to outer scopes (like "Is this function ever used as a
first-class value inside this body?") is definitely harder.
It is possible to additionally use *macroexpand-hook* to embed a code
walker inside a macro, but that's quite shaky. (That's the only way I
tried to implement a code walker myself so far.)
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Rainer Joswig wrote:
>> In article <···············@mid.individual.net>,
>> Pascal Costanza <··@p-cos.net> wrote:
>>
>>> Rainer Joswig wrote:
>>>> It also should be noted that ANSI CL lacks the access to
>>>> the environment information during macro expansion.
>>>> Much of that was in CLtL2, but didn't make it into ANSI CL.
>>>>
>>>> http://lispm.dyndns.org/documentation/cltl2/clm/node102.html#SECTION001250000000000000000
>>> That's a bit harsh. Yes, something like what is described in CLtL2
>>> would be very nice here, but you can already do a lot (really a
>>> lot) with what is already provided in ANSI Common Lisp.
>>>
>>> The trick is to use symbol-macrolet / macrolet to pass around
>>> information, and macroexpand / macroexpand-1 to retrieve that
>>> information again. (It's actually pretty close to expansion-passing
>>> style.)
>> Would you use that to write a portable code walker that would be
>> able to identify variables, functions, declarations, variable types, ...?
>
> I'm not sure, because I don't have that much experience with code
> walkers, but I guess I would give it a try. My gut feeling is that it
> should be doable.
But why bother, when it's already been done for you? ...
http://www.lispwire.com/entry-proganal-envaccess-des
This package is portable in the sense that it compiles, loads, and
provides information on many major CL implementations (though I'm told
by Raymond Toy that there are some diffs for CMUCL that need to be
applied; I haven't seen them yet, but I'll put them in as soon as I
do. And Ray and Carl Shapiro have been working to get this (or
similar) functionality into CMUCL to the point where the compiler
actually uses it for its environment information.
> ANSI CL's environment objects are primarily good for passing
> information from outer scopes to inner scopes (like "This variable has
> the following declared type."), and for that you don't need a code
> walker, you just need symbol-macrolet / macrolet and
> macroexpand. Passing information from inner scopes to outer scopes
> (like "Is this function ever used as a first-class value inside this
> body?") is definitely harder.
and fairly soon you find that you've reimpemented first-class
environments.
To be fair, environments are already first-class for most
implementations; it is just that their interfaces are either not
public or not portable, and the above module is an attempt to inject
the Environments chapter of CLtL2 back into CL implementations.
> It is possible to additionally use *macroexpand-hook* to embed a code
> walker inside a macro, but that's quite shaky. (That's the only way I
> tried to implement a code walker myself so far.)
Well, you get the environment object, but that's no different than
defining your macro with the &environment element in the lambda list.
And I suspect that unless you know the format of the environment
object you can't portably reason about the environment nor make all of
the changes that are possible with a true portable interface.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Rainer Joswig wrote:
>>> In article <···············@mid.individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>> Rainer Joswig wrote:
>>>>> It also should be noted that ANSI CL lacks the access to
>>>>> the environment information during macro expansion.
>>>>> Much of that was in CLtL2, but didn't make it into ANSI CL.
>>>>>
>>>>> http://lispm.dyndns.org/documentation/cltl2/clm/node102.html#SECTION001250000000000000000
>>>> That's a bit harsh. Yes, something like what is described in CLtL2
>>>> would be very nice here, but you can already do a lot (really a
>>>> lot) with what is already provided in ANSI Common Lisp.
>>>>
>>>> The trick is to use symbol-macrolet / macrolet to pass around
>>>> information, and macroexpand / macroexpand-1 to retrieve that
>>>> information again. (It's actually pretty close to expansion-passing
>>>> style.)
>>> Would you use that to write a portable code walker that would be
>>> able to identify variables, functions, declarations, variable types, ...?
>> I'm not sure, because I don't have that much experience with code
>> walkers, but I guess I would give it a try. My gut feeling is that it
>> should be doable.
>
> But why bother, when it's already been done for you? ...
>
> http://www.lispwire.com/entry-proganal-envaccess-des
Sure, that would be better.
>> It is possible to additionally use *macroexpand-hook* to embed a code
>> walker inside a macro, but that's quite shaky. (That's the only way I
>> tried to implement a code walker myself so far.)
>
> Well, you get the environment object, but that's no different than
> defining your macro with the &environment element in the lambda list.
> And I suspect that unless you know the format of the environment
> object you can't portably reason about the environment nor make all of
> the changes that are possible with a true portable interface.
*macroexpand-hook* allows you to see all macroexpansions, not just those
for your own macros. That can make a difference in some cases (but
that's probably only a theoretical advantage).
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Edi Weitz
Subject: Re: Announcing a new release of Lisp1
Date:
Message-ID: <u4pcxhaxp.fsf@agharta.de>
On Mon, 28 Jan 2008 15:35:50 +0100, Pascal Costanza <··@p-cos.net> wrote:
> The trick is to use symbol-macrolet / macrolet to pass around
> information, and macrolet / macrolet-1 to retrieve that information
> again. (It's actually pretty close to expansion-passing style.)
Could you provide a small example? I don't think I fully understand
what you mean.
Thanks,
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Tobias C. Rittweiler
Subject: Re: Announcing a new release of Lisp1
Date:
Message-ID: <87tzkx8uqz.fsf@freebits.de>
Edi Weitz <········@agharta.de> writes:
> On Mon, 28 Jan 2008 15:35:50 +0100, Pascal Costanza <··@p-cos.net> wrote:
>
> > The trick is to use symbol-macrolet / macrolet to pass around
> > information, and macrolet / macrolet-1 to retrieve that information
> > again. (It's actually pretty close to expansion-passing style.)
>
> Could you provide a small example? I don't think I fully understand
> what you mean.
Look into the issue write up about COMPILER-LET.
-T.
From: Edi Weitz
Subject: Re: Announcing a new release of Lisp1
Date:
Message-ID: <uejc1fusz.fsf@agharta.de>
On Mon, 28 Jan 2008 23:12:36 +0100, "Tobias C. Rittweiler" <···@freebits.de.invalid> wrote:
> Look into the issue write up about COMPILER-LET.
Thanks!
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")