Could anyone recommend a LISP environment? I have a ten-year old
version of Harlequin on a PC and a 15-year-old version of MCL on a 120
mh Mac clone. Are the Mac LISPs sufficiently better than the PC LISPs
to justify buying a new Mac?
On May 1, 11:22 pm, bridgetrix <········@gmail.com> wrote:
> Could anyone recommend a LISP environment?
Thnake (http://ifile.it/28upfjt) + unetbootin
(unetbootin.sourceforge.net) + a cheap usb flash pen = a cheap and
easy slime + sbcl on linux with no need to install anything to your
pc.
And a portable lisp environment as well.
On Fri, 01 May 2009 19:22:15 -0700, bridgetrix wrote:
> Could anyone recommend a LISP environment? I have a ten-year old
> version of Harlequin on a PC and a 15-year-old version of MCL on a 120
> mh Mac clone. Are the Mac LISPs sufficiently better than the PC LISPs
> to justify buying a new Mac?
I don't think so. If you already have a PC, you can experiment with the
following Lisp environments to see which one works for you:
Emacs + SLIME + various implementations
ABLE (http://phil.nullable.eu/)
Various commercial implementations have versions you can use for free
(and if you have been working on an aged Mac, the limitations imposed
on the free versions should not be binding :-)), and have their own
IDEs.
HTH,
Tamas
On 2 Mai, 04:22, bridgetrix <········@gmail.com> wrote:
> Could anyone recommend a LISP environment? I have a ten-year old
> version of Harlequin on a PC and a 15-year-old version of MCL on a 120
> mh Mac clone. Are the Mac LISPs sufficiently better than the PC LISPs
> to justify buying a new Mac?
It depends on what you want to do. To me, the Mac developer tools and
frameworks are alot more fun than anything MS Windows has to offer.
Many current Common Lisp systems have good access to Cocoa and other
Objective-C frameworks. Accessing an Objective-C framework using a
Objective-C bridge like in LispWorks or Clozure CL is much easier than
accessing plain C libraries not even thinking of abysmal ideas like C+
+ or COM (shudder). So if you actually want to do applications
development and the OS is not that important, you could have a lot
more fun using CL on a Mac.
If you want to use Windows, the commercial CL systems currently
provide alot more tools to make your life easier. They enable
relatively easy access to implement COM interfaces and offer solid
lisp-level GUI libraries. Perhaps one could do all those things on
some free CL system today too - but I guess it will have to do alot
more work on your own. One option might be to use something like RDNZL
which makes access to .NET easy - this would be something like the
counterpart of an Objective-C bridge on Mac OS X.
ciao,
Jochen Schmidt
bridgetrix wrote:
> Could anyone recommend a LISP environment? I have a ten-year old
> version of Harlequin on a PC and a 15-year-old version of MCL on a 120
> mh Mac clone. Are the Mac LISPs sufficiently better than the PC LISPs
> to justify buying a new Mac?
Harlequin is now called LispWorks Inc. [1], and their IDE is still
supported on Linux, Windows and Mac OS X.
MCL is not supported anymore, but there is now an open source fork based
on the original MCL environment called Clozure Common Lisp, also
supported on various operating systems (including at Linux and Mac OS X,
maybe more).
There are more actively supported Lisp implementations. See a recent
survey by Dan Weinreb here: http://common-lisp.net/~dlw/LispSurvey.html
Pascal
[1] Well, that's an oversimplification of the history, but good enough
for the moment. ;)
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
bridgetrix schrieb:
> Could anyone recommend a LISP environment? I have a ten-year old
> version of Harlequin on a PC and a 15-year-old version of MCL on a 120
> mh Mac clone. Are the Mac LISPs sufficiently better than the PC LISPs
> to justify buying a new Mac?
Have a look at http://clojure.org/
and the Enclojure IDE: http://www.enclojure.org/
Clojure is a modern Lisp dialect, and it runs under all major OSes.
I suggest you to consider using it.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Andr� Thieme <> writes:
> Clojure is a modern Lisp dialect, and it runs under all major OSes.
> I suggest you to consider using it.
Please say "recent", or perhaps "new", rather than modern. That is if
you do not want to appear to be on the marketing campaign that others
accused you to be.
-T.
Tobias C. Rittweiler schrieb:
> Andr� Thieme <> writes:
>
>> Clojure is a modern Lisp dialect, and it runs under all major OSes.
>> I suggest you to consider using it.
>
> Please say "recent", or perhaps "new", rather than modern. That is if
> you do not want to appear to be on the marketing campaign that others
> accused you to be.
What criterias would a Lisp dialect have to fullfil to be called
modern rightfully?
Btw, why did you add this personal note to me in public? Your first
sentence would have been enough to express your opinion.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Andr� Thieme wrote:
> Tobias C. Rittweiler schrieb:
>> Andr� Thieme <> writes:
>>
>>> Clojure is a modern Lisp dialect, and it runs under all major OSes.
>>> I suggest you to consider using it.
>>
>> Please say "recent", or perhaps "new", rather than modern. That is if
>> you do not want to appear to be on the marketing campaign that others
>> accused you to be.
>
> What criterias would a Lisp dialect have to fullfil to be called
> modern rightfully?
My Thesaurus lists "out of date" and "old fashioned" as antonyms for
"modern." Which Lisps do you consider "out of date" or "old fashioned"
as opposed to Clojure? (If you don't consider any "out of date" or "old
fashioned", your statement doesn't make any sense. That's why I'm asking.)
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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 schrieb:
> Andr� Thieme wrote:
>> Tobias C. Rittweiler schrieb:
>>> Andr� Thieme <> writes:
>>>
>>>> Clojure is a modern Lisp dialect, and it runs under all major
>>>> OSes. I suggest you to consider using it.
>>>
>>> Please say "recent", or perhaps "new", rather than modern. That
>>> is if you do not want to appear to be on the marketing campaign
>>> that others accused you to be.
>>
>> What criterias would a Lisp dialect have to fullfil to be called
>> modern rightfully?
>
> My Thesaurus lists "out of date" and "old fashioned" as antonyms for
> "modern." Which Lisps do you consider "out of date" or "old
> fashioned" as opposed to Clojure? (If you don't consider any "out of
> date" or "old fashioned", your statement doesn't make any sense.
> That's why I'm asking.)
I consider for example Common Lisp as �out of date�.
Other than with food it does not mean that one should not use it anymore.
We have three ways to look at it:
1) the language itself
2) concrete implementations
3) environment around the langauge and implementation
To point 1):
The CL standard does not explicitly support threading.
That already is enough to be outdated in todays world.
From the set of developments and advances that took place in the past 15
years since ANSI some proved to be good and became mature. None of those
had the chance to go into the spec. If the spec would be written today
it would not be identical. And I think not only fragments would be
modified.
For example take this quote which William James posted:
Having separate "value cells" and "function cells" (to use the "street
language" way of saying it) was one of the most unfortuanate issues.
We did not want to break pre-existing programs that had a global
variable named "foo" and a global function named "foo" that were
distinct. We at Symbolics were forced to insist on this, in the face
of everyone's knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all the
specific things like this, but if we had had fewer compatibility
issues, I think it would have come out looking more like Scheme in
general. --- Daniel Weinreb, 24 Feb 2003
If even one of those guys who worked on the standard says this, it
means it is outdated.
To point 2):
Here we are no longer talking about the languages but the VMs they run
on. Those are constantly evolving. We need to decide explicitly at which
ones we want to look. For example it could be clisp, but also SBCL.
For Clojure it should be Suns JVM and the OpenJDK.
Suns JVM for example still does not offer TCO. That is outdated. It is
also outdated in other aspects, for example tagged numbers, which are
working very well in SBCL.
But things like HotSpot are years away for CL implementations. Also
STMs are typically not available, no MVCC. The new Garbage First
Collector has no equivalent in clisp or Lispworks.
So while some CLs have good points here, the sheer amount of man hours
that goes into Suns JVM or the OpenJDK are something that CL implementors
can't compete with currently.
To point 3):
The lib situation for CL is not as bad as it used to be. But still, if I
want to integrate SAP into my software I have no native drivers.
NetBeans GUI builder is one of the most advanced available. Compare that
with the one available in Lispworks.
It's again the money --> man hours.
With Terracotta there exists an excellent clustering solution. If a CL
app does not scale the programmers will have to leave their domain and
do need to program cluster code.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 2, 12:19 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> For example take this quote which William James posted:
>
> Having separate "value cells" and "function cells" (to use the "street
> language" way of saying it) was one of the most unfortuanate issues.
> We did not want to break pre-existing programs that had a global
> variable named "foo" and a global function named "foo" that were
> distinct. We at Symbolics were forced to insist on this, in the face
> of everyone's knowing that it was not what we would have done absent
> compatibility constraints. It's hard for me to remember all the
> specific things like this, but if we had had fewer compatibility
> issues, I think it would have come out looking more like Scheme in
> general. --- Daniel Weinreb, 24 Feb 2003
>
> If even one of those guys who worked on the standard says this, it
> means it is outdated.
That's an amusing quote, really.
Andr� Thieme <······························@justmail.de> writes:
>>>>> Clojure is a modern Lisp dialect, and it runs under all major
>>>>> OSes. I suggest you to consider using it.
> [...]
> I consider for example Common Lisp as �out of date�.
Hi! Where can I find the ANSI or IEEE standard for Clojure? I would like
to compare myself.
Nicolas
--
Lisp is not dead. It�s only Andre Thieme who has stumbled off the road.
On Sat, 02 May 2009 17:46:03 +0200
Nicolas Neuss <········@math.uni-karlsruhe.de> wrote:
> André Thieme <······························@justmail.de> writes:
>
> >>>>> Clojure is a modern Lisp dialect, and it runs under all major
> >>>>> OSes. I suggest you to consider using it.
> > [...]
> > I consider for example Common Lisp as “out of date”.
>
> Hi! Where can I find the ANSI or IEEE standard for Clojure? I would
> like to compare myself.
Yep, complaining about the lack of threading in the CL standard when
Clojure has no standard at all is not really that fortunate.
That said, I don't know anyone who still uses only IEEE Scheme instead
of some more recent "community" standard :)
regards,
Marek
On May 2, 3:35 pm, Marek Kubica <·····@xivilization.net> wrote:
> On Sat, 02 May 2009 17:46:03 +0200
>
> Nicolas Neuss <········@math.uni-karlsruhe.de> wrote:
> > André Thieme <······························@justmail.de> writes:
>
> > >>>>> Clojure is a modern Lisp dialect, and it runs under all major
> > >>>>> OSes. I suggest you to consider using it.
> > > [...]
> > > I consider for example Common Lisp as “out of date”.
>
> > Hi! Where can I find the ANSI or IEEE standard for Clojure? I would
> > like to compare myself.
>
> Yep, complaining about the lack of threading in the CL standard when
> Clojure has no standard at all is not really that fortunate.
>
> That said, I don't know anyone who still uses only IEEE Scheme instead
> of some more recent "community" standard :)
Forget that! Enterprises around the world are shocked in horror that
there's no such a thing as IEEE or ANSI Java!
Andr� Thieme wrote:
> Pascal Costanza schrieb:
>> Andr� Thieme wrote:
>>> Tobias C. Rittweiler schrieb:
>>>> Andr� Thieme <> writes:
>>>>
>>>>> Clojure is a modern Lisp dialect, and it runs under all major
>>>>> OSes. I suggest you to consider using it.
>>>>
>>>> Please say "recent", or perhaps "new", rather than modern. That
>>>> is if you do not want to appear to be on the marketing campaign
>>>> that others accused you to be.
>>>
>>> What criterias would a Lisp dialect have to fullfil to be called
>>> modern rightfully?
>>
>> My Thesaurus lists "out of date" and "old fashioned" as antonyms for
>> "modern." Which Lisps do you consider "out of date" or "old
>> fashioned" as opposed to Clojure? (If you don't consider any "out of
>> date" or "old fashioned", your statement doesn't make any sense.
>> That's why I'm asking.)
>
> I consider for example Common Lisp as �out of date�.
> Other than with food it does not mean that one should not use it anymore.
> We have three ways to look at it:
> 1) the language itself
> 2) concrete implementations
> 3) environment around the langauge and implementation
>
> To point 1):
> The CL standard does not explicitly support threading.
> That already is enough to be outdated in todays world.
...but the implementations do.
That is already enough to stop discussing this particular point.
> From the set of developments and advances that took place in the past 15
> years since ANSI some proved to be good and became mature. None of those
> had the chance to go into the spec. If the spec would be written today
> it would not be identical. And I think not only fragments would be
> modified.
> For example take this quote which William James posted:
>
> Having separate "value cells" and "function cells" (to use the "street
> language" way of saying it) was one of the most unfortuanate issues.
> We did not want to break pre-existing programs that had a global
> variable named "foo" and a global function named "foo" that were
> distinct. We at Symbolics were forced to insist on this, in the face
> of everyone's knowing that it was not what we would have done absent
> compatibility constraints. It's hard for me to remember all the
> specific things like this, but if we had had fewer compatibility
> issues, I think it would have come out looking more like Scheme in
> general. --- Daniel Weinreb, 24 Feb 2003
>
> If even one of those guys who worked on the standard says this, it
> means it is outdated.
What is true is that the people who worked on the standard also have
their opinions, like everybody else.
There are enough people who think that a Lisp-2, or Lisp-n, is superior
to a Lisp-1, among other reasons because they make macros more reliable.
To me, whenever a new Lisp dialect comes out that chooses to go the
Lisp-1 route, this seems like a major step back to me.
> To point 2):
> Here we are no longer talking about the languages but the VMs they run
> on. Those are constantly evolving. We need to decide explicitly at which
> ones we want to look. For example it could be clisp, but also SBCL.
> For Clojure it should be Suns JVM and the OpenJDK.
> Suns JVM for example still does not offer TCO. That is outdated. It is
> also outdated in other aspects, for example tagged numbers, which are
> working very well in SBCL.
> But things like HotSpot are years away for CL implementations. Also
> STMs are typically not available, no MVCC. The new Garbage First
> Collector has no equivalent in clisp or Lispworks.
> So while some CLs have good points here, the sheer amount of man hours
> that goes into Suns JVM or the OpenJDK are something that CL implementors
> can't compete with currently.
That is true. Unfortunately, this "sheer amount of man hours" is wasted
on a fundamentally broken programming model. I'm not impressed by that.
> To point 3):
> The lib situation for CL is not as bad as it used to be. But still, if I
> want to integrate SAP into my software I have no native drivers.
> NetBeans GUI builder is one of the most advanced available. Compare that
> with the one available in Lispworks.
> It's again the money --> man hours.
> With Terracotta there exists an excellent clustering solution. If a CL
> app does not scale the programmers will have to leave their domain and
> do need to program cluster code.
Same problem as above.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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 May 2, 2:16 pm, Pascal Costanza <····@p-cos.net> wrote:
> André Thieme wrote:
> > So while some CLs have good points here, the sheer amount of man hours
> > that goes into Suns JVM or the OpenJDK are something that CL implementors
> > can't compete with currently.
>
> That is true. Unfortunately, this "sheer amount of man hours" is wasted
> on a fundamentally broken programming model. I'm not impressed by that.
Well, I'm not impressed either on a programming landscape built upon C/
C++ but, hey!, here we are...
Pascal Costanza schrieb:
> Andr� Thieme wrote:
> There are enough people who think that a Lisp-2, or Lisp-n, is superior
> to a Lisp-1, among other reasons because they make macros more reliable.
>
> To me, whenever a new Lisp dialect comes out that chooses to go the
> Lisp-1 route, this seems like a major step back to me.
I think that is also about personal preference.
For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
pass functions around and call them.
In http://www.nhplace.com/kent/Papers/Technical-Issues.html Kent Pitman
argued:
�Probably a programmer who frequently passes functions as arguments or
who uses passed arguments functionally finds Lisp1 syntax easier to
read than Lisp2 syntax;�.
Also see point 11 in his list.
The point about reliability of macros is good. Clojure can not go around
all potential problems, but against some it protects us. Consider:
CL-USER> (defmacro foo (x &body body)
`(let ((y (1+ ,x)))
(print y)
,@body))
FOO
CL-USER> (defun bar (y)
(foo 20
(print y)))
BAR
CL-USER> (bar 100)
21
21
and see:
user> (defmacro foo [x & body]
`(let [y (inc ~x)]
(println y)
·@body))
#'user/foo
user> (defn bar [y]
(foo 20
(println y)))
Here I press <Enter> and immediately get an error:
java.lang.Exception: Can't let qualified name: user/y
To use a fresh gensymed symbol in Clojure I add a # after
the name of the var:
user> (defmacro foo [x & body]
`(let [y# (inc ~x)]
(println y#)
·@body))
Now that works:
user> (bar 100)
21
100
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 2, 2:44 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Pascal Costanza schrieb:
[...]
> > To me, whenever a new Lisp dialect comes out that chooses to go the
> > Lisp-1 route, this seems like a major step back to me.
> I think that is also about personal preference.
> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
> pass functions around and call them.
> Inhttp://www.nhplace.com/kent/Papers/Technical-Issues.htmlKent Pitman
> argued:
> “Probably a programmer who frequently passes functions as arguments or
> who uses passed arguments functionally finds Lisp1 syntax easier to
> read than Lisp2 syntax;”.
I frequently pass functions as arguments, in languages with one
namespace in addition to Common Lisp. I don't really find the omission
of FUNCALL (or its moral equivalent) makes code much easier to read in
the general case. If you're doing complicated things with the passed
parameters, then I think eliminating that syntactic noise is a win,
but in many other instances the emphasis added makes things more
readable, not less.
I do wish Common Lisp had somewhat stronger support for macros that
make things easier in more complicated situations. Being able to
define your own macros that work like LAMBDA (and thus can appear in
the car of evaluatable expressions, or after a #') would be very
helpful, IMO.
Cheers,
Pillsy
[...]
Pillsy schrieb:
> On May 2, 2:44 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>
>> Pascal Costanza schrieb:
> [...]
>>> To me, whenever a new Lisp dialect comes out that chooses to go the
>>> Lisp-1 route, this seems like a major step back to me.
>
>> I think that is also about personal preference.
>> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
>> pass functions around and call them.
>> Inhttp://www.nhplace.com/kent/Papers/Technical-Issues.htmlKent Pitman
>> argued:
>> �Probably a programmer who frequently passes functions as arguments or
>> who uses passed arguments functionally finds Lisp1 syntax easier to
>> read than Lisp2 syntax;�.
>
> I frequently pass functions as arguments, in languages with one
> namespace in addition to Common Lisp. I don't really find the omission
> of FUNCALL (or its moral equivalent) makes code much easier to read in
> the general case. If you're doing complicated things with the passed
> parameters, then I think eliminating that syntactic noise is a win,
> but in many other instances the emphasis added makes things more
> readable, not less.
I agree with the point, that without funcall the code does not become
in general *much easier* to read.
Although there are exceptions, such as the one that Kent Pitman lists:
-------------------------------------------------------------
In Lisp2, one can write the Y operator as
(DEFUN Y (F)
( (LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))
#'(LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))))
while in Lisp1, one can write
(DEFUN Y (F)
((LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))
(LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))))
-------------------------------------------------------------
Btw, in Clojure:
(defn y [f]
((fn [g] #((f (g g)) %))
(fn [g] #((f (g g)) %))))
So while in general I agree and say that Lisp-1 makes functional code
not much easier to read, I also can't say that Lisp-n does. In my
opinion Lisp-2 makes functional code harder to read. In Clojure one
will typically see more functional code. So for Clojure it makes
sense.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 7, 8:13 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Pillsy schrieb:
>
>
>
> > On May 2, 2:44 pm, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
>
> >> Pascal Costanza schrieb:
> > [...]
> >>> To me, whenever a new Lisp dialect comes out that chooses to go the
> >>> Lisp-1 route, this seems like a major step back to me.
>
> >> I think that is also about personal preference.
> >> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
> >> pass functions around and call them.
> >> Inhttp://www.nhplace.com/kent/Papers/Technical-Issues.htmlKentPitman
> >> argued:
> >> “Probably a programmer who frequently passes functions as arguments or
> >> who uses passed arguments functionally finds Lisp1 syntax easier to
> >> read than Lisp2 syntax;”.
>
> > I frequently pass functions as arguments, in languages with one
> > namespace in addition to Common Lisp. I don't really find the omission
> > of FUNCALL (or its moral equivalent) makes code much easier to read in
> > the general case. If you're doing complicated things with the passed
> > parameters, then I think eliminating that syntactic noise is a win,
> > but in many other instances the emphasis added makes things more
> > readable, not less.
>
> I agree with the point, that without funcall the code does not become
> in general *much easier* to read.
> Although there are exceptions, such as the one that Kent Pitman lists:
> -------------------------------------------------------------
> In Lisp2, one can write the Y operator as
> (DEFUN Y (F)
> ( (LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))
> #'(LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))))
>
> while in Lisp1, one can write
>
> (DEFUN Y (F)
> ((LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))
> (LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))))
> -------------------------------------------------------------
This can also be written in a Lisp-2
(def y (f)
((lambda (g) (lambda (h) ((f (g g)) h)))
(lambda (g) (lambda (h) ((f (g g)) h)))))
It cannot be written in Common Lisp. I'd wager (and I did before)
that you could still bend Common Lisp to do at least the follwing
(defun y (f)
((lambda (g) (lambda (h) ((funcall f (funcall g g)) h)))
(lambda (g) (lambda (h) ((funcall f (funcall g g)) h)))))
You could also remove the FUNCALLS completely with some hairy cost.
BTW. You do not need the #'.
> Btw, in Clojure:
> (defn y [f]
> ((fn [g] #((f (g g)) %))
> (fn [g] #((f (g g)) %))))
>
> So while in general I agree and say that Lisp-1 makes functional code
> not much easier to read, I also can't say that Lisp-n does. In my
> opinion Lisp-2 makes functional code harder to read. In Clojure one
> will typically see more functional code. So for Clojure it makes
> sense.
Ok. But the above is not nearly as clean as the Scheme version.
Cheers
--
Marco
Marco Antoniotti schrieb:
> On May 7, 8:13 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Pillsy schrieb:
>>
>>
>>
>>> On May 2, 2:44 pm, Andr� Thieme <address.good.until.
>>> ···········@justmail.de> wrote:
>>>> Pascal Costanza schrieb:
>>> [...]
>>>>> To me, whenever a new Lisp dialect comes out that chooses to go the
>>>>> Lisp-1 route, this seems like a major step back to me.
>>>> I think that is also about personal preference.
>>>> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
>>>> pass functions around and call them.
>>>> Inhttp://www.nhplace.com/kent/Papers/Technical-Issues.htmlKentPitman
>>>> argued:
>>>> �Probably a programmer who frequently passes functions as arguments or
>>>> who uses passed arguments functionally finds Lisp1 syntax easier to
>>>> read than Lisp2 syntax;�.
>>> I frequently pass functions as arguments, in languages with one
>>> namespace in addition to Common Lisp. I don't really find the omission
>>> of FUNCALL (or its moral equivalent) makes code much easier to read in
>>> the general case. If you're doing complicated things with the passed
>>> parameters, then I think eliminating that syntactic noise is a win,
>>> but in many other instances the emphasis added makes things more
>>> readable, not less.
>> I agree with the point, that without funcall the code does not become
>> in general *much easier* to read.
>> Although there are exceptions, such as the one that Kent Pitman lists:
>> -------------------------------------------------------------
>> In Lisp2, one can write the Y operator as
>> (DEFUN Y (F)
>> ( (LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))
>> #'(LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))))
>>
>> while in Lisp1, one can write
>>
>> (DEFUN Y (F)
>> ((LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))
>> (LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))))
>> -------------------------------------------------------------
>
> This can also be written in a Lisp-2
>
> (def y (f)
> ((lambda (g) (lambda (h) ((f (g g)) h)))
> (lambda (g) (lambda (h) ((f (g g)) h)))))
>
> It cannot be written in Common Lisp. I'd wager (and I did before)
> that you could still bend Common Lisp to do at least the follwing
>
> (defun y (f)
> ((lambda (g) (lambda (h) ((funcall f (funcall g g)) h)))
> (lambda (g) (lambda (h) ((funcall f (funcall g g)) h)))))
>
> You could also remove the FUNCALLS completely with some hairy cost.
> BTW. You do not need the #'.
They were on the website.
For the first 2-3 years I always said #'(lambda ...) *with* the #' just
because I found this to be more consistent. Later I changed my mind and
think: what use is the lambda macro if I never use it? :)
>
>> Btw, in Clojure:
>> (defn y [f]
>> ((fn [g] #((f (g g)) %))
>> (fn [g] #((f (g g)) %))))
>>
>> So while in general I agree and say that Lisp-1 makes functional code
>> not much easier to read, I also can't say that Lisp-n does. In my
>> opinion Lisp-2 makes functional code harder to read. In Clojure one
>> will typically see more functional code. So for Clojure it makes
>> sense.
>
> Ok. But the above is not nearly as clean as the Scheme version.
Where is the Scheme version? Did you mean the Lisp-1 version?
You could do it without the #(...) reader macro, by changing
#((f (g g)) %)) to (fn [h] ((f (g g)) h))
Clojure users however are trained to also read #(...) anan functions,
and I guess that others (than I) can also read my version above very
well, aside from the y combinator not being the most trivial function
one can imagine ;)
On May 7, 11:42 pm, Marcus Breiing <······@2009w18.mail.breiing.com>
wrote:
> * =?windows-1252?Q?Andr=E9_Thieme?=
>
> > in Lisp1, one can write
> > (DEFUN Y (F)
> > ((LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))
> > (LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))))
>
> Common Lisp with trivial macrology:
>
> (defun y (f)
> [(lambda (g) (lambda (h) [[f [g g]] h]))
> (lambda (g) (lambda (h) [[f [g g]] h]))])
>
> Note that this "Lisp-2" function's body is valid Scheme...
Beautiful. But you can even reduce the macros.
(defun y (f)
((lambda (g) (lambda (h) [[f [g g]] h))
(lambda (g) (lambda (h) [[f [g g]] h]))))
given that a lambda expression is the only non symbol allowed in the
operator position.
I am still not convinced that allowing arbitrary applications in the
operator position in CL should be restricted. Writing
((compose f g) 42)
should work.
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
On May 7, 6:42 pm, Marcus Breiing <······@2009w18.mail.breiing.com>
wrote:
> * =?windows-1252?Q?Andr=E9_Thieme?=
>
> > in Lisp1, one can write
> > (DEFUN Y (F)
> > ((LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))
> > (LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))))
>
> Common Lisp with trivial macrology:
>
> (defun y (f)
> [(lambda (g) (lambda (h) [[f [g g]] h]))
> (lambda (g) (lambda (h) [[f [g g]] h]))])
>
> Note that this "Lisp-2" function's body is valid Scheme...
Yeah, now besides having to write the macro, you have to remember
where to apply it.
On May 7, 2:13 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Although there are exceptions, such as the one that Kent Pitman lists:
> -------------------------------------------------------------
> In Lisp2, one can write the Y operator as
> (DEFUN Y (F)
> ( (LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))
> #'(LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))))
>
> while in Lisp1, one can write
>
> (DEFUN Y (F)
> ((LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))
> (LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))))
Probably the only time, though, that I've ever written the Y operator
is for class. In practice, when you need it, you'd write it a
different way. And, incidentally, when writing it that way, I'd
rather the Lisp2 notation. I don't disagree that the Lisp1 notation
is brief, but IMO brief != perspicuous. Which is not to say I didn't
like programming in TECO and that I don't know people who liked APL,
but that kind of elegance is also error-prone.
Lisp has been criticized even for doing (IF test consequent
alternative) rather than (IF test THEN consequent ELSE alternative)
because it's harder to detect errors. If you sese (IF x foo) it's
hard to realize the bug that the consequent was omitted and the
alternative was slid over. Extra words provide redundancy and allow
correction. They also attract focus and clarify local meaning.
Omitting them is very macho perhaps, but not always friendly to those
looking on.
I'm ok with you thinking otherwise. I just keep seeing my name next
to those other arguments. As I explained in a post yesterday, those
are things we listed for completeness, and because Gabriel was more
warm to them than I. But I don't consider those points to be the
compelling ones, which is why I argued for Lisp2 style for CL.
Incidentally, I don't begrudge Lisp1's their choices. People who
design languages need to make choices they're comfortable with and
then work through them. We did some very clever things with Lisp1
style in T (Yale Scheme) when designing the object system. But that
didn't make Lisp1 an intrinsic win. That was more the fact that with
ANY set of design choices, there are cool things you can do and you
might as well. CL has cool things you can do based on Lisp2, and
again why shouldn't it?
······@nhplace.com schrieb:
> On May 7, 2:13 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Although there are exceptions, such as the one that Kent Pitman lists:
>> -------------------------------------------------------------
>> In Lisp2, one can write the Y operator as
>> (DEFUN Y (F)
>> ( (LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))
>> #'(LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))))
>>
>> while in Lisp1, one can write
>>
>> (DEFUN Y (F)
>> ((LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))
>> (LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))))
>
Hi Kent, thanks for this post and your one before.
When I originally found the paper on your website in the past I saw that
R.G. was involved. Over the years I guess I forgot that he also was the
author, but just remembered that the paper is hosted on your website.
So I should mention R.G. in the places where I used your name.
Sorry for the confusion.
About my point it does not make a difference *who* the Lisp veteran was,
who wrote the examples.
Back in 2004 or 2005 I read that paper for the first time and first
thought that it would be mostly in favor of Lisp-2. But I still remember
that I was surprised that this article is in my opinion much more in
favour for Lisp-1.
> Probably the only time, though, that I've ever written the Y operator
> is for class. In practice, when you need it, you'd write it a
> different way. And, incidentally, when writing it that way, I'd
> rather the Lisp2 notation. I don't disagree that the Lisp1 notation
> is brief, but IMO brief != perspicuous. Which is not to say I didn't
> like programming in TECO and that I don't know people who liked APL,
> but that kind of elegance is also error-prone.
Yes. However, I also can see differences between APL and the Lisp-1
version. Lisp-1 is shorter and I think clearer. There is no need for
a lambda macro which allows people to omit the #' in front of a lambda,
if that #' really makes things clearer. The #' itself is also not needed
but still I see people using that reader macro.
Why do these macros exist?
If they don't improve the code then either they don't change it at all,
or those macros make the code worse. In both cases there is no reason
to ever say (lambda ...) instead of (function (lambda ...) ...).
It's more difficult for me to believe that someone prefers Lisp-n who
makes use of #' or even the lambda macro.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 8, 1:52 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ······@nhplace.com schrieb:
>
> > On May 7, 2:13 pm, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> Although there are exceptions, such as the one thatKentPitmanlists:
> >> -------------------------------------------------------------
> >> In Lisp2, one can write the Y operator as
> >> (DEFUN Y (F)
> >> ( (LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))
> >> #'(LAMBDA (G) #'(LAMBDA (H) (FUNCALL (FUNCALL F (FUNCALL G G)) H)))))
>
> >> while in Lisp1, one can write
>
> >> (DEFUN Y (F)
> >> ((LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))
> >> (LAMBDA (G) (LAMBDA (H) ((F (G G)) H)))))
>
> HiKent, thanks for this post and your one before.
> When I originally found the paper on your website in the past I saw that
> R.G. was involved. Over the years I guess I forgot that he also was the
> author, but just remembered that the paper is hosted on your website.
> So I should mention R.G. in the places where I used your name.
> Sorry for the confusion.
> About my point it does not make a difference *who* the Lisp veteran was,
> who wrote the examples.
>
> Back in 2004 or 2005 I read that paper for the first time and first
> thought that it would be mostly in favor of Lisp-2. But I still remember
> that I was surprised that this article is in my opinion much more in
> favour for Lisp-1.
>
> > Probably the only time, though, that I've ever written the Y operator
> > is for class. In practice, when you need it, you'd write it a
> > different way. And, incidentally, when writing it that way, I'd
> > rather the Lisp2 notation. I don't disagree that the Lisp1 notation
> > is brief, but IMO brief != perspicuous. Which is not to say I didn't
> > like programming in TECO and that I don't know people who liked APL,
> > but that kind of elegance is also error-prone.
>
> Yes. However, I also can see differences between APL and the Lisp-1
> version. Lisp-1 is shorter and I think clearer. There is no need for
> a lambda macro which allows people to omit the #' in front of a lambda,
> if that #' really makes things clearer. The #' itself is also not needed
> but still I see people using that reader macro.
> Why do these macros exist?
> If they don't improve the code then either they don't change it at all,
> or those macros make the code worse. In both cases there is no reason
> to ever say (lambda ...) instead of (function (lambda ...) ...).
> It's more difficult for me to believe that someone prefers Lisp-n who
> makes use of #' or even the lambda macro.
I write functions all the time and almost never write (lambda ...)
without a preceding #'. I do this by preference. I find it nicely
regular as a way of naming functions and I do not find it visually
disturbing.
To me, #' means "I'm about to name a function." I consider (lambda
(x) x) to be a "name" for an anonymous function, so it's a kind of
name, just like when someone asks you who owns an object, you can
either say "John" or "that guy over there". Bpth are noun phrases,
but each of a different kind. The thing after #' is a name. So #'foo
or #'(lambda (x) ...) are the two kinds of "names" for functions.
<······@nhplace.com> wrote:
+---------------
| Andr� Thieme <······························@justmail.de> wrote:
| > There is no need for a lambda macro which allows people to omit the
| > #' in front of a lambda, if that #' really makes things clearer.
| > The #' itself is also not needed but still I see people using that
| > reader macro. Why do these macros exist?
|
| I write functions all the time and almost never write (lambda ...)
| without a preceding #'. I do this by preference. I find it nicely
| regular as a way of naming functions and I do not find it visually
| disturbing.
|
| To me, #' means "I'm about to name a function." I consider (lambda
| (x) x) to be a "name" for an anonymous function, so it's a kind of
| name, just like when someone asks you who owns an object, you can
| either say "John" or "that guy over there". Bpth are noun phrases,
| but each of a different kind. The thing after #' is a name. So #'foo
| or #'(lambda (x) ...) are the two kinds of "names" for functions.
+---------------
I understand what Kent's saying here, but I would like to share
a different view [not "better", just different]: I also think of
FUNCTION or #' as "I'm about to name a function", which is precisely
why I *don't* use #' in front of LAMBDA!! Why is this? It's probably
because of my Scheme background, where capturing free variables in a
closure is a much more common coding style than in CL, and where it's
a little more obvious that typing (LAMBDA ...something...) is *not* so
much "naming" a function as *creating* one!!
That is, to me (LAMBDA ...something...) is an executable form [albeit
a special form] which returns a value, a new function which has closed
over its free variables with the current dynamic values of the lexically
visible bindings in the current environment. This doesn't seem like
"naming" to me so much as "creating", since the resulting closure you
get back is [potentially] *different* every time you execute the LAMBDA.
Contrast that with (FUNCTION FOO), which always gives you the *same*
[functional value of] FOO every time [modulo runtime redefinitions].
Yes, a LAMBDA form with no free variables is also a "constant" name,
which is why I don't argue with Kent's view that "naming" is the more
important aspect. I suspect [but will wait for him to confirm or deny]
that most of the LAMBDAs he writes don't depend on captured free variables.
But for me, who even in CL uses lots of "functions which generate functions"
[i.e., non-trivial closures], the reverse is true. The function-creating
role of LAMBDA is paramount, and the "naming" aspect is actually rather
unreliable, since different executions of the LAMBDA form produce different
results [not something I associate with being "the" name of something].
That's why I, for one, am *very* glad that the LAMBDA *macro* exists
in CL, so that I can use it -- *without* the #' or FUNCTION prefix --
to make it very clear when I'm generating a value [a closure] and not
"just" naming something static & anonymous. ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On May 11, 6:41 pm, ····@rpw3.org (Rob Warnock) wrote:
> <······@nhplace.com> wrote:
>
> +---------------
> | To me, #' means "I'm about to name a function." I consider (lambda
> | (x) x) to be a "name" for an anonymous function, so it's a kind of
> | name
> +---------------
>
> I understand what Kent's saying here, but I would like to share
> a different view [not "better", just different]: I also think of
> FUNCTION or #' as "I'm about to name a function", which is precisely
> why I *don't* use #' in front of LAMBDA!!
FWIW, I'm with Rob here. For highly functional code, "LAMBDA" is
already too long -- why add two more characters?
-- Scott
On May 12, 4:08 am, Scott Burson <········@gmail.com> wrote:
> On May 11, 6:41 pm, ····@rpw3.org (Rob Warnock) wrote:
>
> > <······@nhplace.com> wrote:
>
> > +---------------
> > | To me, #' means "I'm about to name a function." I consider (lambda
> > | (x) x) to be a "name" for an anonymous function, so it's a kind of
> > | name
> > +---------------
>
> > I understand what Kent's saying here, but I would like to share
> > a different view [not "better", just different]: I also think of
> > FUNCTION or #' as "I'm about to name a function", which is precisely
> > why I *don't* use #' in front of LAMBDA!!
>
> FWIW, I'm with Rob here. For highly functional code, "LAMBDA" is
> already too long -- why add two more characters?
1+
slobodan
>
> -- Scott
Slobodan Blazeski wrote:
> On May 12, 4:08 am, Scott Burson <········@gmail.com> wrote:
>> On May 11, 6:41 pm, ····@rpw3.org (Rob Warnock) wrote:
>>
>>> <······@nhplace.com> wrote:
>>> +---------------
>>> | To me, #' means "I'm about to name a function." I consider (lambda
>>> | (x) x) to be a "name" for an anonymous function, so it's a kind of
>>> | name
>>> +---------------
>>> I understand what Kent's saying here, but I would like to share
>>> a different view [not "better", just different]: I also think of
>>> FUNCTION or #' as "I'm about to name a function", which is precisely
>>> why I *don't* use #' in front of LAMBDA!!
>> FWIW, I'm with Rob here. For highly functional code, "LAMBDA" is
>> already too long -- why add two more characters?
>
> 1+
>
> slobodan
>
>> -- Scott
>
And after all Common Lisp is the language allowing this. (And for one
thing some other Lisp languages should have compiler-macros :)).
On May 11, 10:08 pm, Scott Burson <········@gmail.com> wrote:
> On May 11, 6:41 pm, ····@rpw3.org (Rob Warnock) wrote:
> ...
> FWIW, I'm with Rob here. For highly functional code, "LAMBDA" is
> already too long -- why add two more characters?
You're missing my point because this is the wrong question.
The question in an issue of personal respect in a pluralistic society
is never "why should I allow the other person to have it their way?"
Once you get to that, you're already on a path of coercion.
The question is, "Does the other person purport to have a legitimate
reason for wanting the right to engage a freedom, and is there a
compelling overriding reason why I cannot live with allowing that?"
So in the debate over alphabetic case translation, we worked really
hard to get close to allowing all points of view, and we fell short,
but we did what we could. It's slightly irresolvable (Duane, you're
welcome to chime in here if you want to--others please ignore this
parenthetical remark) to do the whole thing. But we tried.
In the case of LAMBDA, again, it's simply not recognized that there
are competing theories. One theory says "the car of a form is
evaluated." But to logically carry that through requires writing (#'f
x) not (f x) in a lisp 2, since you have to say that the car of a form
is feval'd not eval'd. If you say feval is allowed to evaluate other
forms, then you end up in a mess that is as powerful as eval but just
has a screwy syntax, and it's a short walk to requiring lisp1. But
that's not what lisp2 people want. Lisp1 people think "what else
could it mean?" because they can't see that leaving it undefined is
more regular in the minds of some, but that doesn't mean the lisp2
people have no point of view, it means the lisp1 people are not
respecting it.
Once you acknowledge that there are two legitimate points of view
here, it becomes easier to answer the question you pose: The two
characters are not required. You are instead asking, why ALLOW two
more characters? And the answer to that is "Because I want them."
And if your answer is "But I don't care what you want." then you're
seeing it from my point of view. If you're saying a language should
shift incompatibly every time there's a voting majority one one side
or the other of a line, you're going to have a big shifty ship right
at the middle line, like the US supreme court on a number of issues
these days. Hysteresis is good. And so making a change in another
language can make sense if the implementor of another language wants
to. Arc, Clojure, Scheme, etc. can make the decisions that are good
for them. But the reason #' is allowed in CL is because some of us
want to use it. It is not a relic. I prefer it. I like functions to
have this annotation so I can see them easily in code. There is
something special about functions and I like having that special
thing marked. I agree that in very rare situations the extra two
columns are a pain. But it's not often enough that I would personally
make the design choice on that basis. YMMV.
Honestly, I think it's a big step forward for pluralisms to honestly
assess the abstract question: "Is my opponent in this debate
rational?" "Is my opponent in the debate reaching a different
conclusion than me?" "Do I respect my debate oppponent's right to
have a different position?" "If my opponent has a different position
than mine, by what ethical theory will I resolve the conflict?"
I hope I've motivated why this is, philosophically, the wrong question.
On May 12, 11:29 am, ······@nhplace.com wrote:
> So in the debate over alphabetic case translation, we worked really
> hard to get close to allowing all points of view, and we fell short,
> but we did what we could. It's slightly irresolvable (Duane, you're
> welcome to chime in here if you want to--others please ignore this
> parenthetical remark) to do the whole thing. But we tried.
I have nothing to say about this yet :-)
Duane
On 12 Mag, 23:52, ·····@franz.com wrote:
> On May 12, 11:29 am, ······@nhplace.com wrote:
>
> > So in the debate over alphabetic case translation, we worked really
> > hard to get close to allowing all points of view, and we fell short,
> > but we did what we could. It's slightly irresolvable (Duane, you're
> > welcome to chime in here if you want to--others please ignore this
> > parenthetical remark) to do the whole thing. But we tried.
>
> I have nothing to say about this yet :-)
>
A lot was said about this in 2000 :)
http://groups.google.it/group/comp.lang.lisp/browse_frm/thread/bcbfd54a5aaac65d/386bbff08bb18159?lnk=gst&q=What+case+problem+is+Franz+trying+to+solve#386bbff08bb18159
I have never goptten back to this and I assume that meny
implementations have done something about it. But, since every
cockroach is beautiful to his mother's eye, I still like my proposal.
There's a CDR to be written.
Cheers
--
Marco
On May 13, 1:09 am, Marco Antoniotti <·······@gmail.com> wrote:
> On 12 Mag, 23:52, ·····@franz.com wrote:
>
> > On May 12, 11:29 am, ······@nhplace.com wrote:
>
> > > So in the debate over alphabetic case translation, we worked really
> > > hard to get close to allowing all points of view, and we fell short,
> > > but we did what we could. It's slightly irresolvable (Duane, you're
> > > welcome to chime in here if you want to--others please ignore this
> > > parenthetical remark) to do the whole thing. But we tried.
>
> > I have nothing to say about this yet :-)
>
> A lot was said about this in 2000 :)
Not by me :-)
> http://groups.google.it/group/comp.lang.lisp/browse_frm/thread/bcbfd5...
>
> I have never goptten back to this and I assume that meny
> implementations have done something about it. But, since every
> cockroach is beautiful to his mother's eye, I still like my proposal.
> There's a CDR to be written.
I didn't see your proposal in that thread - it is a long thread. So,
which cockroach is yours? :-)
Duane
On May 13, 7:39 pm, ·····@franz.com wrote:
> On May 13, 1:09 am, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On 12 Mag, 23:52, ·····@franz.com wrote:
>
> > > On May 12, 11:29 am, ······@nhplace.com wrote:
>
> > > > So in the debate over alphabetic case translation, we worked really
> > > > hard to get close to allowing all points of view, and we fell short,
> > > > but we did what we could. It's slightly irresolvable (Duane, you're
> > > > welcome to chime in here if you want to--others please ignore this
> > > > parenthetical remark) to do the whole thing. But we tried.
>
> > > I have nothing to say about this yet :-)
>
> > A lot was said about this in 2000 :)
>
> Not by me :-)
Yeah. It was mainly John Foderaro.
> >http://groups.google.it/group/comp.lang.lisp/browse_frm/thread/bcbfd5...
>
> > I have never goptten back to this and I assume that meny
> > implementations have done something about it. But, since every
> > cockroach is beautiful to his mother's eye, I still like my proposal.
> > There's a CDR to be written.
>
> I didn't see your proposal in that thread - it is a long thread. So,
> which cockroach is yours? :-)
It's in there. I'll extricate it and massage it. There are a few
warts in it, but I thinks it would save goat and cabbage (the goat or
the cabbage being Franz Modern mode; your choice) :)
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
On May 13, 7:39 pm, ·····@franz.com wrote:
> On May 13, 1:09 am, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On 12 Mag, 23:52, ·····@franz.com wrote:
>
> > > On May 12, 11:29 am, ······@nhplace.com wrote:
>
> > > > So in the debate over alphabetic case translation, we worked really
> > > > hard to get close to allowing all points of view, and we fell short,
> > > > but we did what we could. It's slightly irresolvable (Duane, you're
> > > > welcome to chime in here if you want to--others please ignore this
> > > > parenthetical remark) to do the whole thing. But we tried.
>
> > > I have nothing to say about this yet :-)
>
> > A lot was said about this in 2000 :)
>
> Not by me :-)
>
> >http://groups.google.it/group/comp.lang.lisp/browse_frm/thread/bcbfd5...
>
> > I have never goptten back to this and I assume that meny
> > implementations have done something about it. But, since every
> > cockroach is beautiful to his mother's eye, I still like my proposal.
> > There's a CDR to be written.
>
> I didn't see your proposal in that thread - it is a long thread. So,
> which cockroach is yours? :-)
Message 108. (At least in my Google listing).
Cheers
--
Marco
ELS 2008 www.european-lisp-symposium.org
> On May 12, 11:29 am, ······@nhplace.com wrote:
>> So in the debate over alphabetic case translation, we worked really
>> hard to get close to allowing all points of view, and we fell short,
>> but we did what we could. It's slightly irresolvable (Duane, you're
>> welcome to chime in here if you want to--others please ignore this
>> parenthetical remark) to do the whole thing. But we tried.
I feel free to comment on the parenthetical remark because the
instruction to ignore it was contained in the parenthetical remark. Now
had you nested the instruction....
hth, kt
On May 12, 11:29 am, ······@nhplace.com wrote:
> On May 11, 10:08 pm, Scott Burson <········@gmail.com> wrote:
>
> > On May 11, 6:41 pm, ····@rpw3.org (Rob Warnock) wrote:
> > ...
> > FWIW, I'm with Rob here. For highly functional code, "LAMBDA" is
> > already too long -- why add two more characters?
>
> But the reason #' is allowed in CL is because some of us
> want to use it.
Hi Kent,
Sorry, I must not have read far enough back in the thread. I never
meant to be voting to disallow the #' -- only saying that I am among
those who do not use it.
-- Scott
Scott Burson <········@gmail.com> wrote:
+---------------
| ······@nhplace.com wrote:
| > Scott Burson <········@gmail.com> wrote:
| > > ····@rpw3.org (Rob Warnock) wrote:
| > > ...
| > > FWIW, I'm with Rob here. �For highly functional code,
| > > "LAMBDA" is already too long -- why add two more characters?
| >
| > But the reason #' is allowed in CL is because some of us
| > want to use it.
|
| Hi Kent,
| Sorry, I must not have read far enough back in the thread. I never
| meant to be voting to disallow the #' -- only saying that I am among
| those who do not use it.
+---------------
And those who "agreed" with me by citing the length argument
["why add two more characters"] missed *my* point entirely!!
I, like Kent, *want* to use #' when I am *naming* a function --
yes, sometimes even an anonymous LAMBDA, in the case when there
are no free variables [since that feels like a "constant" function
to me]. My point, which the syntax quibbling seems to have missed
entirely, is that when a LAMBDA *is* capturing some free variables
into a closure, which value is then returned, then it feels [to me!]
less like a "name" and more like an "executable form", so I leave
off the #' to emphasize that aspect.
That's just my style of coding[1], and I'm glad I have the freedom to
choose. And I'm glad Kent has the freedom to choose *his* preferred
style, as well. And all you others, too! "All Hail King Mudball!"
-Rob
[1] And of course, I'm speaking here of only production code,
with the source stored in files. At the REPL, I allow myself
all manner of ugly shortcuts, including FN as an abbreviation
for LAMBDA and even the #$ readmacro (with $1, $2... as params)
discussed here at length before. But I *never* permit those
in code that others might have to maintain [which includes
a future *me*!]...
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Tue, 12 May 2009 11:29:44 -0700 (PDT), ······@nhplace.com wrote:
> The question is, "Does the other person purport to have a legitimate
> reason for wanting the right to engage a freedom" ...
They almost always purport legitimacy. The question is whether the
purportation is honest.
> ... "and is there a compelling overriding reason why I cannot live
> with allowing that?"
Generally the answer to that is "Yes!". The average person shares a
predilection for bloodthirsty avarism with hyenas. If you establish a
pattern of consideration and concession, many will perceive that as
weakness and try to take advantage.
A group of people may be united by a common goal - or more likely by
separate, mostly compatible goals - but it's pretty rare to put
together any sizable group of altruists willing to work for the common
good at great expense to themselves. The sad fact is that most people
have agendas that include others only by necessity or by happenstance.
George
Scott Burson <········@gmail.com> writes:
> On May 11, 6:41�pm, ····@rpw3.org (Rob Warnock) wrote:
>> <······@nhplace.com> wrote:
>>
>> +---------------
>> | To me, #' means "I'm about to name a function." �I consider (lambda
>> | (x) x) to be a "name" for an anonymous function, so it's a kind of
>> | name
>> +---------------
>>
>> I understand what Kent's saying here, but I would like to share
>> a different view [not "better", just different]: �I also think of
>> FUNCTION or #' as "I'm about to name a function", which is precisely
>> why I *don't* use #' in front of LAMBDA!!
>
> FWIW, I'm with Rob here. For highly functional code, "LAMBDA" is
> already too long -- why add two more characters?
I learned (and loved) APL before Lisp, and I think we ought to
use the lambda glyph. (This actually worked on the CADRs, too!)
On May 17, 3:54 pm, ······@news.dtpq.com (Christopher C. Stacy) wrote:
> I learned (and loved) APL before Lisp, and I think we ought to
> use the lambda glyph. (This actually worked on the CADRs, too!)
Yes, we really should see if we can get some benefit out of this
Unicode thing that so many people have worked so hard on. I haven't
tried at all. Can I write a lambda in XEmacs? Anyone know? (Wrong
forum, I know)
-- Scott
Scott Burson <········@gmail.com> writes:
> On May 17, 3:54�pm, ······@news.dtpq.com (Christopher C. Stacy) wrote:
>> I learned (and loved) APL before Lisp, and I think we ought to
>> use the lambda glyph. �(This actually worked on the CADRs, too!)
>
> Yes, we really should see if we can get some benefit out of this
> Unicode thing that so many people have worked so hard on. I haven't
> tried at all. Can I write a lambda in XEmacs? Anyone know? (Wrong
> forum, I know)
http://www.emacswiki.org/emacs/pretty-mode.el
-T.
On May 11, 9:41 pm, ····@rpw3.org (Rob Warnock) wrote:
> <······@nhplace.com> wrote:
> ...
> | To me, #' means "I'm about to name a function." I consider (lambda
> | (x) x) to be a "name" for an anonymous function, so it's a kind of
> | name, just like when someone asks you who owns an object, you can
> | either say "John" or "that guy over there". Bpth are noun phrases,
> | but each of a different kind. The thing after #' is a name. So #'foo
> | or #'(lambda (x) ...) are the two kinds of "names" for functions.
> +---------------
>
> I understand what Kent's saying here, but I would like to share
> a different view [not "better", just different]: I also think of
> FUNCTION or #' as "I'm about to name a function", which is precisely
> why I *don't* use #' in front of LAMBDA!! Why is this? It's probably
> because of my Scheme background, where capturing free variables in a
> closure is a much more common coding style than in CL, and where it's
> a little more obvious that typing (LAMBDA ...something...) is *not* so
> much "naming" a function as *creating* one!!
>
> That is, to me (LAMBDA ...something...) is an executable form [albeit
> a special form] which returns a value, a new function which has closed
> over its free variables with the current dynamic values of the lexically
> visible bindings in the current environment. This doesn't seem like
> "naming" to me so much as "creating", since the resulting closure you
> get back is [potentially] *different* every time you execute the LAMBDA.
> Contrast that with (FUNCTION FOO), which always gives you the *same*
> [functional value of] FOO every time [modulo runtime redefinitions].
>
> Yes, a LAMBDA form with no free variables is also a "constant" name,
> which is why I don't argue with Kent's view that "naming" is the more
> important aspect. I suspect [but will wait for him to confirm or deny]
> that most of the LAMBDAs he writes don't depend on captured free variables.
> But for me, who even in CL uses lots of "functions which generate functions"
> [i.e., non-trivial closures], the reverse is true. The function-creating
> role of LAMBDA is paramount, and the "naming" aspect is actually rather
> unreliable, since different executions of the LAMBDA form produce different
> results [not something I associate with being "the" name of something].
>
> That's why I, for one, am *very* glad that the LAMBDA *macro* exists
> in CL, so that I can use it -- *without* the #' or FUNCTION prefix --
> to make it very clear when I'm generating a value [a closure] and not
> "just" naming something static & anonymous. ;-} ;-}
But you are not, in point of fact, creating a function. #'(lambda (x)
x) will not cons anything in most implementations. It's permitted to
cons, but not required to, and most implementations will return a
constant object because no closure is required. It is therefore the
moral equivalent of the passive mode in English speech. "A function
will be returned" without acknowledging who makes the function.
The lambda macro exists because of only one reason: It's a pain in the
neck to shadow LAMBDA. When I wrote my ISLISP emulator, long ago
(1992, I believe, or maybe early 1993, not that it matters, but it was
just before one of the public review periods of the dpANS), I needed
to redefine LAMBDA in order to define the "obvious" macro, and it
seemed the path of least resistance to instead just define the same
macro as many wanted. It wasn't an exercise in aesthetic, it was an
exercise in accommodation. There was actual objection from people who
said it would confuse people into thinking the macro was primitive and
the keyword that works with function was an aberration, and we're
seeing that objection to have teeth in this very conversation.
Paul Robertson, by the way, author of what became Symbolics CLOE (a
delivery lisp for the 386 from Symbolics), remarked to me once that it
was a design error in Lisp that there were not two operators for what
Lisp calls one. That is [I'll number them here, though he didn't]
there should be a LAMBDA1 that never creates closures and can be used
reliably to know one is talking about a non-consing reference to a
function and will err if it has a free variable that would need
closing over and a LAMBDA2 that permits [though for generality reasons
in degenerate cases probably doesn't require] closure creation. Had
there been, my answer in the prior paragraphs might be different in
subtle ways. [Perhaps you're saying you use #'(lambda ...) for
lambdas of the first kind and (lambda ...) for lambdas of the second
kind--I'm not sure.]
On 12 maio, 15:18, ······@nhplace.com wrote:
> But you are not, in point of fact, creating a function. #'(lambda (x)
> x) will not cons anything in most implementations. It's permitted to
> cons, but not required to, and most implementations will return a
> constant object because no closure is required. It is therefore the
> moral equivalent of the passive mode in English speech. "A function
> will be returned" without acknowledging who makes the function.
>
Hum, interesting:
··········@gugamilare-desktop:~$ clisp
[...]
[1]> (defun foo ()
(lambda (x) x))
FOO
[2]> (eq (foo) (foo))
NIL
[3]> (compile 'foo)
FOO ;
NIL ;
NIL
[4]> (eq (foo) (foo))
T
gugamilare <··········@gmail.com> writes:
> On 12 maio, 15:18, ······@nhplace.com wrote:
> > But you are not, in point of fact, creating a function. ��#'(lambda (x)
> > x) will not cons anything in most implementations. ��It's permitted to
> > cons, but not required to, and most implementations will return a
> > constant object because no closure is required. ��It is therefore the
> > moral equivalent of the passive mode in English speech. ��"A function
> > will be returned" without acknowledging who makes the function.
> >
> Hum, interesting:
>
> ··········@gugamilare-desktop:~$ clisp
> [...]
> [1]> (defun foo ()
> (lambda (x) x))
> FOO
> [2]> (eq (foo) (foo))
> NIL
> [3]> (compile 'foo)
> FOO ;
> NIL ;
> NIL
> [4]> (eq (foo) (foo))
> T
In Allegro CL:
CL-USER> CL-USER> (defun foo ()
(lambda (x) x))
FOO
CL-USER> (eq (foo) (foo))
NIL
CL-USER> (compile 'foo)
FOO
NIL
NIL
CL-USER> (eq (foo) (foo))
T
In SBCL:
* (defun foo ()
(lambda (x) x))
FOO
* (eq (foo) (foo))
T
* (compile 'foo)
FOO
NIL
NIL
* (eq (foo) (foo))
T
*
--
Thomas A. Russ, USC/Information Sciences Institute
Kent Pitman <······@nhplace.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > That is, to me (LAMBDA ...something...) is an executable form [albeit
| > a special form] which returns a value, a new function which has closed
| > over its free variables with the current dynamic values of the lexically
| > visible bindings in the current environment. This doesn't seem like
| > "naming" to me so much as "creating", since the resulting closure you
| > get back is [potentially] *different* every time you execute the LAMBDA.
| > Contrast that with (FUNCTION FOO), which always gives you the *same*
| > [functional value of] FOO every time [modulo runtime redefinitions].
| >
| > Yes, a LAMBDA form with no free variables is also a "constant" name,
| > which is why I don't argue with Kent's view that "naming" is the more
| > important aspect. I suspect [but will wait for him to confirm or deny]
| > that most of the LAMBDAs he writes don't depend on captured free
| > variables. But for me, who even in CL uses lots of "functions which
| > generate functions" [i.e., non-trivial closures], the reverse is true.
...
| > That's why I, for one, am *very* glad that the LAMBDA *macro* exists
| > in CL, so that I can use it -- *without* the #' or FUNCTION prefix --
| > to make it very clear when I'm generating a value [a closure] and not
| > "just" naming something static & anonymous. ;-} ;-}
|
| But you are not, in point of fact, creating a function. #'(lambda (x) x)
| will not cons anything in most implementations. It's permitted to cons,
| but not required to, and most implementations will return a constant
| object because no closure is required.
+---------------
Of course not. But (LAMBDA (X) (+ X Y)) *will* cons, at least in those
cases where the closure value escapes the current lexical contour.
[If it doesn't escape, then, yes, most implementations will rewrite
the application to a LET binding.]
+---------------
| [Perhaps you're saying you use #'(lambda ...) for lambdas of the first
| kind and (lambda ...) for lambdas of the second kind--I'm not sure.]
+---------------
Bingo. If it doesn't capture any free variables, then it's a "constant"
(or equivalent to one), and #' can be used to "name" it without confusion.
But if it *does* capture free variables, then it's an executable form
producing a value and should look like such.
And since I originally came to CL from the Scheme world[1], I had gotten
into the habit of using LAMBDAs of the second kind, and still tend to
use them in CL more frequently than I see them in other people's CL code.
-Rob
p.s. Where incremental currying by closing over this or that
is *very* common! Nesting LAMBDAs two or three deep is frequent,
and four is not unknown [though five or more is rare].
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
······@nhplace.com writes:
> Paul Robertson, by the way, author of what became Symbolics CLOE (a
> delivery lisp for the 386 from Symbolics), remarked to me once that it
> was a design error in Lisp that there were not two operators for what
> Lisp calls one. That is [I'll number them here, though he didn't]
> there should be a LAMBDA1 that never creates closures and can be used
> reliably to know one is talking about a non-consing reference to a
> function and will err if it has a free variable that would need
> closing over and a LAMBDA2 that permits [though for generality reasons
> in degenerate cases probably doesn't require] closure creation. Had
> there been, my answer in the prior paragraphs might be different in
> subtle ways. [Perhaps you're saying you use #'(lambda ...) for
> lambdas of the first kind and (lambda ...) for lambdas of the second
> kind--I'm not sure.]
However, it's rare a lambda that has no free-something.
That is, in Scheme, all non trivial(*) lambda will refer functions that
are to be considered like free variables.
In Common Lisp, we could consider the references to the functions to
be also free references, even if in the function name space. Consider:
(flet ((f (x) (+ x 1)))
(let ((y 42))
(lambda (z) (+ (f z) y))))
Here we have to three free references:
- one to the variable y,
- one to the function f,
- one to the function + !
There may be some provisions in CL (and even in scheme) to allow
implementations to optimize out the global function references, but
this is just that, an optimization. I think that conceptually, all
lambdas will be closures.
(*) this is a definition.
(lambda (x) x) is trivial. (lambda (x) (1+ x)) is not trivial.
--
__Pascal Bourguignon__
On 2009-05-12, Rob Warnock <····@rpw3.org> wrote:
><······@nhplace.com> wrote:
> +---------------
>| André Thieme <······························@justmail.de> wrote:
>| > There is no need for a lambda macro which allows people to omit the
>| > #' in front of a lambda, if that #' really makes things clearer.
>| > The #' itself is also not needed but still I see people using that
>| > reader macro. Why do these macros exist?
>|
>| I write functions all the time and almost never write (lambda ...)
>| without a preceding #'. I do this by preference. I find it nicely
>| regular as a way of naming functions and I do not find it visually
>| disturbing.
>|
>| To me, #' means "I'm about to name a function." I consider (lambda
>| (x) x) to be a "name" for an anonymous function, so it's a kind of
>| name, just like when someone asks you who owns an object, you can
>| either say "John" or "that guy over there". Bpth are noun phrases,
>| but each of a different kind. The thing after #' is a name. So #'foo
>| or #'(lambda (x) ...) are the two kinds of "names" for functions.
> +---------------
>
> I understand what Kent's saying here, but I would like to share
> a different view [not "better", just different]: I also think of
> FUNCTION or #' as "I'm about to name a function", which is precisely
> why I *don't* use #' in front of LAMBDA!! Why is this? It's probably
> because of my Scheme background, where capturing free variables in a
> closure is a much more common coding style than in CL, and where it's
> a little more obvious that typing (LAMBDA ...something...) is *not* so
> much "naming" a function as *creating* one!!
There is also the view that in functional programming, you aren't creating
anything. The program plus its input simply denote that which is computed.
A lambda which contains free variables that capture lexicals also
just dentoes.
Creating objects and returning values is an implementation view.
> That is, to me (LAMBDA ...something...) is an executable form [albeit
> a special form] which returns a value, a new function which has closed
> over its free variables with the current dynamic values of the lexically
> visible bindings in the current environment.
Likewise, there is the view that #'(lambda ...) is an executable form
for creating a function; a syntactic sugar for the FUNCTION operator
whose job it is to manufacture functions out of lambda expressions.
> This doesn't seem like
> "naming" to me so much as "creating", since the resulting closure you
> get back is [potentially] *different* every time you execute the LAMBDA.
> Contrast that with (FUNCTION FOO), which always gives you the *same*
> [functional value of] FOO every time [modulo runtime redefinitions].
Modulo compile-time redefinitions too.
(flet (foo (...) ...) (function foo))
The form #'foo contains, guess what, a free reference which
captures a lexical binding.
And of course the lexical function FOO can itself capture variables,
and so (function foo) may have to produce a different object on different
invocations, exactly like (function (lambda ...)) when the lambda
captures variables.
Your argument has bit the bag here, sorry. :)
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| Rob Warnock <····@rpw3.org> wrote:
| > That is, to me (LAMBDA ...something...) is an executable form [albeit
| > a special form] which returns a value, a new function which has closed
| > over its free variables with the current dynamic values of the lexically
| > visible bindings in the current environment.
|
| Likewise, there is the view that #'(lambda ...) is an executable form
| for creating a function; a syntactic sugar for the FUNCTION operator
| whose job it is to manufacture functions out of lambda expressions.
+---------------
That's correct as far as it goes [but see below]. There is still, IMHO,
value in distinguishing between #'(LAMBDA ...) -- simply naming one --
and (LAMBDA ...) -- actually executing it and returning a new value.
+---------------
| > This doesn't seem like
| > "naming" to me so much as "creating", since the resulting closure you
| > get back is [potentially] *different* every time you execute the LAMBDA.
| > Contrast that with (FUNCTION FOO), which always gives you the *same*
| > [functional value of] FOO every time [modulo runtime redefinitions].
|
| Modulo compile-time redefinitions too.
|
| (flet (foo (...) ...) (function foo))
|
| The form #'foo contains, guess what, a free reference which
| captures a lexical binding.
+---------------
You're confusing closure-creation time with closure-reference time.
In your example, closure-creation time is when the FLET binding occurs.
*That's* when the underlying (implicit here) LAMBDA was *executed*.
All subsequent mentions of #'FOO or (FUNCTION FOO) are simply *referencing*
that already-created closure.
+---------------
| And of course the lexical function FOO can itself capture variables,
| and so (function foo) may have to produce a different object on different
| invocations, exactly like (function (lambda ...)) when the lambda
| captures variables.
|
| Your argument has bit the bag here, sorry. :)
+---------------
Again, you're confusing closure-creation time with closure-reference
time. (FUNCTION FOO) will never capture a *new* free variable reference
[it already had it chance, once when it was FLET-bound], and will never
produce a *different* value, whereas (FUNCTION (LAMBDA (Y) (+ X Y)))
will capture a "new" X each time it's executed, and will return a new,
different closure for each such execution.
Let's back up a step: Whether or not one writes (LAMBDA ...) or
#'(LAMBDA ...) or (FUNCTION (LAMBDA ...)) is really irrelevant
to the semantics. The value that (FUNCTION FOO) produces -- say,
when one does (SETQ BAR (FUNCTION FOO)), which definitely *does*
produce a value!! -- will be "the same" wherever one evaluates it
[within the scope of the binding of #'FOO]. Whereas the closure value
that (FUNCTION (LAMBDA ...)) produces might have captured an entirely
different value each time it is executed. So in that sense (FUNCTION FOO)
is more of a "constant name" and (FUNCTION (LAMBDA ...)) is more of an
"executable form"... *when* it's closing over free variables. When it's
not, then (FUNCTION (LAMBDA ...)) is "just a name" like (FUNCTION FOO).
Given that, all I'm saying is that I prefer to make that distinction
visible in my code by writing #'(LAMBDA ...) when I'm just "naming"
an anonymous function [with no free variables] and by writing
(LAMBDA ...) when I'm "executing" it to capture free variables
and produce a closure value [even though technically there is no
difference under the hood -- either form could be used in either place].
But YMMV...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On 2009-05-13, Rob Warnock <····@rpw3.org> wrote:
> Kaz Kylheku <········@gmail.com> wrote:
> +---------------
>| Rob Warnock <····@rpw3.org> wrote:
>| > That is, to me (LAMBDA ...something...) is an executable form [albeit
>| > a special form] which returns a value, a new function which has closed
>| > over its free variables with the current dynamic values of the lexically
>| > visible bindings in the current environment.
>|
>| Likewise, there is the view that #'(lambda ...) is an executable form
>| for creating a function; a syntactic sugar for the FUNCTION operator
>| whose job it is to manufacture functions out of lambda expressions.
> +---------------
>
> That's correct as far as it goes [but see below]. There is still, IMHO,
> value in distinguishing between #'(LAMBDA ...) -- simply naming one --
> and (LAMBDA ...) -- actually executing it and returning a new value.
>
> +---------------
>| > This doesn't seem like
>| > "naming" to me so much as "creating", since the resulting closure you
>| > get back is [potentially] *different* every time you execute the LAMBDA.
>| > Contrast that with (FUNCTION FOO), which always gives you the *same*
>| > [functional value of] FOO every time [modulo runtime redefinitions].
>|
>| Modulo compile-time redefinitions too.
>|
>| (flet (foo (...) ...) (function foo))
>|
>| The form #'foo contains, guess what, a free reference which
>| captures a lexical binding.
> +---------------
>
> You're confusing closure-creation time with closure-reference time.
There are no such well-defined times. It could be that the closure is in fact
instantiated at the site where (function foo) is compiled.
Remember, in functional programming, reference /is/ construction. An object
need not exist if it is never used. The program simply denotes the object
that it computes.
If the compiler can analyze deeply enough, it can just replace an entire
program with the object which that program computes, so that none of the
closures implicit in that program ever exist at all.
Lisp may not be a functional language with non-strict semantics, but certain
common optimization principles apply, nevertheless.
> In your example, closure-creation time is when the FLET binding occurs.
This is not necessarily so. At the time the FLET binding occurs, there is not
necessarily any closure, just a local function is given a name.
The lexical function binding between FOO and the function it denotes need
not exist until the first reference to FOO to retrieve that binding.
If the the closure of such a function is never taken with FUNCTION, then a
closure never needs to be constructed.
It's only because we applied the FUNCTION operator and returned the
value that the closure needs to exist, and the compiler must behave
accordingly.
The closure construction has to do with that operator. No operator, no closure.
(Except perhaps in a badly optimized implementation which makes unnecessary
closures).
FUNCTION is inherently a function (and thus closure-making) operator. Of course
it pulls cached closures from symbol bindings when it makes sense to do that.
> *That's* when the underlying (implicit here) LAMBDA was *executed*.
> All subsequent mentions of #'FOO or (FUNCTION FOO) are simply *referencing*
> that already-created closure.
It could be that there is a hidden cache variable which holds the closure. The
first (function foo) would see that the variable is nil, construct the closure,
and then store it in that variable. Subsequent evaluations of (function foo)
would just use that value to avoid consing a new closure.
On May 11, 9:41 pm, ····@rpw3.org (Rob Warnock) wrote:
> Yes, a LAMBDA form with no free variables is also a "constant" name,
> which is why I don't argue withKent'sview that "naming" is the more
> important aspect. I suspect [but will wait for him to confirm or deny]
> that most of the LAMBDAs he writes don't depend on captured free variables.
> But for me, who even in CL uses lots of "functions which generate functions"
> [i.e., non-trivial closures], the reverse is true. The function-creating
> role of LAMBDA is paramount, and the "naming" aspect is actually rather
> unreliable, since different executions of the LAMBDA form produce different
> results [not something I associate with being "the" name of something].
>
> That's why I, for one, am *very* glad that the LAMBDA *macro* exists
> in CL, so that I can use it -- *without* the #' or FUNCTION prefix --
> to make it very clear when I'm generating a value [a closure] and not
> "just" naming something static & anonymous. ;-} ;-}
Sorry to disappoint ya, Rob. I understand the distinction you're
making but I wouldn't personally want to make it in the way you
suggest.
The problem is that I like the #' as a way of saying "there is
syntactically something other than function calling going on" to draw
my attention to the fact that there's a gigantic difference between
(lambda (x) x)
and
(1ambda (x) x)
just as an example. Seeing the #' reminds me that a function is being
talked about. And the function is every bit as much a function
whether it captures or does not.
If I were going to cleave my use of syntax along the axis you
describe, I'd want the "calling attention" thing to be calling
attention to the capture case, not to the non-capture case, so I'd
want to write (lambda (x) x) but #'(lambda (x) y), which is exactly
the opposite of what you get if you decide to claim that #'(lambda (x)
x) names a static thing and (lambda (x) y) names a dynamicaly created
thing. Hence I think this distinction is not a good one.
I therefore always use #'(lambda ...) regardless of which form I
mean. (Although I do have some macro support I tend to use instead
which is orthogonal to this, as all macro discussion is based on user-
defined syntax, not system syntax.)
Well, I say "therefore" as if my use of #' was a consequence of this.
But I really mean "I therefore don't further specialize my use of my
chosen notation in this way".
In fact, I just keep having to repeat it because I think people can't
believe it's true, but I just like seeing the #' before a lambda. It
reassures me that the compiler will understand it. Maybe it's just
that I lived through a time when we all wrote '(lambda ...) and it was
more haphazard that compilers didn't process this right all the time,
and so writing #' was the way of saying, "No, really, use the
functional semantics. Don't risk quoting the thing and having eval
called later." I can't say what it is that made my mind like the #'.
But although others were not raised with what nowadays probably seem
irrational fears, and perhaps therefore leap all too quickly to think
that this means that it's one of those legacy desires, I emphasize
this: What it REALLY shows is that the mind is perfectly capable of
accepting either and that it's probably more of a trained thing.
It bothers me not as much to have people advocate (lambda ...) as a
notation to use as to have them anti-advocating using #'(lambda ...).
The former is the mere stating of a preference. Everyone has
preferences. I tolerate those of others and expect them to tolerate
mine. The latter is the stating of a deathwish for others'
preferences. It relegates the opinions of some to second class
citizenship and diminishes the pluralistic society. It's my right to
think #'(...) looks PREFERRABLE that I'm trying to defend. I'm not
trying to say others have to think it. But when discussions stop
behaving like as if I don't exist or my preference is not valid, I'll
stop whining endlessly about this.
But yes, Rob, I realize you're not trying to do that specific thing.
You're just taking advantage of a situation where there are two
notations to add extra meaning. People do this with LET and LET* for
example, preferring one or the other as the default. (Actually,
ironically, most people prefer LET unless LET* is specifically needed,
I think because it has the nicer name, and as far as I know only Dick
Waters uses LET* unless LET is specifically needed. Yet his reason, in
spite of the odd notation, is more technically compelling: If I'm
stating it right (and I'm always nervous speaking for another), he
claims that LET* is more easily implemented and that LET requires
extra work, so users should prefer not to use the special notation LET
unless they mean to invoke its additional power.
Andr� Thieme <······························@justmail.de> writes:
> Pascal Costanza schrieb:
>> Andr� Thieme wrote:
>
>> There are enough people who think that a Lisp-2, or Lisp-n, is
>> superior to a Lisp-1, among other reasons because they make macros
>> more reliable.
>>
>> To me, whenever a new Lisp dialect comes out that chooses to go the
>> Lisp-1 route, this seems like a major step back to me.
>
> I think that is also about personal preference.
Yet you claimed that it makes Common Lisp objectively "out of
date". Are you trolling or just not very fond of thinking?
Bj�rn Lindberg
Bj�rn Lindberg schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>
>> Pascal Costanza schrieb:
>>> Andr� Thieme wrote:
>>> There are enough people who think that a Lisp-2, or Lisp-n, is
>>> superior to a Lisp-1, among other reasons because they make macros
>>> more reliable.
>>>
>>> To me, whenever a new Lisp dialect comes out that chooses to go the
>>> Lisp-1 route, this seems like a major step back to me.
>> I think that is also about personal preference.
>
> Yet you claimed that it makes Common Lisp objectively "out of
> date". Are you trolling or just not very fond of thinking?
Ah, the old strategy of insulting the discussion partner, instead of
accepting him as okay.
Anyway: I listed three sources in which CL may not be modern. For the
language itself I criticize the absence of explicit threading mechanisms.
And I gave another indicator: if the HyperSpec would look different if
it were written today (and I don't mean just a few minor changes), then
also that is an indicator for CL not being modern.
Now one of the guys who was involved in defining what CL should be says
that they did stupid things to CL, and would not do it today.
This is at least one change a CL veteran mentioned. If you regard it as
minor or not is an opinion. In one of his papers Kent Pitman writes:
�Some argue that the Lisp1 form is easier to read because it is more
concise.�
and
�Probably a programmer who frequently passes functions as arguments or
who uses passed arguments functionally finds Lisp1 syntax easier to
read than Lisp2 syntax;�
I agree, but I can also accept the opinion of people like Pascal, who
prefer Lisp-n. My opinion is different.
> Bj�rn Lindberg
I hope in the future I can read postings of you where you don't
question the intellectual integrity of other discussion partners.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Andr� Thieme <······························@justmail.de> writes:
> Bj�rn Lindberg schrieb:
>> Andr� Thieme <······························@justmail.de> writes:
>>
>>> Pascal Costanza schrieb:
>>>> Andr� Thieme wrote:
>>>> There are enough people who think that a Lisp-2, or Lisp-n, is
>>>> superior to a Lisp-1, among other reasons because they make macros
>>>> more reliable.
>>>>
>>>> To me, whenever a new Lisp dialect comes out that chooses to go the
>>>> Lisp-1 route, this seems like a major step back to me.
>>> I think that is also about personal preference.
>>
>> Yet you claimed that it makes Common Lisp objectively "out of
>> date". Are you trolling or just not very fond of thinking?
>
> Ah, the old strategy of insulting the discussion partner, instead of
> accepting him as okay.
>
> Anyway: I listed three sources in which CL may not be modern. For the
> language itself I criticize the absence of explicit threading mechanisms.
> And I gave another indicator: if the HyperSpec would look different if
> it were written today (and I don't mean just a few minor changes), then
> also that is an indicator for CL not being modern.
> Now one of the guys who was involved in defining what CL should be says
> that they did stupid things to CL, and would not do it today.
> This is at least one change a CL veteran mentioned. If you regard it as
> minor or not is an opinion. In one of his papers Kent Pitman writes:
> �Some argue that the Lisp1 form is easier to read because it is more
> concise.�
> and
> �Probably a programmer who frequently passes functions as arguments or
> who uses passed arguments functionally finds Lisp1 syntax easier to
> read than Lisp2 syntax;�
>
> I agree, but I can also accept the opinion of people like Pascal, who
> prefer Lisp-n. My opinion is different.
You asserted that the lisp-2-ness of Common Lisp makes it unmodern in
a thread started by someone inquiring about which Lisp to use, in
order to downplay CL in favour of your language of choice. When
challenged on this point, you quickly retreated to the view that
lisp-1/lisp-2 is a matter of personal preference. Such a view cannot
be used to support your initial assertion, making the latter
dishonest. Seeing your behaviour as you "not thinking" is the _nicer_
interpretation of those possible.
> I hope in the future I can read postings of you where you don't
> question the intellectual integrity of other discussion partners.
I hope in the future that you keep your language advocacy honest,
because I have certainly seen informative posts from you on that topic
before.
Bj�rn Lindberg
Bj�rn Lindberg schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>
>> Bj�rn Lindberg schrieb:
>>> Andr� Thieme <······························@justmail.de> writes:
>>>
>>>> Pascal Costanza schrieb:
>>>>> Andr� Thieme wrote:
>>>>> There are enough people who think that a Lisp-2, or Lisp-n, is
>>>>> superior to a Lisp-1, among other reasons because they make macros
>>>>> more reliable.
>>>>>
>>>>> To me, whenever a new Lisp dialect comes out that chooses to go the
>>>>> Lisp-1 route, this seems like a major step back to me.
>>>> I think that is also about personal preference.
>>> Yet you claimed that it makes Common Lisp objectively "out of
>>> date". Are you trolling or just not very fond of thinking?
>> Ah, the old strategy of insulting the discussion partner, instead of
>> accepting him as okay.
>>
>> Anyway: I listed three sources in which CL may not be modern. For the
>> language itself I criticize the absence of explicit threading mechanisms.
>> And I gave another indicator: if the HyperSpec would look different if
>> it were written today (and I don't mean just a few minor changes), then
>> also that is an indicator for CL not being modern.
>> Now one of the guys who was involved in defining what CL should be says
>> that they did stupid things to CL, and would not do it today.
>> This is at least one change a CL veteran mentioned. If you regard it as
>> minor or not is an opinion. In one of his papers Kent Pitman writes:
>> �Some argue that the Lisp1 form is easier to read because it is more
>> concise.�
>> and
>> �Probably a programmer who frequently passes functions as arguments or
>> who uses passed arguments functionally finds Lisp1 syntax easier to
>> read than Lisp2 syntax;�
>>
>> I agree, but I can also accept the opinion of people like Pascal, who
>> prefer Lisp-n. My opinion is different.
>
> You asserted that the lisp-2-ness of Common Lisp makes it unmodern in
> a thread started by someone inquiring about which Lisp to use, in
> order to downplay CL in favour of your language of choice. When
> challenged on this point, you quickly retreated to the view that
> lisp-1/lisp-2 is a matter of personal preference. Such a view cannot
> be used to support your initial assertion, making the latter
> dishonest. Seeing your behaviour as you "not thinking" is the _nicer_
> interpretation of those possible.
I probably did not make this point clear enough in my original posting.
My own opinion is that Lisp-1 is more concise and clearer the more a
functional style is used in a program. While this is still more neutral
I also prefer Lisp-1 if a program is not predominantly written in
functional style.
In my posting before I wanted to make this point:
I don't see that the CL standard/language is still modern, and I gave
two main arguments:
I) no explicit support for threading structures in the language
(only in implementations, but I was talking in point 1. in my original
posting about the language, and only later about implementations)
II) the language standard would look different if it were written today.
Those modifications are not just simple details.
To support point II) I gave one example. A lisp veteran who was involved
in defining what CL is/should be explained that today he sees the past
efforts in making CL a Lisp-n as very unfortunate. So, there I got a
supportive statement. What the message itself was about is not so
important, also not if that is the strongest point why the HS needs a
change. What matters here is *that* there are (not only minor) things
that would need a change/addition.
I should have chosen another example, which sounds about as clear as
the issue with the concurrency support.
>> I hope in the future I can read postings of you where you don't
>> question the intellectual integrity of other discussion partners.
>
> I hope in the future that you keep your language advocacy honest,
> because I have certainly seen informative posts from you on that topic
> before.
My goal is to be honest, and while I am aware that I may not be neutral
in that regard: I find that I am honest. For some people my postings can
sound provocative, while others fully agree and find that I could still
go on and make my statements even stronger. Typically Clojure users can
fall into that second category more easily.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
=?windows-1252?Q?Andr=E9_Thieme?= <······························@justmail.de> writes:
> I probably did not make this point clear enough in my original posting.
> My own opinion is that Lisp-1 is more concise and clearer the more a
> functional style is used in a program. While this is still more neutral
> I also prefer Lisp-1 if a program is not predominantly written in
> functional style.
Well, in a non-functional style there isn't any external difference,
other than the fact that people can safely use "list" as the name of a
variable instead of resorting to "lst".
> In my posting before I wanted to make this point:
> I don't see that the CL standard/language is still modern, and I gave
> two main arguments:
> I) no explicit support for threading structures in the language
> (only in implementations, but I was talking in point 1. in my original
> posting about the language, and only later about implementations)
The only issue here with a mandate from the standard is that it would
either
a) Require every implementation to provide threading, somehow. I
would imagine that for some embedded architectures or on operating
systems that don't support threading, this could be an onerous
requirement. It would also make it a lot more difficult to generate new
implementations since they would also have to support threading. Java
gets this independent of architecture by having a virtual machine. Lisp
prefers to allow native implementation techniques.
b) Put an interface for threading into the language, but allow
implementations to effectively ignore them and serialize everything.
This would put you in a similar position as currently, where the
presence of actual threading is really implementation dependent. I
suppose that this is not really a viable option, since co-routines would
require some way of at least interleaving execution. Otherwise you
would just get deadlock.
In any case, you would also end up with a situation where you have to
choose one particular model of threading, and (except for
implementation-specific extensions) not be able to take advantage of
particular features that one operating system or hardware architecture
provides. It doesn't seem like this is an unadulterated benefit, and
there are already least-common-denominator threading libraries.
As a general rule, the Common Lisp specification process has
historically been driven largely by implementations of features rather
than by imposing new ideas that haven't already been tried and tested.
So, is there a common threading interface that has gained enough
popularity to be a good candidate for what a standard should look like?
Cliki lists
Bordeaux threads http://www.cliki.net/Bordeaux-Threads
cl-muproc (Erlang-like) http://www.cliki.net/cl-muproc
patron multi-producer/consumer http://www.cliki.net/patron
portable threads http://www.cliki.net/Portable-Threads
There's a nice discussion of portable threads at
http://gbbopen.org/hyperdoc/ref-portable-thread-entities.html
> II) the language standard would look different if it were written today.
> Those modifications are not just simple details.
>
> To support point II) I gave one example. A lisp veteran who was involved
> in defining what CL is/should be explained that today he sees the past
> efforts in making CL a Lisp-n as very unfortunate.
Well, I'm not sure that's exactly what Kent Pitman indicated given his
careful response to your original citation. But I'll let him speak for
himself.
As far as Lisp-n is concerned, it seems to me that most "modern"
languages use separate namespaces for functions and variables. For
example, in Java it is perfectly acceptable to have a method named "f"
and a variable named "f" in the same scope without conflict.
And for all of the code that looks "nicer" with a Lisp-1 there is other
code that ends up looking not as nice as one tries to avoid name
collisions. In particular, this gets to be really problematic when
writing macros, since an entirely new area for potential name collisions
gets opened up. Consider the following:
(defmacro embed (&body body)
`(list (progn ,@body)))
And then having the following invocation:
(let ((list '(a b c)))
(embed (reverse list)))
This will, of course, break in a Lisp-1 implementation.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ schrieb:
> André Thieme <······························@justmail.de> writes:
>> To support point II) I gave one example. A lisp veteran who was involved
>> in defining what CL is/should be explained that today he sees the past
>> efforts in making CL a Lisp-n as very unfortunate.
>
> Well, I'm not sure that's exactly what Kent Pitman indicated given his
> careful response to your original citation. But I'll let him speak for
> himself.
Kent answered to the y-combinator example. He didn't reply to what I
stated above.
The „unfortunate” came from someone else:
Having separate "value cells" and "function cells" (to use the "street
language" way of saying it) was one of the most unfortuanate issues.
We did not want to break pre-existing programs that had a global
variable named "foo" and a global function named "foo" that were
distinct. We at Symbolics were forced to insist on this, in the face
of everyone's knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all the
specific things like this, but if we had had fewer compatibility
issues, I think it would have come out looking more like Scheme in
general. --- Daniel Weinreb, 24 Feb 2003
> As far as Lisp-n is concerned, it seems to me that most "modern"
> languages use separate namespaces for functions and variables. For
> example, in Java it is perfectly acceptable to have a method named "f"
> and a variable named "f" in the same scope without conflict.
I don't know Java very well, but I think it does not support first class
functions. So „f(f, coll);” may never allow the argument f to be the
same as the function that is called. Perhaps Java is a Java-2 *wink*
and allows to do „funcall(f, function(f), coll)”.
> And for all of the code that looks "nicer" with a Lisp-1 there is other
> code that ends up looking not as nice as one tries to avoid name
> collisions. In particular, this gets to be really problematic when
> writing macros, since an entirely new area for potential name collisions
> gets opened up. Consider the following:
>
> (defmacro embed (&body body)
> `(list (progn ,@body)))
>
> And then having the following invocation:
>
> (let ((list '(a b c)))
> (embed (reverse list)))
>
> This will, of course, break in a Lisp-1 implementation.
Not necesserily. For example, if that Lisp-1 is Clojure then it would
work out like this:
user> (defmacro embed [& body]
`(list (do ·@body)))
#'user/embed
user> (let [list '(a b c)]
(embed (reverse list)))
((c b a))
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On May 9, 5:04 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Kent answered to the y-combinator example. He didn't reply to what I
> stated above.
> The „unfortunate” came from someone else:
> Having separate "value cells" and "function cells" (to use the "street
> language" way of saying it) was one of the most unfortuanate issues.
> We did not want to break pre-existing programs that had a global
> variable named "foo" and a global function named "foo" that were
> distinct.
I would want those to always be distinct. English (and most natural
languages) make contextual distinctions in the meanings of words. The
classic English sentence "buffalo buffalo buffalo" or the Spanish
sentence "Como como como" illustrate the effect, although there are
less pathological examples. Even just something like "I will work at
work today" illustrates this. Because most natural languages do this
and no one complains, I allege that this is the most natural.
It is common to assert that "most elegant" or "most natural" or "most
simple" means something simplistic like "smallest". I claim a better
definition is (approximately) "most isomorphic to how people think",
since this will make best use of available wetware and minimize
dissonance with ordinary human speech. This is slightly an uphill or
confusing target since people can be taught to think differently.
However, when you get people retrained to reform human language to be
single namespace, I'll be happy to discuss this matter with you again.
I don't insist that you like my definition of these simplicity
metrics, I only ask that you respect them as legitimate and stop
making remarks like you don't believe there are people in the world
that think that way, or that you think it's outmoded, or that you
think it's based simply on compatibility. The reason the old
languages were designed this way isn't that we were primitive man
unable to think outside of our caves and now we have grown to
understand better. It's that our brains are highly parallel and
contain strong capabilities for usefully resolving ambiguities in a
way I'd like to leverage in my languages. I do not want to speak in
Esperanto and I do not want to program in Lisp1.
That's not to say I wouldn't program in a Lisp1 under various
circumstances. One makes pragmatic bargains all the time. But if you
ask me how I would design a new language today, I would probably make
it a LispN.
The only reason I ever might consider compromising that is,
ironically, an accommodation to backward compatibility of exactly the
mirror kind. Some legacy systems (here I'll put CLR and JVM in that
camp--heh) do it that way, and I consider them very high priority to
be compatible with. So if that's the reason that Clojure wants to do
it, that's Rich Hickey's call to make and I'm behind him. But not
because I'm caving on my love of Lisp2. Only because I think it's up
to the designer of a language to come up with a consistent theory that
works under the pragmatics it has to, and then to stand by it.
So if the killer argument for Lisp1 is "well, it's required for
compatibility", then I could live with that. But I'll be amused the
whole while that the reason people tried to disparage Lisp2 was that
it was a feeble claim that compatibility mattered. Compatibility DOES
matter, and we should never have been criticized for it. Nor am I
seriously criticizing others for it. I'm just being amused that when
people rely on such arguments, it can turn around to bite them.
> We at Symbolics were forced to insist on this, in the face
> of everyone's knowing that it was not what we would have done absent
> compatibility constraints. It's hard for me to remember all the
> specific things like this, but if we had had fewer compatibility
> issues, I think it would have come out looking more like Scheme in
> general. --- Daniel Weinreb, 24 Feb 2003
I believe in a pluralistic user community and am comfortable with Dan
both thinking this for himself and assessing the community
differently. There is no definitive survey of the community that
would really say, and even if there were I'm not sure what it means
for a community to have an opinion separate from its individuals
absent a voting procedure. However, even though I'm not going to
track Dan down and make him recant, I also am going to say that he's
not counting me in the community he speaks of then. I don't know if he
means the LM community before I became part of it, or if he never
asked me. But I've consistently disliked Lisp1 all along for most
purposes. I do think it's fun for things like Steele's art of the
interpreter papers, and we did some fun things with it in T, but that
doesn't mean I recommend it. It just means I'm capable of smiling in
a lot of adverse circumstances. One has to make the best of whatever
hand they're dealt in the world.
I didn't address hygiene. I don't have time to do that today. But
I've spoken to it on other occasions. It's more of an issue in a
Lisp1 than a Lisp2, which is another reason I dislike Lisp1's. :)
Andr� Thieme <······························@justmail.de> writes:
> [...]
> I should have chosen another example, which sounds about as clear as
> the issue with the concurrency support.
And that would be?
Nicolas
--
Lisp is not dead. It's just Andre Thieme who looks somewhat pale.
Nicolas Neuss schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>
>> [...]
>> I should have chosen another example, which sounds about as clear as
>> the issue with the concurrency support.
>
> And that would be?
For example lazyness.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 8, 9:07 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Nicolas Neuss schrieb:
>
> > André Thieme <······························@justmail.de> writes:
>
> >> [...]
> >> I should have chosen another example, which sounds about as clear as
> >> the issue with the concurrency support.
>
> > And that would be?
>
> For example lazyness.
... as in CLAZY? :)
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
Marco Antoniotti schrieb:
> On May 8, 9:07 pm, André Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Nicolas Neuss schrieb:
>>
>>> André Thieme <······························@justmail.de> writes:
>>>> [...]
>>>> I should have chosen another example, which sounds about as clear as
>>>> the issue with the concurrency support.
>>> And that would be?
>> For example lazyness.
>
> ... as in CLAZY? :)
Sure. Now we left point 1 of my earlier post. Now this is point 3:
„environment around the langauge and implementation”
To not seem that we cherry pick on one feature we should look at the
bigger picture. I gave examples in my earlier post (May 2nd).
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On May 2, 2:44 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> [...]
> In http://www.nhplace.com/kent/Papers/Technical-Issues.html Kent Pitman
> argued:
> “Probably a programmer who frequently passes functions as arguments or
> who uses passed arguments functionally finds Lisp1 syntax easier to
> read than Lisp2 syntax;”.
I don't know if I argued that or not. I probably didn't strongly
object to the phrase.
It should be noted for the record that the paper you're citing has two
authors and the two of us were thrown together by X3J13 exactly
because we disagreed quite strongly over all the issues covered. The
careful reader will be able to discern that in places there is an
almost alternation of voices where Gabriel wrote a sentence or
paragraph saying one thing and then I responded (rather than editing
his statement) saying another, or vice versa. In fact, we each had
total control of the paper twice, but I think he had the last shot at
it. Consequently, it has slightly more of his voice than mine.
I personally don't happen to like the Lisp1 syntax at all even when
I'm passing functions, except in what I regard is the highly rare
situation of pretending Lisp is the lambda calculus (which I regard as
a very rare event), and even then more because it's a piece of
historical art than my preference. It's like talking in iambic
pentameter to be Shakespeare-like. I've written pieces in that form
(see for example http://www.anotherwayout.com/episodes/episode-127.html),
but it's not anything I would advocate as a way of doing things
normally. And I feel the same about Lisp1. But I acknowledge that
others feel quite differently about this.
The point I do want to make, though, is that seeing text in that paper
does not imply that *I* said it. It means one of us said it. We
jointly wrote the paper, but we certainly do not jointly hold all of
the opinions mentioned in the paper.
The paper is itself a debate. Like all debates, everyone reads it as
supporting their own side as the winner. I was surprised the first
time I heard people thought it makes a clear case for Lisp1 because I
think just the opposite. But when I finally came to the independent
realization, probably watching some US presidential debate, that all
debates are like this and that spin doctors after always claim victory
for their side, I suddenly understood better the varying responses to
this paper.
So feel free to carry on with your discussion. Just be kind of
careful about invoking my name as if this paper is the final word
about my preferences on anything. Thanks. :)
On May 2, 11:44 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Pascal Costanza schrieb:
>
> > André Thieme wrote:
> > There are enough people who think that a Lisp-2, or Lisp-n, is superior
> > to a Lisp-1, among other reasons because they make macros more reliable.
>
> > To me, whenever a new Lisp dialect comes out that chooses to go the
> > Lisp-1 route, this seems like a major step back to me.
>
> I think that is also about personal preference.
> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
> pass functions around and call them.
Be careful how strongly opposed to Lisp-n you are. At the ILC09
tutorial I went up to Rich Hickey and asked hom what his reasons were
for selecting Lisp-1, and his answer was "I just want to allow
arbitrary things to be in the functional position in a list". I
pointed out that yes, CL doesn't allow arbitrary items in the first
position in a list, but only because of how it's specified. But a case
could be made in a Lisp that is not CL for spefying that to evaluate
a list one could take the first element and if it is a symbol, use its
function cell, or otherwise assume it is a call-able value and just
call it. It would certainly satisfy Hickey's goal of allowing any
arbitrary value in the functional position. This was during a break,
and RH seemed interested in the concept but we never finished
discussing it because the break was over and he had to continue the
discussion.
So as you take a strong stand based on what Clojure does, be careful.
Who knows? Clojure could change out from under you and embarrass you a
little...
Duane
·····@franz.com schrieb:
> On May 2, 11:44 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Pascal Costanza schrieb:
>>
>>> Andr� Thieme wrote:
>>> There are enough people who think that a Lisp-2, or Lisp-n, is superior
>>> to a Lisp-1, among other reasons because they make macros more reliable.
>>> To me, whenever a new Lisp dialect comes out that chooses to go the
>>> Lisp-1 route, this seems like a major step back to me.
>> I think that is also about personal preference.
>> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
>> pass functions around and call them.
>
> Be careful how strongly opposed to Lisp-n you are. At the ILC09
> tutorial I went up to Rich Hickey and asked hom what his reasons were
> for selecting Lisp-1, and his answer was "I just want to allow
> arbitrary things to be in the functional position in a list". I
> pointed out that yes, CL doesn't allow arbitrary items in the first
> position in a list, but only because of how it's specified. But a case
> could be made in a Lisp that is not CL for spefying that to evaluate
> a list one could take the first element and if it is a symbol, use its
> function cell, or otherwise assume it is a call-able value and just
> call it. It would certainly satisfy Hickey's goal of allowing any
> arbitrary value in the functional position. This was during a break,
> and RH seemed interested in the concept but we never finished
> discussing it because the break was over and he had to continue the
> discussion.
>
> So as you take a strong stand based on what Clojure does, be careful.
> Who knows? Clojure could change out from under you and embarrass you a
> little...
I just wanted to write something similar in another post in this thread,
but the opposit way around.
I believe that some people defend Lisp-2 simply because that is the way
of CL. I think that if there exists a parallel universe in which CL is a
Lisp-1 then some of those hardcore Lisp-2 advocates in this universe
would argue in favour of Lisp-1.
Especially people who sometimes use #' instead of funcall.
And users of the lambda macro can't convince me that they prefer Lisp-2
over Lisp-1. If they do, then there is always the function operator...
I certainly prefer Lisp-1 over Lisp-2. And I doubt that Clojure will
soon require a funcall and thus breaking close to 100% of all existing
Clojure programs.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 8, 11:00 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ·····@franz.com schrieb:
>
>
>
> > On May 2, 11:44 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> Pascal Costanza schrieb:
>
> >>> André Thieme wrote:
> >>> There are enough people who think that a Lisp-2, or Lisp-n, is superior
> >>> to a Lisp-1, among other reasons because they make macros more reliable.
> >>> To me, whenever a new Lisp dialect comes out that chooses to go the
> >>> Lisp-1 route, this seems like a major step back to me.
> >> I think that is also about personal preference.
> >> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
> >> pass functions around and call them.
>
> > Be careful how strongly opposed to Lisp-n you are. At the ILC09
> > tutorial I went up to Rich Hickey and asked hom what his reasons were
> > for selecting Lisp-1, and his answer was "I just want to allow
> > arbitrary things to be in the functional position in a list". I
> > pointed out that yes, CL doesn't allow arbitrary items in the first
> > position in a list, but only because of how it's specified. But a case
> > could be made in a Lisp that is not CL for spefying that to evaluate
> > a list one could take the first element and if it is a symbol, use its
> > function cell, or otherwise assume it is a call-able value and just
> > call it. It would certainly satisfy Hickey's goal of allowing any
> > arbitrary value in the functional position. This was during a break,
> > and RH seemed interested in the concept but we never finished
> > discussing it because the break was over and he had to continue the
> > discussion.
>
> > So as you take a strong stand based on what Clojure does, be careful.
> > Who knows? Clojure could change out from under you and embarrass you a
> > little...
>
> I just wanted to write something similar in another post in this thread,
> but the opposit way around.
> I believe that some people defend Lisp-2 simply because that is the way
> of CL. I think that if there exists a parallel universe in which CL is a
> Lisp-1 then some of those hardcore Lisp-2 advocates in this universe
> would argue in favour of Lisp-1.
It may be that some people argue Lisp-2 (actually, Lisp-n) because it
is what CL is. But I'm not those people, and I do not recall those
Lisp-n advocates using that argument; all of the arguments I recall
people like Kent Pitman making for Lisp-n have been for the concept of
namespace separation, not the spec. The classic benchmark is to be
able to use ``list'' as a variable name without breaking the
underlying system.
> Especially people who sometimes use #' instead of funcall.
I'm not sure what you mean here.
> And users of the lambda macro can't convince me that they prefer Lisp-2
> over Lisp-1. If they do, then there is always the function operator...
The fundamental argument for Lisp-2 and higher is separation of
namespaces, especially for variables. I hate having to use lst as a
variable name because list is already in use.
> I certainly prefer Lisp-1 over Lisp-2. And I doubt that Clojure will
> soon require a funcall and thus breaking close to 100% of all existing
> Clojure programs.
You've fallen into the classic trap in the Lisp-1/Lisp-n debate.
Funcall is not necessary in Lisp-n, except in languages which exercise
strict separation of the function namespace (languages like CL). Any
language which would provide for the execution of functions and/or
values in the car position (as RH has stated he wants) need not
require the use of funcall. I'm afraid it is you that is mistakenly
using the must-have-funcall argument just because CL has required it.
Duane
·····@franz.com schrieb:
> On May 8, 11:00 am, André Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> ·····@franz.com schrieb:
> It may be that some people argue Lisp-2 (actually, Lisp-n) because it
> is what CL is. But I'm not those people, and I do not recall those
> Lisp-n advocates using that argument; all of the arguments I recall
> people like Kent Pitman making for Lisp-n have been for the concept of
> namespace separation, not the spec. The classic benchmark is to be
> able to use ``list'' as a variable name without breaking the
> underlying system.
That problem can occur in Clojure:
(defn foo [list]
(list list))
This call will typically throw an exception when foo is called in a way
that is interesting for humans. For an infinite set of cases foo will
work fine, for example for:
(foo list) ==> (#< ·····························@b11164>)
(foo identity) ==> #<core$identity__3567 ···························@7b21ea>
(foo constantly) ...
But not for (foo [1 2 3])
>> Especially people who sometimes use #' instead of funcall.
>
> I'm not sure what you mean here.
Sorry, a typo. #' vs function.
>> And users of the lambda macro can't convince me that they prefer Lisp-2
>> over Lisp-1. If they do, then there is always the function operator...
>
> The fundamental argument for Lisp-2 and higher is separation of
> namespaces, especially for variables. I hate having to use lst as a
> variable name because list is already in use.
In principle being Lisp-1 can potentially result in parameter names in
Clojure that are not perfect. In practice however this is not really a
problem. For practical matters there are only few functions that work
specfically with lists, have exactly one parameter which is supposed to
be a list and then also have to call the function list.
„list” is just a place holder here.
Take a look at
http://code.google.com/p/clojure/source/browse/#svn/trunk/src/clj/clojure
or
http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib
and see how often that „beautiful parameter names” argument is a problem.
>> I certainly prefer Lisp-1 over Lisp-2. And I doubt that Clojure will
>> soon require a funcall and thus breaking close to 100% of all existing
>> Clojure programs.
>
> You've fallen into the classic trap in the Lisp-1/Lisp-n debate.
> Funcall is not necessary in Lisp-n, except in languages which exercise
> strict separation of the function namespace (languages like CL). Any
> language which would provide for the execution of functions and/or
> values in the car position (as RH has stated he wants) need not
> require the use of funcall. I'm afraid it is you that is mistakenly
> using the must-have-funcall argument just because CL has required it.
Ah okay, funcall wouldn't be required. Thanks for making me aware about
the trap :)
Anyway, how about FUNCTION, respectively a reader macro?
Would things like (map √ coll) need to become (map $√ coll) or even
(map (function √) coll)? That would break even more code.
If there is a solution that won't break (pratically 100% of) existing
programs then I wouldn't object.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On May 9, 2:52 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ·····@franz.com schrieb:
>
> > On May 8, 11:00 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> ·····@franz.com schrieb:
> > It may be that some people argue Lisp-2 (actually, Lisp-n) because it
> > is what CL is. But I'm not those people, and I do not recall those
> > Lisp-n advocates using that argument; all of the arguments I recall
> > people like Kent Pitman making for Lisp-n have been for the concept of
> > namespace separation, not the spec. The classic benchmark is to be
> > able to use ``list'' as a variable name without breaking the
> > underlying system.
>
> That problem can occur in Clojure:
> (defn foo [list]
> (list list))
>
> This call will typically throw an exception when foo is called in a way
> that is interesting for humans. For an infinite set of cases foo will
> work fine, for example for:
> (foo list) ==> (#< ·····························@b11164>)
> (foo identity) ==> #<core$identity__3567 ···························@7b21ea>
> (foo constantly) ...
>
> But not for (foo [1 2 3])
Yes, this is the kind of exceptional execution that Lisp-1 forces.
> >> Especially people who sometimes use #' instead of funcall.
>
> > I'm not sure what you mean here.
>
> Sorry, a typo. #' vs function.
OK, now that I know what you mean, I don't understand what the problem
is. Though possibly confusing because #' means something completely
different in Clojure than in CL, it is the case that in CL there is
_no_ difference between #'foo and (function foo) - one is a character
macro for the other. What is your issue with it?
> >> And users of the lambda macro can't convince me that they prefer Lisp-2
> >> over Lisp-1. If they do, then there is always the function operator...
>
> > The fundamental argument for Lisp-2 and higher is separation of
> > namespaces, especially for variables. I hate having to use lst as a
> > variable name because list is already in use.
>
> In principle being Lisp-1 can potentially result in parameter names in
> Clojure that are not perfect. In practice however this is not really a
> problem. For practical matters there are only few functions that work
> specfically with lists, have exactly one parameter which is supposed to
> be a list and then also have to call the function list.
> „list” is just a place holder here.
>
> Take a look athttp://code.google.com/p/clojure/source/browse/#svn/trunk/src/clj/clo...
> orhttp://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
>
> and see how often that „beautiful parameter names” argument is a problem.
This is why you are constantly accused of marketing Clojure; this
looks like just another ruse to get people to look at Clojure code.
Performing a search of "beautiful" generates no results. If you are
making a point, make it. Otherwise leave unexplained references to
code out of the conversation.
> >> I certainly prefer Lisp-1 over Lisp-2. And I doubt that Clojure will
> >> soon require a funcall and thus breaking close to 100% of all existing
> >> Clojure programs.
>
> > You've fallen into the classic trap in the Lisp-1/Lisp-n debate.
> > Funcall is not necessary in Lisp-n, except in languages which exercise
> > strict separation of the function namespace (languages like CL). Any
> > language which would provide for the execution of functions and/or
> > values in the car position (as RH has stated he wants) need not
> > require the use of funcall. I'm afraid it is you that is mistakenly
> > using the must-have-funcall argument just because CL has required it.
>
> Ah okay, funcall wouldn't be required. Thanks for making me aware about
> the trap :)
You're welcome.
> Anyway, how about FUNCTION, respectively a reader macro?
What about function? What is the question here?
> Would things like (map √ coll) need to become (map $√ coll) or even
> (map (function √) coll)? That would break even more code.
Break what code? Existing code? Potential code? It is simply the
case that how the language is defined will determine how users can
program in it. The question is whether the language is consistent and
intuitive as to how it defines itself.
> If there is a solution that won't break (pratically 100% of) existing
> programs then I wouldn't object.
Hyperbole. Just above you were saying that you didn't care between
Lisp-1 and Lisp-n. I'm not interested in arguing hyperbole with you.
Duane
·····@franz.com schrieb:
> On May 9, 2:52 am, André Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> But not for (foo [1 2 3])
>
> Yes, this is the kind of exceptional execution that Lisp-1 forces.
Agreed.
Also one potential „danger” with Lisp-1 is to have a function F with a
parameter P shadowing a function, and where we later want to call the
function P, then we need to remember that P must be renamed, and each
use of it in the body of F needs to be changed as well.
A good editor could help us, but right now I am not aware of an editor
that is prepared for that.
I would like: underline or colorize each use of parameters of the
function one is currently editing. In that case we could see that map
in (map ...) is suddenly underlined.
>>>> Especially people who sometimes use #' instead of funcall.
>>> I'm not sure what you mean here.
>> Sorry, a typo. #' vs function.
>
> OK, now that I know what you mean, I don't understand what the problem
> is. Though possibly confusing because #' means something completely
> different in Clojure than in CL, it is the case that in CL there is
> _no_ difference between #'foo and (function foo) - one is a character
> macro for the other. What is your issue with it?
Yes, I was always talking about CLs reader macro #' for FUNCTION.
My point is that people who use #' can not convince me that they prefer
Lisp-2 over Lisp-1.
But I believe that some people really prefer Lisp-2 over Lisp-1, and
that those people will spell out (function ...).
A friend of mine is doing so.
>>>> And users of the lambda macro can't convince me that they prefer Lisp-2
>>>> over Lisp-1. If they do, then there is always the function operator...
>>> The fundamental argument for Lisp-2 and higher is separation of
>>> namespaces, especially for variables. I hate having to use lst as a
>>> variable name because list is already in use.
>> In principle being Lisp-1 can potentially result in parameter names in
>> Clojure that are not perfect. In practice however this is not really a
>> problem. For practical matters there are only few functions that work
>> specfically with lists, have exactly one parameter which is supposed to
>> be a list and then also have to call the function list.
>> „list” is just a place holder here.
>>
>> Take a look athttp://code.google.com/p/clojure/source/browse/#svn/trunk/src/clj/clo...
>> orhttp://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
>>
>> and see how often that „beautiful parameter names” argument is a problem.
>
> This is why you are constantly accused of marketing Clojure; this
> looks like just another ruse to get people to look at Clojure code.
> Performing a search of "beautiful" generates no results. If you are
> making a point, make it. Otherwise leave unexplained references to
> code out of the conversation.
Duane sorry, but this is a false claim from you.
This has absolutely nothing to do with marketing. I understand the
psychology behind those accusing people, but I must reject that as
indefensible.
And btw, I did not ask you to search for "beautiful".
People here in c.l.l. who prefer Lisp-2 over Lisp-1 told me several
times that Lisp-1 leads to bad parameter names. I would like that those
people back up their claims.
What wonders me: why don't people in the Clojure mailing list constantly
complain about this? My impression is: the Lisp-2 folks try to make an
issue out of something that in practise is not very visible.
I feel as if they put lipstick on the pig.. defending whatever CL
offers, just because it is CL.
We can find many thousand lines of this Lisp-onish Clojure code online.
I don't say that it never ever has those naming problems. But nearly all
the functions we can find simply don't have this problem.
But: lots of functions pass function objects in their calls. Some take
other functions as their arguments and call them. The Lisp-1 code is
full of that.
I just linked to material to support my claim. How can we try to talk at
least minimally objectively when I am not even allowed to post links to
non-CL code to back up what I say, and ask others to use that material
to point me to problems I am not aware of?
Sorry, but this stinks a bit.
If you really found that my quote above was about marketing, then I must
say that I see a very big misfiring of your neuros. Your pattern matcher
(brain) produced a false positive.
You are one of the most moderate posters here in c.l.l. I don't want to
believe that you are willing to go the route of the more emotional
people with less self-control, and just shout out the killer argument
"marketing" to shut up any discussion.
Okay, next:
>> Anyway, how about FUNCTION, respectively a reader macro?
>
> What about function? What is the question here?
Oki, I did not put enough information into my question. I meant:
do you also see a way to get rid of the special operator function?
Can Clojure be made a Lisp-2 without having to mark functions that
one wants to pass?
Such as (reduce + coll) vs (reduce (function +) coll).
>> Would things like (map √ coll) need to become (map $√ coll) or even
>> (map (function √) coll)? That would break even more code.
>
> Break what code? Existing code? Potential code? It is simply the
> case that how the language is defined will determine how users can
> program in it. The question is whether the language is consistent and
> intuitive as to how it defines itself.
If Rich Hickey wants to follow the idea of making Clojure a Lisp-2, is
there then a way how he can do that by not breaking code?
If he finds a way to make it a Lisp-2 without having the need of the
function FUNCALL or the special operator FUNCTION (or its Lisp-onish
reader macro #', here in my example marked by a $ sign as #' already
has a different meaning in Clojure), then no code would break.
>> If there is a solution that won't break (pratically 100% of) existing
>> programs then I wouldn't object.
>
> Hyperbole. Just above you were saying that you didn't care between
> Lisp-1 and Lisp-n. I'm not interested in arguing hyperbole with you.
Probably a misunderstanding. Maybe I did not clearly express myself.
If Rich Hickey can make Clojure a Lisp-2 in such a way that
(reduce + coll) will continue to work after the change, then no code
would break.
You already explained that there are technical ways to get rid of
FUNCALL. I didn't know that. I thought that it would be required if
one would like to do things like:
(defun foo (list)
(funcall list list))
(foo #'identity)
But I'll take your word for it right now. So, for now let's see FUNCALL
as eliminated. Good, so my resistance against Clojure becoming a Lisp-2
is reduced.
But the more important issue is that (reduce + coll) can stay the way it
is and does not need to become (reduce (function +) coll) or with some
reader macro support something like (reduce $+ coll).
Provided there is also a way that (reduce + coll) can stay unchanged,
then I won't object anymore. Then let Clojure become a Lisp-2.
The need for FUNCTION and FUNCALL are my only objections I have against
Lisp-2.
Hope this time I was more clear.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
André Thieme wrote:
> People here in c.l.l. who prefer Lisp-2 over Lisp-1 told me several
> times that Lisp-1 leads to bad parameter names. I would like that those
> people back up their claims.
Just one heads down working programmer who dallied in Arc long enough to
implement Cells Lite: there are prolly no big claims to be made here. I
did get bit by lisp-1 where I chose a local name overlapping something,
and that did leave me with an abiding case of lingering anxiety
medication has not helped with. Meanwhile, many a time when programming
in CL I choose a local name that makes me worry reflexively, but then I
remember it's L2 and feel great inside.
It is interesting that the reflexive concern pops in even after 14 years
of non-stop Lisp, but maybe that is because my formative years involved
as much Basic as anything else (from Apple II to RSTS/E to VAX/VMS), and
those first neuronal patterns never really fade.
kt
"=?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=" <······························@justmail.de> wrote on Sat, 09 May 2009:
> Also one potential danger with Lisp-1 is to have a function F with a
> parameter P shadowing a function, and where we later want to call the
> function P, then we need to remember that P must be renamed, and each use
> of it in the body of F needs to be changed as well.
Yes, correct.
> A good editor could help us, but right now I am not aware of an editor that
> is prepared for that. I would like: underline or colorize each use of
> parameters of the function one is currently editing. In that case we could
> see that map in (map ...) is suddenly underlined.
Or: use a Lisp-2/n.
> My point is that people who use #' can not convince me that they prefer
> Lisp-2 over Lisp-1.
Is this a statement about you, or a statement about them?
Why is it that they cannot convince you about their preferences?
What inherent conflict do you see?
> But I believe that some people really prefer Lisp-2 over Lisp-1, and
> that those people will spell out (function ...).
Why? What does the syntactic sugar of #' have to do with the preference
for a Lisp-2?
> Can Clojure be made a Lisp-2 without having to mark functions that
> one wants to pass?
> Such as (reduce + coll) vs (reduce (function +) coll).
A Lisp-2/n separates (among others) function and value bindings. In general,
you would need the "(function ...)" (or #') in this case. But for some
examples perhaps the value cell holds the same function as the function cell?
In that case, you wouldn't need the special notation.
It's only when the function and value cells _differ_, that it's important
to specify the correct one.
So: you can solve your problem, simply by always having your function cells
identical to your value cells, in the code you write. Then you don't need
a special syntax indicator for getting the function.
> If Rich Hickey wants to follow the idea of making Clojure a Lisp-2, is
> there then a way how he can do that by not breaking code?
Almost certainly not. If there is code written assuming a Lisp-1, surely
SOME of it must change in at least trivial ways, in order to work in a
Lisp-2/n. Otherwise, what would be the significance of the change?
> If he finds a way to make it a Lisp-2 without having the need of the
> function FUNCALL or the special operator FUNCTION (or its Lisp-onish
> reader macro #', here in my example marked by a $ sign as #' already
> has a different meaning in Clojure), then no code would break.
I suspect "no code would break" is too high a bar.
But, "programmers can mostly follow the same style they're used to" might
be achievable.
> If Rich Hickey can make Clojure a Lisp-2 in such a way that
> (reduce + coll) will continue to work after the change, then no code
> would break.
That one is unlikely in general, but possible in some cases.
> You already explained that there are technical ways to get rid of
> FUNCALL. I didn't know that. I thought that it would be required if
> one would like to do things like:
> (defun foo (list)
> (funcall list list))
> (foo #'identity)
Wait a minute. I appreciate that the code you want to write instead is
(defun foo (list)
(list list))
The question is, what answer do you _want_ from the call to
(foo #'identity)
The whole POINT of a Lisp-2/n, is to return the answer
'(#'identity)
not just
#'identity
In other words, to make sure that
(list ...)
calls the predefined function LIST, not the function that happens to be
bound to the variable named "list".
So yes, in a Lisp-2/n, if you WANT the result
#'identity
then you WOULD need something like a FUNCALL
(defun foo (list)
(funcall list list))
But that's (intended to be) the (or one of the) BENEFIT(s) of a Lisp-2/n,
that you don't accidentally shadow well-known functions, just because of
a local variable naming choice.
I suspect the "technical way" you were referring to, is that Common Lisp
doesn't currently allow
((identity #'list) 1 2 3)
to be meaningful. The CAR position of a form has to be a symbol, in order
to result in a function call. But there isn't any other use for that syntax;
it's just an error in CL. There's no reason why a new Lisp couldn't be
defined that, when seeing such syntax, just evaluates the CAR position and
calls whatever results as a function.
In Common Lisp, this use you DO need to notate with a FUNCALL:
(funcall (identity #'list) 1 2 3)
and that's the FUNCALL that one could imagine a Lisp doing without.
But not the FUNCALL in your example.
> But the more important issue is that (reduce + coll) can stay the way it
> is and does not need to become (reduce (function +) coll) or with some
> reader macro support something like (reduce $+ coll).
You know,
(reduce + coll)
works just fine, even in regular old currently-existing Common Lisp, if
you don't need the "+" symbol as a variable, and just have its value be
the function as well.
(Well, ok: this won't work from the REPL at the top-level, but that's
for separate reasons that aren't relevant here.)
> The need for FUNCTION and FUNCALL are my only objections I have against
> Lisp-2.
You understand, I hope, that the whole (?) justification for a Lisp-2 is so
that this code
(defun foo (list)
(list list))
(foo #'identity)
does NOT result in
#'identity
but instead in
'(#'identity)
Assuming you agree (?) that this is a benefit, then something like
FUNCTION/FUNCALL is clearly required, for the cases when you deliberately
do NOT want the default behavior.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Instead of mousetraps, what about baby traps? Not to harm the babies,
but just to hold them down until they can be removed.
-- "Lost" Deep Thoughts by Jack Handey [SNL]
On May 9, 12:25 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ·····@franz.com schrieb:
>
> > On May 9, 2:52 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> But not for (foo [1 2 3])
>
> > Yes, this is the kind of exceptional execution that Lisp-1 forces.
>
> Agreed.
>
> Also one potential „danger” with Lisp-1 is to have a function F with a
> parameter P shadowing a function, and where we later want to call the
> function P, then we need to remember that P must be renamed, and each
> use of it in the body of F needs to be changed as well.
> A good editor could help us, but right now I am not aware of an editor
> that is prepared for that.
> I would like: underline or colorize each use of parameters of the
> function one is currently editing. In that case we could see that map
> in (map ...) is suddenly underlined.
>
> >>>> Especially people who sometimes use #' instead of funcall.
> >>> I'm not sure what you mean here.
> >> Sorry, a typo. #' vs function.
>
> > OK, now that I know what you mean, I don't understand what the problem
> > is. Though possibly confusing because #' means something completely
> > different in Clojure than in CL, it is the case that in CL there is
> > _no_ difference between #'foo and (function foo) - one is a character
> > macro for the other. What is your issue with it?
>
> Yes, I was always talking about CLs reader macro #' for FUNCTION.
> My point is that people who use #' can not convince me that they prefer
> Lisp-2 over Lisp-1.
> But I believe that some people really prefer Lisp-2 over Lisp-1, and
> that those people will spell out (function ...).
> A friend of mine is doing so.
You may see a correlation between CLers who use (function...) and
CLers who use #' but any such correlation is coincidental. Both forms
are identical, and they do not speak to the mindset of the user of
either. We do not use #' or (function ...) to convince anyone of
anything. It is just a special-operator in CL and it does whaty it
does. Period.
> >> Take a look athttp://code.google.com/p/clojure/source/browse/#svn/trunk/src/clj/clo...
> >> orhttp://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
>
> >> and see how often that „beautiful parameter names” argument is a problem.
>
> > This is why you are constantly accused of marketing Clojure; this
> > looks like just another ruse to get people to look at Clojure code.
> > Performing a search of "beautiful" generates no results. If you are
> > making a point, make it. Otherwise leave unexplained references to
> > code out of the conversation.
>
> Duane sorry, but this is a false claim from you.
The only claim I made here was that your previous post didn't carry
enough information with it. As such, it _looks_ like marketing from
someone who has a habit of throwing tidbits out for people to chew
on. You certainly can't deny my claim that it _looks_ like marketing;
it is what it looks like to me. And this is a chance to learn a
little about why you have been getting so much flak from others on
this list; if you throw up information without explaining what it is
for, it _looks_ like marketing.
> This has absolutely nothing to do with marketing. I understand the
> psychology behind those accusing people, but I must reject that as
> indefensible.
> And btw, I did not ask you to search for "beautiful".
You did not ask me to do anything; you did not explain yourself. I am
not a mind reader, but I am pretty good at making guesses at why
people say or do what they do. I thought that the juxtaposition of
the links with the quoted phrase "beautiful parameter names" might be
a clue for me to look for such a quoted phrase. But I could find no
such phrase, nor even the word beautiful. So my guess was wrong.
Now, in this reply, you have explained yourself below; if you had done
this in your previous reply, we wouldn't be having this little
misunderstanding.
> People here in c.l.l. who prefer Lisp-2 over Lisp-1 told me several
> times that Lisp-1 leads to bad parameter names. I would like that those
> people back up their claims.
I think you misunderstand their intentions. There may even be some
who say something like that, but here's what they're really saying:
as Kenny also noted in another reply to yours here, it is not really
an issue of forcing bad parameter (variable) names, but the fact that
there are names that are off-limits because they are the names of
functions, and they are common names for what they would want to use
as variables. So, in a sense, it is not that it forces bad names, but
excludes some of the very best names. The classic example is list,
which forces a variable name that is not list, which is often the best
name for a ... list. Someone else mentioned the equivalent natural-
language overloading of verbs and nouns; English is hard enough as it
is, but think how hard it would be if you couldn't talk about listing
a list. Furthermore, a language which has only a variable (noun)
namespace and which borrows that namespace for functions (verbs) has a
possibly infinite number of these collisions, if it is an extensible
language. So as Kenny mentioned already, it is really a question of
having to pause to reflect on whether a name has already been used as
a function before having the freedom to use it as a variable. It is
this lack of freedom which Lisp-n advocates rail against, and those of
us who have gotten used to the idea of selecting the perfect name for
a variable, it does indeed seem as though putting a damper on
selecting that perfect name is in fact forcing selection of "bad"
names.
> What wonders me: why don't people in the Clojure mailing list constantly
> complain about this? My impression is: the Lisp-2 folks try to make an
> issue out of something that in practise is not very visible.
> I feel as if they put lipstick on the pig.. defending whatever CL
> offers, just because it is CL.
>
> We can find many thousand lines of this Lisp-onish Clojure code online.
> I don't say that it never ever has those naming problems. But nearly all
> the functions we can find simply don't have this problem.
> But: lots of functions pass function objects in their calls. Some take
> other functions as their arguments and call them. The Lisp-1 code is
> full of that.
> I just linked to material to support my claim. How can we try to talk at
> least minimally objectively when I am not even allowed to post links to
> non-CL code to back up what I say, and ask others to use that material
> to point me to problems I am not aware of?
If you had made the above explanation of why you posted that code,
there would have been no misunderstanding. Again, I am not a mind
reader. I'm a pretty good guesser, but I guessed wrong in this case.
> Sorry, but this stinks a bit.
Yes, it does, but the stink is not coming from me. You are the one
who forced me to guess, and because I got it wrong, you have now
become defensive.
> If you really found that my quote above was about marketing, then I must
> say that I see a very big misfiring of your neuros. Your pattern matcher
> (brain) produced a false positive.
You could have corrected that misfire, which occurred because of too
little information.
> You are one of the most moderate posters here in c.l.l. I don't want to
> believe that you are willing to go the route of the more emotional
> people with less self-control, and just shout out the killer argument
> "marketing" to shut up any discussion.
Now this is what really stinks. How dare you accuse me of trying to
shut you up? I have never even come close to trying to shut you up;
I'm trying to help you to understand why you get so much animosity
from this newsgroup. When I did this in the past, and you listened to
what I had to say, things improved for you a bit, didn't they? You
have recently been getting more technical discussions from people,
even if they disagree, because you are sticking to the technical
discussions, for the most part. But now you accuse me of that same
animosity? Go back and reread what I actually wrote, and understand
where it came from. If you base your expectations of responses from
people not to depend on how much information you give them, then you
are in for a rough ride wherever you go.
> Okay, next:
>
> >> Anyway, how about FUNCTION, respectively a reader macro?
>
> > What about function? What is the question here?
>
> Oki, I did not put enough information into my question. I meant:
> do you also see a way to get rid of the special operator function?
> Can Clojure be made a Lisp-2 without having to mark functions that
> one wants to pass?
> Such as (reduce + coll) vs (reduce (function +) coll).
OK, now we're back to technical discussions. And I really don't care
whether RH wants to solve this issue; he has his own ideas for what he
wants to do, and he will decide if this is something worth doing. As
far as the introduction of a need for (function ...) to get at a
function cell, that is simply a design decision. He made a similar
design decision and followed CL in his design of "vars"; in his
tutorial he cited the preponderance of CL implementations which
treated globally special variables as per-thread when they are bound,
and global when they are not bound, and he chose the same style for
his language. Ironically, it is #' which denotes this. But some
might criticize either Clojure or CL for such a decision; in Allegro
CL, for example, one can get at the current binding of *print-pretty*
by just saying *print-pretty* in the code, but in order to get the
global value, one must say (sys:global-symbol-value '*print-pretty*) -
I'm sure if you wanted to make a reader macro for it you could, but
the criticism might still be made that forcing more functionality in
order to get a global value is not necessary (and the same criticism
would be applicable to Clojure). Our responses to that for both
languages would be that because the symbol has the global value
associated with it as well as the bound value, there needs to be a
different way of accessing it, otherwise the feature would not be
available. It is a design decision to allow global values of symbols
to be accessed, and with that design decision comes requirements for
access. How the values are accessed are also designed into the
language, and of RH decided to make the change, he would have to
decide how access would happen as well.
> >> Would things like (map √ coll) need to become (map $√ coll) or even
> >> (map (function √) coll)? That would break even more code.
Ah, so that's what you meant by "breaking code". Yes, incompatible
changes are a pain. It may be that he makes no change for that
reason. But then again, since your language is defined by its
implementation, you have to rely on your benevolent dictator not to
make your older code obsolete in any other areas, as well.
> > Break what code? Existing code? Potential code? It is simply the
> > case that how the language is defined will determine how users can
> > program in it. The question is whether the language is consistent and
> > intuitive as to how it defines itself.
>
> If Rich Hickey wants to follow the idea of making Clojure a Lisp-2, is
> there then a way how he can do that by not breaking code?
> If he finds a way to make it a Lisp-2 without having the need of the
> function FUNCALL or the special operator FUNCTION (or its Lisp-onish
> reader macro #', here in my example marked by a $ sign as #' already
> has a different meaning in Clojure), then no code would break.
Right.
> >> If there is a solution that won't break (pratically 100% of) existing
> >> programs then I wouldn't object.
>
> > Hyperbole. Just above you were saying that you didn't care between
> > Lisp-1 and Lisp-n. I'm not interested in arguing hyperbole with you.
>
> Probably a misunderstanding. Maybe I did not clearly express myself.
Correct. It related to the question of what code you were talking
about breaking.
> If Rich Hickey can make Clojure a Lisp-2 in such a way that
> (reduce + coll) will continue to work after the change, then no code
> would break.
> You already explained that there are technical ways to get rid of
> FUNCALL. I didn't know that. I thought that it would be required if
> one would like to do things like:
> (defun foo (list)
> (funcall list list))
>
> (foo #'identity)
>
> But I'll take your word for it right now. So, for now let's see FUNCALL
> as eliminated. Good, so my resistance against Clojure becoming a Lisp-2
> is reduced.
This was really my only point in the first place. RH's stated purpose
for Lisp-1 over Lisp-2 was to allow extension of the first element of
a list designated for evaluation. My response was in how to get rid
of funcall in some imaginary lisp (perhaps a future version of
Clojure) Whether he does this or not is not my concern, nor is what
he would do with the function issue.
> But the more important issue is that (reduce + coll) can stay the way it
> is and does not need to become (reduce (function +) coll) or with some
> reader macro support something like (reduce $+ coll).
> Provided there is also a way that (reduce + coll) can stay unchanged,
> then I won't object anymore. Then let Clojure become a Lisp-2.
> The need for FUNCTION and FUNCALL are my only objections I have against
> Lisp-2.
> Hope this time I was more clear.
Yes, much more clear. Now if you can only develop a little thicker
skin :-)
Duane
Andr� Thieme <······························@justmail.de> writes:
> Yes, I was always talking about CLs reader macro #' for FUNCTION.
> My point is that people who use #' can not convince me that they prefer
> Lisp-2 over Lisp-1.
> But I believe that some people really prefer Lisp-2 over Lisp-1, and
> that those people will spell out (function ...).
> A friend of mine is doing so.
Well, another datapoint for your survey:
I prefer Lisp-N over Lisp-1.
And I always use #' instead of spelling out FUNCTION.
I don't spell out QUOTE either.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 11, 11:47 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> André Thieme <······························@justmail.de> writes:
> > Yes, I was always talking about CLs reader macro #' for FUNCTION.
> > My point is that people who use #' can not convince me that they prefer
> > Lisp-2 over Lisp-1.
> > But I believe that some people really prefer Lisp-2 over Lisp-1, and
> > that those people will spell out (function ...).
> > A friend of mine is doing so.
>
> Well, another datapoint for your survey:
>
> I prefer Lisp-N over Lisp-1.
> And I always use #' instead of spelling out FUNCTION.
> I don't spell out QUOTE either.
>
> --
> Thomas A. Russ, USC/Information Sciences Institute
same here
The only person I know who routinely eschews the ' and #' reader
macros is Pascal B.
In addition, I think common lisp strikes a happy medium by allowing
lambdas in function position while still enjoying the benefits of lisp-
n-ness.
On May 9, 3:25 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ·····@franz.com schrieb:
>
> > On May 9, 2:52 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> But not for (foo [1 2 3])
>
> > Yes, this is the kind of exceptional execution that Lisp-1 forces.
>
> Agreed.
>
> Also one potential „danger” with Lisp-1 is to have a function F with a
> parameter P shadowing a function, and where we later want to call the
> function P, then we need to remember that P must be renamed, and each
> use of it in the body of F needs to be changed as well.
> A good editor could help us, but right now I am not aware of an editor
> that is prepared for that.
> I would like: underline or colorize each use of parameters of the
> function one is currently editing. In that case we could see that map
> in (map ...) is suddenly underlined.
>
> >>>> Especially people who sometimes use #' instead of funcall.
> >>> I'm not sure what you mean here.
> >> Sorry, a typo. #' vs function.
>
> > OK, now that I know what you mean, I don't understand what the problem
> > is. Though possibly confusing because #' means something completely
> > different in Clojure than in CL, it is the case that in CL there is
> > _no_ difference between #'foo and (function foo) - one is a character
> > macro for the other. What is your issue with it?
>
> Yes, I was always talking about CLs reader macro #' for FUNCTION.
> My point is that people who use #' can not convince me that they prefer
> Lisp-2 over Lisp-1.
> But I believe that some people really prefer Lisp-2 over Lisp-1, and
> that those people will spell out (function ...).
> A friend of mine is doing so.
>
>
>
> >>>> And users of the lambda macro can't convince me that they prefer Lisp-2
> >>>> over Lisp-1. If they do, then there is always the function operator...
> >>> The fundamental argument for Lisp-2 and higher is separation of
> >>> namespaces, especially for variables. I hate having to use lst as a
> >>> variable name because list is already in use.
> >> In principle being Lisp-1 can potentially result in parameter names in
> >> Clojure that are not perfect. In practice however this is not really a
> >> problem. For practical matters there are only few functions that work
> >> specfically with lists, have exactly one parameter which is supposed to
> >> be a list and then also have to call the function list.
> >> „list” is just a place holder here.
>
> >> Take a look athttp://code.google.com/p/clojure/source/browse/#svn/trunk/src/clj/clo...
> >> orhttp://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
>
> >> and see how often that „beautiful parameter names” argument is a problem.
>
> > This is why you are constantly accused of marketing Clojure; this
> > looks like just another ruse to get people to look at Clojure code.
> > Performing a search of "beautiful" generates no results. If you are
> > making a point, make it. Otherwise leave unexplained references to
> > code out of the conversation.
>
> Duane sorry, but this is a false claim from you.
> This has absolutely nothing to do with marketing. I understand the
> psychology behind those accusing people, but I must reject that as
> indefensible.
> And btw, I did not ask you to search for "beautiful".
> People here in c.l.l. who prefer Lisp-2 over Lisp-1 told me several
> times that Lisp-1 leads to bad parameter names. I would like that those
> people back up their claims.
> What wonders me: why don't people in the Clojure mailing list constantly
> complain about this? My impression is: the Lisp-2 folks try to make an
> issue out of something that in practise is not very visible.
> I feel as if they put lipstick on the pig.. defending whatever CL
> offers, just because it is CL.
>
> We can find many thousand lines of this Lisp-onish Clojure code online.
> I don't say that it never ever has those naming problems. But nearly all
> the functions we can find simply don't have this problem.
> But: lots of functions pass function objects in their calls. Some take
> other functions as their arguments and call them. The Lisp-1 code is
> full of that.
> I just linked to material to support my claim. How can we try to talk at
> least minimally objectively when I am not even allowed to post links to
> non-CL code to back up what I say, and ask others to use that material
> to point me to problems I am not aware of?
> Sorry, but this stinks a bit.
> If you really found that my quote above was about marketing, then I must
> say that I see a very big misfiring of your neuros. Your pattern matcher
> (brain) produced a false positive.
>
> You are one of the most moderate posters here in c.l.l. I don't want to
> believe that you are willing to go the route of the more emotional
> people with less self-control, and just shout out the killer argument
> "marketing" to shut up any discussion.
> Okay, next:
>
> >> Anyway, how about FUNCTION, respectively a reader macro?
>
> > What about function? What is the question here?
>
> Oki, I did not put enough information into my question. I meant:
> do you also see a way to get rid of the special operator function?
> Can Clojure be made a Lisp-2 without having to mark functions that
> one wants to pass?
> Such as (reduce + coll) vs (reduce (function +) coll).
>
> >> Would things like (map √ coll) need to become (map $√ coll) or even
> >> (map (function √) coll)? That would break even more code.
>
> > Break what code? Existing code? Potential code? It is simply the
> > case that how the language is defined will determine how users can
> > program in it. The question is whether the language is consistent and
> > intuitive as to how it defines itself.
>
> If Rich Hickey wants to follow the idea of making Clojure a Lisp-2, is
> there then a way how he can do that by not breaking code?
> If he finds a way to make it a Lisp-2 without having the need of the
> function FUNCALL or the special operator FUNCTION (or its Lisp-onish
> reader macro #', here in my example marked by a $ sign as #' already
> has a different meaning in Clojure), then no code would break.
>
> >> If there is a solution that won't break (pratically 100% of) existing
> >> programs then I wouldn't object.
>
> > Hyperbole. Just above you were saying that you didn't care between
> > Lisp-1 and Lisp-n. I'm not interested in arguing hyperbole with you.
>
> Probably a misunderstanding. Maybe I did not clearly express myself.
> If Rich Hickey can make Clojure a Lisp-2 in such a way that
> (reduce + coll) will continue to work after the change, then no code
> would break.
> You already explained that there are technical ways to get rid of
> FUNCALL. I didn't know that. I thought that it would be required if
> one would like to do things like:
> (defun foo (list)
> (funcall list list))
>
> (foo #'identity)
>
> But I'll take your word for it right now. So, for now let's see FUNCALL
> as eliminated. Good, so my resistance against Clojure becoming a Lisp-2
> is reduced.
> But the more important issue is that (reduce + coll) can stay the way it
> is and does not need to become (reduce (function +) coll) or with some
> reader macro support something like (reduce $+ coll).
> Provided there is also a way that (reduce + coll) can stay unchanged,
> then I won't object anymore. Then let Clojure become a Lisp-2.
> The need for FUNCTION and FUNCALL are my only objections I have against
> Lisp-2.
> Hope this time I was more clear.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
I don't know where to throw this into this conversation, but...
If you look in this pdf:
www.dreamsongs.com/NewFiles/Hopl2.pdf
(A pretty good read!)
On the bottom of page 32, you will see this quote
> If a Lisp has separate namespaces for variables and functions, users are
> allowed to use variable names that also name functions, because the evaluation rules specify the
> namespace in which to look for the meaning. In a Lisp with a single namespace, the user must
> be careful when creating variable names that he isn’t shadowing a function name. //This issue is
> important for macros, which in effect must carefully decide what a free variable is intended to
> mean//. Because the variable and function namespaces are where the real problems lie, this debate
> is often referred to as the “Lisp-1 versus Lisp-2” debate.
So the issue with a Lisp-1 then is if you are importing someone else's
macro (or a macro you haven't looked at in a while),
you could be shadowing a function in your code with one of the
variables in the macro (either at macro-expansion time or at
evaluation time),
and it would not be apparent in the code.
It looks like Clojure uses a form of hygienic macros to get around
this issue, (?)
··················@gmail.com schrieb:
> On May 9, 3:25 pm, André Thieme <address.good.until.
> ···········@justmail.de> wrote:
> I don't know where to throw this into this conversation, but...
>
> If you look in this pdf:
> www.dreamsongs.com/NewFiles/Hopl2.pdf
> (A pretty good read!)
> On the bottom of page 32, you will see this quote
>
>> If a Lisp has separate namespaces for variables and functions, users are
>> allowed to use variable names that also name functions, because the evaluation rules specify the
>> namespace in which to look for the meaning. In a Lisp with a single namespace, the user must
>> be careful when creating variable names that he isn’t shadowing a function name. //This issue is
>> important for macros, which in effect must carefully decide what a free variable is intended to
>> mean//. Because the variable and function namespaces are where the real problems lie, this debate
>> is often referred to as the “Lisp-1 versus Lisp-2” debate.
>
> So the issue with a Lisp-1 then is if you are importing someone else's
> macro (or a macro you haven't looked at in a while),
> you could be shadowing a function in your code with one of the
> variables in the macro (either at macro-expansion time or at
> evaluation time),
> and it would not be apparent in the code.
>
> It looks like Clojure uses a form of hygienic macros to get around
> this issue, (?)
Yes. I don't know if this protects from all cases, but the typical ones
can't accidently occur.
The backquote (also called "syntax-quote") has the effect of translating
free symbols into fully qualified ones, i.e. ones that include the
namespace. So if we say `(list ...) this reader macro will produce then
(clojure.core/list ...).
This also helps catching potential bugs:
(defmacro foo [x]
`(let [y (+ ~x 10)]
(println y)))
When we now call (foo 1) it will throw an Exception:
Can't let qualified name: our-namespace/y
The compiler can report those cases where we most likely wanted to use
a gensym'ed var. For that purpose we can use the postfix reader macro #:
(defmacro foo [x]
`(let [y# (+ ~x 10)]
(println y#)))
André
--
André Thieme wrote:
> In principle being Lisp-1 can potentially result in parameter names in
> Clojure that are not perfect. In practice however this is not really a
> problem.
From http://www.research.att.com/~bs/bs_faq.html#compare
"I also worry about a phenomenon I have repeatedly observed in honest
attempts at language comparisons. The authors try hard to be impartial,
but are hopelessly biased by focusing on a single application, a single
style of programming, or a single culture among programmers. Worse, when
one language is significantly better known than others, a subtle shift
in perspective occurs: Flaws in the well-known language are deemed minor
and simple workarounds are presented, whereas similar flaws in other
languages are deemed fundamental. Often, the workarounds commonly used
in the less-well-known languages are simply unknown to the people doing
the comparison or deemed unsatisfactory because they would be unworkable
in the more familiar language."
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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 schrieb:
> André Thieme wrote:
>> In principle being Lisp-1 can potentially result in parameter names in
>> Clojure that are not perfect. In practice however this is not really a
>> problem.
>
> From http://www.research.att.com/~bs/bs_faq.html#compare
>
> "I also worry about a phenomenon I have repeatedly observed in honest
> attempts at language comparisons. The authors try hard to be impartial,
> but are hopelessly biased by focusing on a single application, a single
> style of programming, or a single culture among programmers. Worse, when
> one language is significantly better known than others, a subtle shift
> in perspective occurs: Flaws in the well-known language are deemed minor
> and simple workarounds are presented, whereas similar flaws in other
> languages are deemed fundamental. Often, the workarounds commonly used
> in the less-well-known languages are simply unknown to the people doing
> the comparison or deemed unsatisfactory because they would be unworkable
> in the more familiar language."
Yes thanks, good point. CL is significantly better known than Clojure,
in this news group and I think in generel.
And yes, Lisp-1 gets deemed unsatisfactory here by some, because it
would be unworkable in the more familar CL.
The guy from that website just posted his personal opinion, but yes, I
can observe the behaviour he described here in c.l.l.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
André Thieme wrote:
> Pascal Costanza schrieb:
>> André Thieme wrote:
>>> In principle being Lisp-1 can potentially result in parameter names in
>>> Clojure that are not perfect. In practice however this is not really a
>>> problem.
>>
>> From http://www.research.att.com/~bs/bs_faq.html#compare
>>
>> "I also worry about a phenomenon I have repeatedly observed in honest
>> attempts at language comparisons. The authors try hard to be
>> impartial, but are hopelessly biased by focusing on a single
>> application, a single style of programming, or a single culture among
>> programmers. Worse, when one language is significantly better known
>> than others, a subtle shift in perspective occurs: Flaws in the
>> well-known language are deemed minor and simple workarounds are
>> presented, whereas similar flaws in other languages are deemed
>> fundamental. Often, the workarounds commonly used in the
>> less-well-known languages are simply unknown to the people doing the
>> comparison or deemed unsatisfactory because they would be unworkable
>> in the more familiar language."
>
> Yes thanks, good point. CL is significantly better known than Clojure,
> in this news group and I think in generel.
> And yes, Lisp-1 gets deemed unsatisfactory here by some, because it
> would be unworkable in the more familar CL.
>
> The guy from that website just posted his personal opinion, but yes, I
> can observe the behaviour he described here in c.l.l.
Do you actually see that the quote above applies to you as to anybody else?
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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 schrieb:
> André Thieme wrote:
>> Pascal Costanza schrieb:
>>> André Thieme wrote:
>>>> In principle being Lisp-1 can potentially result in parameter names in
>>>> Clojure that are not perfect. In practice however this is not really a
>>>> problem.
>>>
>>> From http://www.research.att.com/~bs/bs_faq.html#compare
>>>
>>> "I also worry about a phenomenon I have repeatedly observed in honest
>>> attempts at language comparisons. The authors try hard to be
>>> impartial, but are hopelessly biased by focusing on a single
>>> application, a single style of programming, or a single culture among
>>> programmers. Worse, when one language is significantly better known
>>> than others, a subtle shift in perspective occurs: Flaws in the
>>> well-known language are deemed minor and simple workarounds are
>>> presented, whereas similar flaws in other languages are deemed
>>> fundamental. Often, the workarounds commonly used in the
>>> less-well-known languages are simply unknown to the people doing the
>>> comparison or deemed unsatisfactory because they would be unworkable
>>> in the more familiar language."
>>
>> Yes thanks, good point. CL is significantly better known than Clojure,
>> in this news group and I think in generel.
>> And yes, Lisp-1 gets deemed unsatisfactory here by some, because it
>> would be unworkable in the more familar CL.
>>
>> The guy from that website just posted his personal opinion, but yes, I
>> can observe the behaviour he described here in c.l.l.
>
> Do you actually see that the quote above applies to you as to anybody else?
Sounds confusing - the article talks about programming languages, not
about persons. CL is in c.l.l. significantly better known.
I had the hope you posted that quote as a mirror for you and some
other posters here. But I understand that this group of people won't
admit that they are the ones who are doing what the quote describes.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
André Thieme wrote:
> Pascal Costanza schrieb:
>> André Thieme wrote:
>>> Pascal Costanza schrieb:
>>>> André Thieme wrote:
>>>>> In principle being Lisp-1 can potentially result in parameter names in
>>>>> Clojure that are not perfect. In practice however this is not really a
>>>>> problem.
>>>>
>>>> From http://www.research.att.com/~bs/bs_faq.html#compare
>>>>
>>>> "I also worry about a phenomenon I have repeatedly observed in
>>>> honest attempts at language comparisons. The authors try hard to be
>>>> impartial, but are hopelessly biased by focusing on a single
>>>> application, a single style of programming, or a single culture
>>>> among programmers. Worse, when one language is significantly better
>>>> known than others, a subtle shift in perspective occurs: Flaws in
>>>> the well-known language are deemed minor and simple workarounds are
>>>> presented, whereas similar flaws in other languages are deemed
>>>> fundamental. Often, the workarounds commonly used in the
>>>> less-well-known languages are simply unknown to the people doing the
>>>> comparison or deemed unsatisfactory because they would be unworkable
>>>> in the more familiar language."
>>>
>>> Yes thanks, good point. CL is significantly better known than Clojure,
>>> in this news group and I think in generel.
>>> And yes, Lisp-1 gets deemed unsatisfactory here by some, because it
>>> would be unworkable in the more familar CL.
>>>
>>> The guy from that website just posted his personal opinion, but yes, I
>>> can observe the behaviour he described here in c.l.l.
>>
>> Do you actually see that the quote above applies to you as to anybody
>> else?
>
> Sounds confusing - the article talks about programming languages, not
> about persons. CL is in c.l.l. significantly better known.
> I had the hope you posted that quote as a mirror for you and some
> other posters here. But I understand that this group of people won't
> admit that they are the ones who are doing what the quote describes.
To clarify: We are all doing this.
The important part is to be aware of that.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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 May 8, 9:00 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ·····@franz.com schrieb:
>
>
>
> > On May 2, 11:44 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> Pascal Costanza schrieb:
>
> >>> André Thieme wrote:
> >>> There are enough people who think that a Lisp-2, or Lisp-n, is superior
> >>> to a Lisp-1, among other reasons because they make macros more reliable.
> >>> To me, whenever a new Lisp dialect comes out that chooses to go the
> >>> Lisp-1 route, this seems like a major step back to me.
> >> I think that is also about personal preference.
> >> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
> >> pass functions around and call them.
>
> > Be careful how strongly opposed to Lisp-n you are. At the ILC09
> > tutorial I went up to Rich Hickey and asked hom what his reasons were
> > for selecting Lisp-1, and his answer was "I just want to allow
> > arbitrary things to be in the functional position in a list". I
> > pointed out that yes, CL doesn't allow arbitrary items in the first
> > position in a list, but only because of how it's specified. But a case
> > could be made in a Lisp that is not CL for spefying that to evaluate
> > a list one could take the first element and if it is a symbol, use its
> > function cell, or otherwise assume it is a call-able value and just
> > call it. It would certainly satisfy Hickey's goal of allowing any
> > arbitrary value in the functional position. This was during a break,
> > and RH seemed interested in the concept but we never finished
> > discussing it because the break was over and he had to continue the
> > discussion.
>
> > So as you take a strong stand based on what Clojure does, be careful.
> > Who knows? Clojure could change out from under you and embarrass you a
> > little...
>
> I just wanted to write something similar in another post in this thread,
> but the opposit way around.
> I believe that some people defend Lisp-2 simply because that is the way
> of CL. I think that if there exists a parallel universe in which CL is a
> Lisp-1 then some of those hardcore Lisp-2 advocates in this universe
> would argue in favour of Lisp-1.
> Especially people who sometimes use #' instead of funcall.
> And users of the lambda macro can't convince me that they prefer Lisp-2
> over Lisp-1. If they do, then there is always the function operator...
>
> I certainly prefer Lisp-1 over Lisp-2. And I doubt that Clojure will
> soon require a funcall and thus breaking close to 100% of all existing
> Clojure programs.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
But some people really think Lisp-2 is better, for example me.
My arguments are: you can use the same name for a variable and a
function which relate to the same thing and don't get confused (look
how in CLojure 'a' is prepended to a lot of names, because you can't
do that in Lisp-1). Second, it clearly outlines, where the function
name is. It is very important when you pass a lot of functions around
(as I'm used to doing). Actually, I'm rather scared, when I see some
code, like Haskell's "map even [1 2 3]". It's ok for even, but if it's
some other common name? That's why, IMO, Lisp-2 is better. Can you
provide the same arguments for Lisp-1? That everything can be in
function position of a list? I think, Duane has answered that (I as
well once before argued for such a thing). Btw, do you know, that in
CL ((lambda (x) (1+ x) 1) will work and return 2. So that's more than
half of the problem solved. Surely you can't do (:a map) like in
Clojure. But that's not really a problem of Lisp-2, but of CL. Any
other arguments?
Best regards,
Vsevolod
Vsevolod Dyomkin schrieb:
> On May 8, 9:00 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
> But some people really think Lisp-2 is better, for example me.
> My arguments are: you can use the same name for a variable and a
> function [...]
And that is fine for me. I don't say that Lisp-1 or Lisp-n is
�better� in general. For some cases both have objective advantages.
The advantage that you get also means, at least in CL that you will
need (funcall ...) and (function ...).
That just blows the code up.
Why don't we put each object into a call of identity?
(+ (identity 8) (identity 19))
Okay, that comparison is not very good, because the Lisp-n nature
has the advantage you listed, while my identity example does not
bring interesting advantages.
However, it illustrates that the general idea of code is to be compact
and clear. Increasing the complexity of a code tree by adding another
level is typically not what we want. We don't want the most compact code
for every price - it must be human readable.
If you never use the #' reader macro, but instead always write down
(function ...), then I believe you - you really like Lisp-n more.
> which relate to the same thing and don't get confused (look
> how in CLojure 'a' is prepended to a lot of names, because you can't
> do that in Lisp-1).
I don't understand what you mean.
Do you believe that parameters of functions often have the letter �a� as
their prefix?
I am not aware of that. Especially the �a lot of names� confuses me.
> Second, it clearly outlines, where the function name is.
> It is very important when you pass a lot of functions around
> (as I'm used to doing). Actually, I'm rather scared, when I see some
> code, like Haskell's "map even [1 2 3]".
What about your editor? While you type in that expression the editor
can see if �even� is a parameter of the function and as such color it
differently, automatically.
I prefer (map even? [1 2 3]) over (map (function even?) [1 2 3])
The people who really prefer the Lisp-1 style invented the #' reader
macro, to clean up the code.
> It's ok for even, but if it's
> some other common name? That's why, IMO, Lisp-2 is better.
I am not convinced. But you said that this is your opinion, and I
respect it.
We could consider:
How many functions have the name of a data type?
How many functions are so general that they should name their parameters
like a function that happens to have the name of a datatype?
How many functions, that are so general that it makes sense to name
their parameter(s) like functions which have the name of datatypes need
actually to call that function, which is named as one of their parameters?
In my opinion parameters should get a meaningful name. Typically that
will not be the name of a datatype for which there exists a function,
that has exactly the same name.
But if only few functions ...
1) work specifically on an object of type XYZ
so that you want
2) to express their generality by naming the parameter they take also
XYZ
and where
3) XYZ is not only the name of the datatype but also of a function that
returns an instance of the datatype XYZ
and for which
4) those functions actually need to call XYZ
... then the feature of having many namespaces is not that big anymore.
And when we then keep in mind that in a functional programming style you
constantly pass around functions and call functions that came as args,
then this outweights the benefits.
It also happens when I write Clojure programs, but that is very rarely.
Way more typically it is that I pass functions around, create them on
the fly with the nice #(..) reader macro or call functions that came as
args.
I am interested to see results of a study that shows how many functions
really need those four points above, vs the number of ocurrences where
functions are passed or called (as a parameter in a function).
> Can you
> provide the same arguments for Lisp-1? That everything can be in
> function position of a list? I think, Duane has answered that (I as
> well once before argued for such a thing).
I am not so certain about Duanes argument. He maybe was thinking through
this issue and has good answers, but I am still thinking about some open
questions. Have a look at those 4 functions:
CL-USER> (defun foo1 (list)
(list list))
FOO1
CL-USER> (defun foo2 (list)
(list #'list))
FOO2
CL-USER> (defun foo3 (list)
(funcall list list))
FOO3
CL-USER> (defun foo4 (list)
(funcall list #'list))
FOO4
Let' call them and passing the identity function. We will see four
different results:
CL-USER> (foo1 #'identity) ==> (#<SYSTEM-FUNCTION IDENTITY>)
CL-USER> (foo2 #'identity) ==> (#<SYSTEM-FUNCTION LIST>)
CL-USER> (foo3 #'identity) ==> #<SYSTEM-FUNCTION IDENTITY>
CL-USER> (foo4 #'identity) ==> #<SYSTEM-FUNCTION LIST>
If we now don't have a funcall for Clojure-2 as Duane suggests, how
would then the Clojure function look like that produces the results
of foo3 and foo4?
> Btw, do you know, that in CL ((lambda (x) (1+ x) 1) will work and return 2.
Yes.
> So that's more than half of the problem solved.
Not really. Scan Clojure code that you can find online. Such as Clojure
itself, Clojure Contrib or some other open source code on bitbucket or
github. You will rarely see how someone is doing
((fn [x] (foo x)) 123).
Most of the time people would just do (foo 123) instead.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
The important thing you forgot about is *let*.
Besides, PJB very relevantly mentioned purely functional languages. My
example from Haskell is not so bad there, because of the much lesser
use of explicit function arguments in it (although let bindings are
still possible). In point-free languages I guess it's not a problem at
all.
Btw, have you read the warnings for languages like Python: "don't use
import package, but from package import symbol"? That's because in not
namespace-separated languages name collisions happen much more often.
And besides it's harder to warn the programmer on function
redefinition -- while in CL it's standard practice.
Speaking about #': for me it's a great vehicle of outlining in the
code where function names are used. So I use #' over function, and
definitely prefer it to the style, where there's no indication,
whether you are using a variable or a function name.
Speaking about Clojure's a-predending: I remember it from my small
endeavor into the source code, when I was looking for places, where
locks are used (from our previous discussion). The most outstanding
example should be aseq (and Java's counterpart ASeq). Besides, there
are a lot of array functions (like amap, aget etc), which I've as well
confused into this case (my error: now I understand, that they are not
relevant to this issue).
On funcall: I didn't see, where Duane suggested not to have funcall.
He just described a different to CL approach to treating first
position of a list, possible with Lisp-2 strategy.
But, overall, I'd say this is very much a question of stylistic, not
fundamental preference. Both approaches are viable and have their
merits and peculiarities. If only the Lisp-2 one allows to have CL-
style macros, I'd surely choose it. But if it's possible to provide
them robustly as well in Lisp-1 (which Clojure will or will not show
after some period of heavy use): ok, I can live with it two. ;)
Best regards
Vsevolod
Vsevolod Dyomkin <········@gmail.com> wrote:
+---------------
| On funcall: I didn't see, where Duane suggested not to have funcall.
| He just described a different to CL approach to treating first
| position of a list, possible with Lisp-2 strategy.
+---------------
Though note that permitting the functional position in CL to be any
function-returning expression trivally *allows* one to eliminate the
built-in FUNCALL function, to wit:
(funcall sexp args...) === ((progn sexp) args...)
But of course, CL *is* the world-renowned "big ball of mud", so even
if such general functional expressions in the CAR of a list were added
to all the major and/or popular CLs, I daresay that FUNCALL would still
remain anyway for compatibility, legacy code, stylistic choice, etc.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On 2009-05-10, Rob Warnock <····@rpw3.org> wrote:
> Vsevolod Dyomkin <········@gmail.com> wrote:
> +---------------
>| On funcall: I didn't see, where Duane suggested not to have funcall.
>| He just described a different to CL approach to treating first
>| position of a list, possible with Lisp-2 strategy.
> +---------------
>
> Though note that permitting the functional position in CL to be any
> function-returning expression trivally *allows* one to eliminate the
> built-in FUNCALL function, to wit:
Which is of no use if the applicator you want is something else,
like APPLY, or MAPCAR.
(defun lisp-1-func (foo &rest args)
(apply other-func foo args))
Oops.
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| Rob Warnock <····@rpw3.org> wrote:
| > Vsevolod Dyomkin <········@gmail.com> wrote:
| > +---------------
| >| On funcall: I didn't see, where Duane suggested not to have funcall.
| >| He just described a different to CL approach to treating first
| >| position of a list, possible with Lisp-2 strategy.
| > +---------------
| >
| > Though note that permitting the functional position in CL to be any
| > function-returning expression trivally *allows* one to eliminate the
| > built-in FUNCALL function, to wit:
|
| Which is of no use if the applicator you want is something else,
| like APPLY, or MAPCAR.
|
| (defun lisp-1-func (foo &rest args)
| (apply other-func foo args))
|
| Oops.
+---------------
Non-sequitor. APPLY is here a symbol in the CAR of the form,
so the classic rule for symbols in the functional position
applies [pardon the pun].
Now if you're asking how to *implement* APPLY, well, that's another
question entirely, but one which also has nothing to do with FUNCALL.
One should remember that, in Lisp, APPLY is primitive, not FUNCALL,
and in fact the canonical definition of FUNCALL is simply:
(defun funcall (function &rest args)
(apply function args))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Andr� Thieme <······························@justmail.de> writes:
> In my opinion parameters should get a meaningful name. Typically that
> will not be the name of a datatype for which there exists a function,
> that has exactly the same name.
There are a lot of words that are both verb and noun. Even in
languages where verbs have different forms than nounds, attributes
(nouns) are also often made accessor functions, so the collision
between a parameter name and a function occurs naturally and often.
> ... then the feature of having many namespaces is not that big anymore.
> And when we then keep in mind that in a functional programming style you
> constantly pass around functions and call functions that came as args,
> then this outweights the benefits.
Of course, the problem would be mut in a purely functional language
that is variableless. (See Backus' paper).
--
__Pascal Bourguignon__
André Thieme <······························@justmail.de> writes:
> If you never use the #' reader macro, but instead always write down
> (function ...), then I believe you - you really like Lisp-n more.
What could that possibly have to do with anything? Perhaps I just think
#' is cuter.
I always use #', and I prefer a Lisp-n (for reasons of (DEFUN (LIST)
(LIST LIST))). Convince me I don't.
On May 9, 1:41 pm, Vsevolod Dyomkin <········@gmail.com> wrote:
> code, like Haskell's "map even [1 2 3]". It's ok for even, but if it's
> some other common name? That's why, IMO, Lisp-2 is better.
That's the common argument: that you may use "list" for the name of a
list data without lexically overwriting the associated function.
Being a Unixer as well as a Lisper, I don't mind that as I tend to
always write list arguments as ls or xs (Haskell influence)
anyway... :P
> well once before argued for such a thing). Btw, do you know, that in
> CL ((lambda (x) (1+ x) 1) will work and return 2. So that's more than
> half of the problem solved.
* (((lambda (x) (lambda (y) (+ x y))) 3) 4)
; in: LAMBDA NIL
; (((LAMBDA (X) (LAMBDA (Y) (+ X Y))) 3) 4)
;
; caught ERROR:
; illegal function call
not enough for full applicative-style programming. :)
On May 10, 11:43 pm, namekuseijin <············@gmail.com> wrote:
> On May 9, 1:41 pm, Vsevolod Dyomkin <········@gmail.com> wrote:
>
> > code, like Haskell's "map even [1 2 3]". It's ok for even, but if it's
> > some other common name? That's why, IMO, Lisp-2 is better.
>
> That's the common argument: that you may use "list" for the name of a
> list data without lexically overwriting the associated function.
> Being a Unixer as well as a Lisper, I don't mind that as I tend to
> always write list arguments as ls or xs (Haskell influence)
> anyway... :P
>
> > well once before argued for such a thing). Btw, do you know, that in
> > CL ((lambda (x) (1+ x) 1) will work and return 2. So that's more than
> > half of the problem solved.
>
> * (((lambda (x) (lambda (y) (+ x y))) 3) 4)
> ; in: LAMBDA NIL
> ; (((LAMBDA (X) (LAMBDA (Y) (+ X Y))) 3) 4)
> ;
> ; caught ERROR:
> ; illegal function call
>
> not enough for full applicative-style programming. :)
I agree that the limitation on forms in operator position should be
lifted. But your code is not legal in CL and we all know that. It is
equivalent to (+ "x is " 42). Does that mean that CL is not good for
string programming? No. On top of that, many "functional" programs
tend to reach a level of obfuscation similar to a mix of Perl and APL.
Cheers
--
Marco
Marco Antoniotti escreveu:
> On top of that, many "functional" programs
> tend to reach a level of obfuscation similar to a mix of Perl and APL.
LOL, true. They are lacking s-expressions... ;)
--
a game sig: http://tinyurl.com/d3rxz9
On May 10, 5:43 pm, namekuseijin <············@gmail.com> wrote:
> On May 9, 1:41 pm, Vsevolod Dyomkin <········@gmail.com> wrote:
>
> > code, like Haskell's "map even [1 2 3]". It's ok for even, but if it's
> > some other common name? That's why, IMO, Lisp-2 is better.
>
> That's the common argument: that you may use "list" for the name of a
> list data without lexically overwriting the associated function.
> Being a Unixer as well as a Lisper, I don't mind that as I tend to
> always write list arguments as ls or xs (Haskell influence)
> anyway... :P
>
> > well once before argued for such a thing). Btw, do you know, that in
> > CL ((lambda (x) (1+ x) 1) will work and return 2. So that's more than
> > half of the problem solved.
>
> * (((lambda (x) (lambda (y) (+ x y))) 3) 4)
> ; in: LAMBDA NIL
> ; (((LAMBDA (X) (LAMBDA (Y) (+ X Y))) 3) 4)
> ;
> ; caught ERROR:
> ; illegal function call
>
> not enough for full applicative-style programming. :)
Why /would/ that work.
If it did work,
it would be completely ruining evaluation rules for no reason other
than to be 'full applicative programming'.
If anything, funcall is good because it keeps you from doing stuff
like this.
··················@gmail.com writes:
> On May 10, 5:43�pm, namekuseijin <············@gmail.com> wrote:
>> On May 9, 1:41�pm, Vsevolod Dyomkin <········@gmail.com> wrote:
>>
>> > code, like Haskell's "map even [1 2 3]". It's ok for even, but if it's
>> > some other common name? That's why, IMO, Lisp-2 is better.
>>
>> That's the common argument: �that you may use "list" for the name of a
>> list data without lexically overwriting the associated function.
>> Being a Unixer as well as a Lisper, I don't mind that as I tend to
>> always write list arguments as ls or xs (Haskell influence)
>> anyway... :P
>>
>> > well once before argued for such a thing). Btw, do you know, that in
>> > CL ((lambda (x) (1+ x) 1) will work and return 2. So that's more than
>> > half of the problem solved.
>>
>> * (((lambda (x) (lambda (y) (+ x y))) 3) 4)
>> ; in: LAMBDA NIL
>> ; � � (((LAMBDA (X) (LAMBDA (Y) (+ X Y))) 3) 4)
>> ;
>> ; caught ERROR:
>> ; � illegal function call
>>
>> not enough for full applicative-style programming. :)
>
> Why /would/ that work.
> If it did work,
> it would be completely ruining evaluation rules for no reason other
> than to be 'full applicative programming'.
>
> If anything, funcall is good because it keeps you from doing stuff
> like this.
How so?
(funcall (funcall (lambda (x) (lambda (y) (+ x y))) 3) 4) --> 7
--
__Pascal Bourguignon__
On May 11, 7:59 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> ··················@gmail.com writes:
> > On May 10, 5:43 pm, namekuseijin <············@gmail.com> wrote:
> >> On May 9, 1:41 pm, Vsevolod Dyomkin <········@gmail.com> wrote:
>
> >> > code, like Haskell's "map even [1 2 3]". It's ok for even, but if it's
> >> > some other common name? That's why, IMO, Lisp-2 is better.
>
> >> That's the common argument: that you may use "list" for the name of a
> >> list data without lexically overwriting the associated function.
> >> Being a Unixer as well as a Lisper, I don't mind that as I tend to
> >> always write list arguments as ls or xs (Haskell influence)
> >> anyway... :P
>
> >> > well once before argued for such a thing). Btw, do you know, that in
> >> > CL ((lambda (x) (1+ x) 1) will work and return 2. So that's more than
> >> > half of the problem solved.
>
> >> * (((lambda (x) (lambda (y) (+ x y))) 3) 4)
> >> ; in: LAMBDA NIL
> >> ; (((LAMBDA (X) (LAMBDA (Y) (+ X Y))) 3) 4)
> >> ;
> >> ; caught ERROR:
> >> ; illegal function call
>
> >> not enough for full applicative-style programming. :)
>
> > Why /would/ that work.
> > If it did work,
> > it would be completely ruining evaluation rules for no reason other
> > than to be 'full applicative programming'.
>
> > If anything, funcall is good because it keeps you from doing stuff
> > like this.
>
> How so?
>
> (funcall (funcall (lambda (x) (lambda (y) (+ x y))) 3) 4) --> 7
>
> --
> __Pascal Bourguignon__
or:
((lambda (x) ((lambda (y) (+ x y)) 4) )3) --> 7
On May 11, 12:54 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On May 11, 7:59 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>
>
> > ··················@gmail.com writes:
> > > On May 10, 5:43 pm, namekuseijin <············@gmail.com> wrote:
> > >> On May 9, 1:41 pm, Vsevolod Dyomkin <········@gmail.com> wrote:
>
> > >> > code, like Haskell's "map even [1 2 3]". It's ok for even, but if it's
> > >> > some other common name? That's why, IMO, Lisp-2 is better.
>
> > >> That's the common argument: that you may use "list" for the name of a
> > >> list data without lexically overwriting the associated function.
> > >> Being a Unixer as well as a Lisper, I don't mind that as I tend to
> > >> always write list arguments as ls or xs (Haskell influence)
> > >> anyway... :P
>
> > >> > well once before argued for such a thing). Btw, do you know, that in
> > >> > CL ((lambda (x) (1+ x) 1) will work and return 2. So that's more than
> > >> > half of the problem solved.
>
> > >> * (((lambda (x) (lambda (y) (+ x y))) 3) 4)
> > >> ; in: LAMBDA NIL
> > >> ; (((LAMBDA (X) (LAMBDA (Y) (+ X Y))) 3) 4)
> > >> ;
> > >> ; caught ERROR:
> > >> ; illegal function call
>
> > >> not enough for full applicative-style programming. :)
>
> > > Why /would/ that work.
> > > If it did work,
> > > it would be completely ruining evaluation rules for no reason other
> > > than to be 'full applicative programming'.
>
> > > If anything, funcall is good because it keeps you from doing stuff
> > > like this.
>
> > How so?
>
> > (funcall (funcall (lambda (x) (lambda (y) (+ x y))) 3) 4) --> 7
>
> > --
> > __Pascal Bourguignon__
>
> or:
> ((lambda (x) ((lambda (y) (+ x y)) 4) )3) --> 7
Those actually illustrate my point, rather than refuting it.
When evaluating a lisp program you apply the car to the (evaluated)
cdr, right?
>(((lambda (x) (lambda (y) (+ x y))) 3) 4)
Does not do this (it (appears to) apply the evaluated car, to the
(evaluated?) cdr).
The examples with fun-call and nested lambdas are consistent with car/
cdr application-recursion. (As long as we accept the lambda-macro for
what it is).
I guess the point is your program becomes needlessly complicated when
you are recurseing on both the car and the cdr.
Sorry if i was unclear.
On May 11, 1:56 pm, ··················@gmail.com wrote:
> When evaluating a lisp program you apply the car to the (evaluated)
> cdr, right?
>
> >(((lambda (x) (lambda (y) (+ x y))) 3) 4)
>
> Does not do this (it (appears to) apply the evaluated car, to the
> (evaluated?) cdr).
Only if you see the lambda expression as a form to be evaluated rather
than the "name" of an otherwise anonymous function. See Kent Pitman's
post wrt this up thread.
On May 11, 3:35 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On May 11, 1:56 pm, ··················@gmail.com wrote:
>
> > When evaluating a lisp program you apply the car to the (evaluated)
> > cdr, right?
>
> > >(((lambda (x) (lambda (y) (+ x y))) 3) 4)
>
> > Does not do this (it (appears to) apply the evaluated car, to the
> > (evaluated?) cdr).
>
> Only if you see the lambda expression as a form to be evaluated rather
> than the "name" of an otherwise anonymous function. See Kent Pitman's
> post wrt this up thread.
(^ ((lambda (x) (lambda (y) (+ x y))) 3)
4)
~=
(defun fn (x) (lambda (y) (+ x y)))
((fn 3) 4)
You've got function that returns a function, then you apply 4 to the
returned function.
(carrot denotes where the internal function ends up)
This is why funcall is nice, it makes things explicit.
(funcall (funcall #'(lambda (x)
#'(lambda (y) (+ x y))) 3)
4)
Any way you slice it, you're evaluating the car.
(not that there's anything wrong with that...)
On May 11, 4:30 pm, ··················@gmail.com wrote:
> On May 11, 3:35 pm, Raffael Cavallaro <················@gmail.com>
> wrote:
>
> > On May 11, 1:56 pm, ··················@gmail.com wrote:
>
> > > When evaluating a lisp program you apply the car to the (evaluated)
> > > cdr, right?
>
> > > >(((lambda (x) (lambda (y) (+ x y))) 3) 4)
>
> > > Does not do this (it (appears to) apply the evaluated car, to the
> > > (evaluated?) cdr).
>
> > Only if you see the lambda expression as a form to be evaluated rather
> > than the "name" of an otherwise anonymous function. See Kent Pitman's
> > post wrt this up thread.
>
> (^ ((lambda (x) (lambda (y) (+ x y))) 3)
> 4)
> ~=
> (defun fn (x) (lambda (y) (+ x y)))
> ((fn 3) 4)
>
> You've got function that returns a function, then you apply 4 to the
> returned function.
>
> (carrot denotes where the internal function ends up)
>
> This is why funcall is nice, it makes things explicit.
>
> (funcall (funcall #'(lambda (x)
> #'(lambda (y) (+ x y))) 3)
> 4)
>
> Any way you slice it, you're evaluating the car.
> (not that there's anything wrong with that...)
Again, see Kent Pitman's post on this. You call it evaluating the car,
but it is really just naming a function by what it does - i.e., an
otherwise anonymous function. It's worth noting here that arbitrary
evaluations are *not* allowed, only lambdas, i.e., only the lambda-
name of an anonymous function.
On May 11, 6:31 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On May 11, 4:30 pm, ··················@gmail.com wrote:
>
>
>
> > On May 11, 3:35 pm, Raffael Cavallaro <················@gmail.com>
> > wrote:
>
> > > On May 11, 1:56 pm, ··················@gmail.com wrote:
>
> > > > When evaluating a lisp program you apply the car to the (evaluated)
> > > > cdr, right?
>
> > > > >(((lambda (x) (lambda (y) (+ x y))) 3) 4)
>
> > > > Does not do this (it (appears to) apply the evaluated car, to the
> > > > (evaluated?) cdr).
>
> > > Only if you see the lambda expression as a form to be evaluated rather
> > > than the "name" of an otherwise anonymous function. See Kent Pitman's
> > > post wrt this up thread.
>
> > (^ ((lambda (x) (lambda (y) (+ x y))) 3)
> > 4)
> > ~=
> > (defun fn (x) (lambda (y) (+ x y)))
> > ((fn 3) 4)
>
> > You've got function that returns a function, then you apply 4 to the
> > returned function.
>
> > (carrot denotes where the internal function ends up)
>
> > This is why funcall is nice, it makes things explicit.
>
> > (funcall (funcall #'(lambda (x)
> > #'(lambda (y) (+ x y))) 3)
> > 4)
>
> > Any way you slice it, you're evaluating the car.
> > (not that there's anything wrong with that...)
>
> Again, see Kent Pitman's post on this. You call it evaluating the car,
> but it is really just naming a function by what it does - i.e., an
> otherwise anonymous function. It's worth noting here that arbitrary
> evaluations are *not* allowed, only lambdas, i.e., only the lambda-
> name of an anonymous function.
so you are saying that
>((lambda (x) (lambda (y) (+ x y))) 3)
Is the name of an anonymous function equivalent to:
(lambda (y) (+ 3 y))
?
(That seems to be evaluation to me).
I don't really care what you call it, I don't see how it is useful...
(Aside from providing for awesome possibilities of obfuscation,
which I will use along with my caret shaped carrots,
to finally make my code truly unreadable,
and obtain real ultimate power).
I will note, however, that it is really easy to write an eval that
evaluates the car of the list.
One has to wonder why they didn't.
··················@gmail.com writes:
> On May 11, 6:31��pm, Raffael Cavallaro wrote:
> so you are saying that
>
> >((lambda (x) (lambda (y) (+ x y))) 3)
>
> Is the name of an anonymous function equivalent to:
> (lambda (y) (+ 3 y))
> ?
No. He is saying that
(lambda (x) (lambda (y) (+ x y)))
is the "name" of an anonymous function that, when applied to an
argument, will return an anonymous function that adds that argument to
its argument.
(lambda (y) (+ 3 y))
is the result of that application.
> (That seems to be evaluation to me).
The evaluation is in the application of the function to the argument 3.
The other aspect is merely the lookup of the function. If it helps, you
can think of the lambda form as just being an immediate representation
of the function code, rather than its name.
> I don't really care what you call it, I don't see how it is useful...
Odd. Lots of people find it useful to have anonymous functions when
they are only needed in a single location. It saves them from having to
make up unique names or introducing a temporary binding (say, via FLET)
for such functions.
Global names would either be rather long, or else somewhat uninformative
with various numeric suffixes, which would have to be kept straight:
f-0001, f-0002, etc.
FLET functions would almost always be named "F". =:-o
> (Aside from providing for awesome possibilities of obfuscation,
> which I will use along with my caret shaped carrots,
> to finally make my code truly unreadable,
> and obtain real ultimate power).
>
> I will note, however, that it is really easy to write an eval that
> evaluates the car of the list.
> One has to wonder why they didn't.
I'm not sure why they didn't, so I can only speculate.
Note that Duane Rettig indicated that evaluation of the first place of
an applicable form was, in fact possible even with Lisp-N namespaces.
It just involves a different mechanism for the lookup.
Some possible reasons would be:
* Error checking on well-formedness of S-expressions.
* Consistency, since a symbol would use a different lookup semantics
as a function name than as a function argument argument, so general
evaluation of that position wasn't the same.
* Efficiency. The expectation that function names are more stable
than variable values, allowing for more efficient invocation and a more
reasonable argument for block compilation and in-lining of code.
Particularly since early lisp systems didn't have lexical scope.
* No perceived need. Figuring that dynamically generated functions
wasn't something that one would really be doing very much. And a
general evaluation mechanism only makes sense if you expect to have
actual forms such as function calls in the first position.
* Parsimony. APPLY already existed, so there wasn't really any need
for fancy evaluation of the first argument position. In fact, APPLY was
needed very early on in order to allow building an evaluator. So, why
make the function lookup rules more complicated than necessary?
* Page limit. There wasn't any more room in the Lisp 1.5 manual to
describe more complicated lookup rules. (OK, I'm joking with this one).
* Nobody thought of it.
I'm sure there are some other possible motivations as well. Perhaps
some other people would like to add their speculations.
Now I know this won't satisfy you, but as Kent Pitman observed, there
are a lot of design choices available in language design. Just because
one language makes one choice and a different language makes a different
choice doesn't make either one of them wrong. They are just alternate
points in the design space.
Since many of us are happy (or at least content) with this set of
features, we really don't see a compelling reason to change, and we have
a fair set of reasons for liking the decision that was made.
--
Thomas A. Russ, USC/Information Sciences Institute
On May 11, 8:23 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> ··················@gmail.com writes:
> > On May 11, 6:31 pm, Raffael Cavallaro wrote:
> > so you are saying that
>
> > >((lambda (x) (lambda (y) (+ x y))) 3)
>
> > Is the name of an anonymous function equivalent to:
> > (lambda (y) (+ 3 y))
> > ?
>
> No. He is saying that
>
> (lambda (x) (lambda (y) (+ x y)))
>
> is the "name" of an anonymous function that, when applied to an
> argument, will return an anonymous function that adds that argument to
> its argument.
>
> (lambda (y) (+ 3 y))
>
> is the result of that application.
>
Ok, this is how I had initially interpreted it.
I was trying to get to the bottom of Raffael's post.
The lambda when when applied to the arguments returns a function,
makes sense.
> > (That seems to be evaluation to me).
>
> The evaluation is in the application of the function to the argument 3.
> The other aspect is merely the lookup of the function. If it helps, you
> can think of the lambda form as just being an immediate representation
> of the function code, rather than its name.
>
Right. I understand that a lambda is an anonymous function.
The example that stemmed my confusion, however, was saying that this:
(((lambda (x) (lambda (y) (+ x y))) 3) 4)
Was going to be executable code.
Which implied (to me) that we were going to apply (lambda (x)..) to 3,
and then apply that to 4.
Which again implied to me that we are going to recursively evaluate
the car of the list.
> > I don't really care what you call it, I don't see how it is useful...
>
Anonymous functions are very useful, of course.
The ability to nest anonymous functions and apply them all in-line,
however...
it seems I would just write one function most of the time.
> Odd. Lots of people find it useful to have anonymous functions when
> they are only needed in a single location. It saves them from having to
> make up unique names or introducing a temporary binding (say, via FLET)
> for such functions.
>
Right. I've done it myself.
Although I will admit that for more complicated things I'll generally
construct a few functions in a labels or Flet and then use them rather
than nesting anonymous lambdas.
> Global names would either be rather long, or else somewhat uninformative
> with various numeric suffixes, which would have to be kept straight:
> f-0001, f-0002, etc.
> FLET functions would almost always be named "F". =:-o
>
> > (Aside from providing for awesome possibilities of obfuscation,
> > which I will use along with my caret shaped carrots,
> > to finally make my code truly unreadable,
> > and obtain real ultimate power).
>
> > I will note, however, that it is really easy to write an eval that
> > evaluates the car of the list.
> > One has to wonder why they didn't.
>
> I'm not sure why they didn't, so I can only speculate.
>
> Note that Duane Rettig indicated that evaluation of the first place of
> an applicable form was, in fact possible even with Lisp-N namespaces.
> It just involves a different mechanism for the lookup.
>
> Some possible reasons would be:
> * Error checking on well-formedness of S-expressions.
> * Consistency, since a symbol would use a different lookup semantics
> as a function name than as a function argument argument, so general
> evaluation of that position wasn't the same.
> * Efficiency. The expectation that function names are more stable
> than variable values, allowing for more efficient invocation and a more
> reasonable argument for block compilation and in-lining of code.
> Particularly since early lisp systems didn't have lexical scope.
> * No perceived need. Figuring that dynamically generated functions
> wasn't something that one would really be doing very much. And a
> general evaluation mechanism only makes sense if you expect to have
> actual forms such as function calls in the first position.
> * Parsimony. APPLY already existed, so there wasn't really any need
> for fancy evaluation of the first argument position. In fact, APPLY was
> needed very early on in order to allow building an evaluator. So, why
> make the function lookup rules more complicated than necessary?
> * Page limit. There wasn't any more room in the Lisp 1.5 manual to
> describe more complicated lookup rules. (OK, I'm joking with this one).
> * Nobody thought of it.
>
> I'm sure there are some other possible motivations as well. Perhaps
> some other people would like to add their speculations.
>
I contemplated some of these myself; it was partially a rhetorical
question and partly of interest.
I was personally wondering if having only functions in the car of
lists would make machine optimization easier. (Might make it easier to
trace all of the function dependencies).
> Now I know this won't satisfy you, but as Kent Pitman observed, there
> are a lot of design choices available in language design. Just because
> one language makes one choice and a different language makes a different
> choice doesn't make either one of them wrong. They are just alternate
> points in the design space.
>
As I said, I'm not against anonymous functions, I'm against doubly
nested anonymous functions being applied without explicit function-
application. (Which as far as I know isn't in the language :-D )
> Since many of us are happy (or at least content) with this set of
> features, we really don't see a compelling reason to change, and we have
> a fair set of reasons for liking the decision that was made.
I don't see a reason to change it either.
··················@gmail.com writes:
> Right. I understand that a lambda is an anonymous function.
> The example that stemmed my confusion, however, was saying that this:
>
> (((lambda (x) (lambda (y) (+ x y))) 3) 4)
>
> Was going to be executable code.
> Which implied (to me) that we were going to apply (lambda (x)..) to 3,
> and then apply that to 4.
> Which again implied to me that we are going to recursively evaluate
> the car of the list.
Ah. I see what you were getting at.
You are currect, that form is not legal Common Lisp, since the first
lambda application (to the argument 3) will not happen. Instead it
would have to be written as
(funcall ((lambda (x) (lambda (y) (+ x y))) 3) 4)
--
Thomas A. Russ, USC/Information Sciences Institute
On 11 maio, 20:25, ··················@gmail.com wrote:
> On May 11, 6:31 pm, Raffael Cavallaro <················@gmail.com>
> wrote:
>
>
>
> > On May 11, 4:30 pm, ··················@gmail.com wrote:
>
> > > On May 11, 3:35 pm, Raffael Cavallaro <················@gmail.com>
> > > wrote:
>
> > > > On May 11, 1:56 pm, ··················@gmail.com wrote:
>
> > > > > When evaluating a lisp program you apply the car to the (evaluated)
> > > > > cdr, right?
>
> > > > > >(((lambda (x) (lambda (y) (+ x y))) 3) 4)
>
> > > > > Does not do this (it (appears to) apply the evaluated car, to the
> > > > > (evaluated?) cdr).
>
> > > > Only if you see the lambda expression as a form to be evaluated rather
> > > > than the "name" of an otherwise anonymous function. See Kent Pitman's
> > > > post wrt this up thread.
>
> > > (^ ((lambda (x) (lambda (y) (+ x y))) 3)
> > > 4)
> > > ~=
> > > (defun fn (x) (lambda (y) (+ x y)))
> > > ((fn 3) 4)
>
> > > You've got function that returns a function, then you apply 4 to the
> > > returned function.
>
> > > (carrot denotes where the internal function ends up)
>
> > > This is why funcall is nice, it makes things explicit.
>
> > > (funcall (funcall #'(lambda (x)
> > > #'(lambda (y) (+ x y))) 3)
> > > 4)
>
> > > Any way you slice it, you're evaluating the car.
> > > (not that there's anything wrong with that...)
>
> > Again, see Kent Pitman's post on this. You call it evaluating the car,
> > but it is really just naming a function by what it does - i.e., an
> > otherwise anonymous function. It's worth noting here that arbitrary
> > evaluations are *not* allowed, only lambdas, i.e., only the lambda-
> > name of an anonymous function.
>
> so you are saying that
>
> >((lambda (x) (lambda (y) (+ x y))) 3)
>
> Is the name of an anonymous function equivalent to:
> (lambda (y) (+ 3 y))
> ?
>
> (That seems to be evaluation to me).
>
> I don't really care what you call it, I don't see how it is useful...
>
> (Aside from providing for awesome possibilities of obfuscation,
> which I will use along with my caret shaped carrots,
> to finally make my code truly unreadable,
> and obtain real ultimate power).
>
> I will note, however, that it is really easy to write an eval that
> evaluates the car of the list.
> One has to wonder why they didn't.
Maybe some disagreement on how it should be treated? Back in 80's
there was a lisp called Mulisp in which you could write something like
this:
(defun fact (n)
((< n 2) 1)
(* (fact (1- n)) n))
so that all defuns worked as if they had an implicit cond around its
code.
On May 11, 8:54 pm, gugamilare <··········@gmail.com> wrote:
> On 11 maio, 20:25, ··················@gmail.com wrote:
...
> > I will note, however, that it is really easy to write an eval that
> > evaluates the car of the list.
> > One has to wonder why they didn't.
Not all language design is about what is easy to implement. Sometimes
there is philosophy involved, and believe it or not, it is possible
for there to be more than one self-consistent philosophy. Indeed, the
Lisp1/Lisp2 debate plays out in the meta, and is really when you're
all done with it, a debate about whether there can be not two
namespaces but two philosophies. The Lisp1 camp often seems
correlated with the set of people who don't admit the right of other
people to think differently, while the Lisp2 camp seems to me
correlated with the set of people who happily live together in a
pluralistic society that tolerates multiple models happily. The Lisp1
crew seems to express almost a need to coerce others into their point
of view against their will, while the Lisp2 crew isn't interested in
coercing anyone, they just want their right to deviate in point of
view--it's more an issue of self-preservation. This is a political/
moral/philosophical asymmetry that is not often given its due in
discussion.
> Maybe some disagreement on how it should be treated? Back in 80's
> there was a lisp called Mulisp in which you could write something like
> this:
>
> (defun fact (n)
> ((< n 2) 1)
> (* (fact (1- n)) n))
>
> so that all defuns worked as if they had an implicit cond around its
> code.
Indeed. And I can tell you the history of this since I discussed this
with Al Rich, who designed MuLisp. MuMath (by David Stoutemeyer, I
believe--I hope I got the spelling right) was built on MuLisp, and the
MuLisp/MuMath people were good friends of the Macsyma people, where I
worked. So we were at an informal get-together at a conference one
time and Al Rich was telling the truly amazing story of how MuLisp was
written. (He was unemployed and had only the computer, no terminal,
and wrote/debugged it all from the console switches, reading results
off the flashy register lights, and I have the impression having to
maybe even re-key the entire thing from the toggle switches if the
power went out.) He had learned Lisp himself from example code he'd
seen somewhere and had made some strange assumptions based on things
he observed, one of which was that there was never an occurrence [he
thought] of double-open parens in the language, so he thought it would
be fun to use that for something useful [in part to save space; they
had such tiny memory that every byte counted, and they didn't want to
waste the cons required for putting cond on the front of a cond
clause]. I had an animal program I'd written. I didn't invent
animal, but I liked the program and had written one in BASIC in high
school and had ported it to Maclisp in college... (longer story there
I'll skip though some of it is probably at http://www.maclisp.info/animal)
... Anyway, I wrote an animal program for him at the party, just for
grins, to see how his Lisp worked. And it kept blowing up on an
undefined function lambda. It took us a while puzzling to realize he
had no idea what lambda was--it had never come up--and especially no
idea what a lambda combination was. So he thought I was doing a call
to some ordinary function lambda, perhaps like APL's iota function.
No, I explained there was a long tradition of this lambda thing in
Lisp, and so I think he probably put in a special case for it
later ... (by this time he had a console and source code and I think
didn't have the problems I mentioned earlier. heh... that was just a
money thing.) So I guess in some circuitous way, if ((lambda...) ...)
is there at all in MuLisp, I can claim credit for it. There are other
elements of this story I'll tell for another day, but they're not
relevant to this discussion. I'll just say the world is very
strangely interconnected sometimes.
--=-=-=
··················@gmail.com writes:
> (^ ((lambda (x) (lambda (y) (+ x y))) 3)
> 4)
> ~=
> (defun fn (x) (lambda (y) (+ x y)))
> ((fn 3) 4)
>
> You've got function that returns a function, then you apply 4 to the
> returned function.
>
> (carrot denotes where the internal function ends up)
Brilliant! But I'm afraid my system doesn't seem to have the unicode
symbol for a carrot and merely shows a caret. :-(
Rupert
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iJwEAQECAAYFAkoIqpIACgkQRtd/pJbYVobRCgP/Tcz35NAAdp5Ic/yrlVsSSCY+
pdtLjPJtOflMN9bunL/ViVIfVa86j8cqdjrFhu7bfMEnmK5H3TXGPey6sVM+G21n
CNJ9nW0aYwBdH3z1QTklYQASujT3fCp5jMy6TgNuYJKxjSL+2Y2Ctajpnde0E/mR
mJiGbUUP80LpCps84BY=
=/J70
-----END PGP SIGNATURE-----
--=-=-=--
On May 11, 6:45 pm, Rupert Swarbrick <··········@gmail.com> wrote:
> > (^ ((lambda (x) (lambda (y) (+ x y))) 3)
> > 4)
> > ~=
> > (defun fn (x) (lambda (y) (+ x y)))
> > ((fn 3) 4)
>
> > You've got function that returns a function, then you apply 4 to the
> > returned function.
>
> > (carrot denotes where the internal function ends up)
>
> Brilliant! But I'm afraid my system doesn't seem to have the unicode
> symbol for a carrot and merely shows a caret. :-(
>
> Rupert
>
> application_pgp-signature_part
> < 1KViewDownload
You should see some of my hideous variable names.
Raffael Cavallaro <················@gmail.com> wrote:
+---------------
| ··················@gmail.com wrote:
| > When evaluating a lisp program you apply the car to the (evaluated)
| > cdr, right?
| > > (((lambda (x) (lambda (y) (+ x y))) 3) 4)
| > Does not do this (it (appears to) apply the evaluated car, to the
| > (evaluated?) cdr).
|
| Only if you see the lambda expression as a form to be evaluated rather
| than the "name" of an otherwise anonymous function. See Kent Pitman's
| post wrt this up thread.
+---------------
Whereas I for one *do* "see the lambda expression as a form to be
evaluated" rather than a name!! [See my reply to Kent's up thread.]
But also being a Lisp2 [or LispN] proponent, it also wouldn't bother
me if one had to write the above this way in CL: ;-}
(funcall (funcall (lambda (x) (lambda (y) (+ x y))) 3) 4)
Conversely, it also wouldn't bother me if all of the major CL
implementations started allowing other arbitrary function-value-returning
forms in the CAR of a function application form [in addition to
LAMBDA expressions]. It's just more mud for the ball... ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On May 11, 10:07 pm, ····@rpw3.org (Rob Warnock) wrote:
> Conversely, it also wouldn't bother me if all of the major CL
> implementations started allowing other arbitrary function-value-returning
> forms in the CAR of a function application form [in addition to
> LAMBDA expressions]. It's just more mud for the ball... ;-}
I agree entirely on this one - the more mud the better!
On May 12, 1:02 am, Raffael Cavallaro <················@gmail.com>
wrote:
> On May 11, 10:07 pm, ····@rpw3.org (Rob Warnock) wrote:
>
> > Conversely, it also wouldn't bother me if all of the major CL
> > implementations started allowing other arbitrary function-value-returning
> > forms in the CAR of a function application form [in addition to
> > LAMBDA expressions]. It's just more mud for the ball... ;-}
>
> I agree entirely on this one - the more mud the better!
I think people have a hard enough time understanding Lisp semantics.
Lisp1 and Lisp2 semantics have reasonable philosophical explanations.
Mixing them would make a mess and make it harder to defend, IMO.
On May 12, 2:30 pm, ······@nhplace.com wrote:
> On May 12, 1:02 am, Raffael Cavallaro <················@gmail.com>
> wrote:
>
> > On May 11, 10:07 pm, ····@rpw3.org (Rob Warnock) wrote:
>
> > > Conversely, it also wouldn't bother me if all of the major CL
> > > implementations started allowing other arbitrary function-value-returning
> > > forms in the CAR of a function application form [in addition to
> > > LAMBDA expressions]. It's just more mud for the ball... ;-}
>
> > I agree entirely on this one - the more mud the better!
>
> I think people have a hard enough time understanding Lisp semantics.
> Lisp1 and Lisp2 semantics have reasonable philosophical explanations.
> Mixing them would make a mess and make it harder to defend, IMO.
With respect, I think that the "consistent semantics" ship sailed a
very long time ago for common lisp. It's quite clearly a multi-
paradigm language, and that's a good thing. It's confusing only if one
approaches it expecting a jewel-like, TOOWTDI design.
A language as lumpy as common lisp only improves when more
capabilities are added. No one is required to use additional features,
and as long as they are backward compatible, I think additional
features are a win.
On 12 Mag, 23:49, Raffael Cavallaro <················@gmail.com>
wrote:
> On May 12, 2:30 pm, ······@nhplace.com wrote:
>
> > On May 12, 1:02 am, Raffael Cavallaro <················@gmail.com>
> > wrote:
>
> > > On May 11, 10:07 pm, ····@rpw3.org (Rob Warnock) wrote:
>
> > > > Conversely, it also wouldn't bother me if all of the major CL
> > > > implementations started allowing other arbitrary function-value-returning
> > > > forms in the CAR of a function application form [in addition to
> > > > LAMBDA expressions]. It's just more mud for the ball... ;-}
>
> > > I agree entirely on this one - the more mud the better!
>
> > I think people have a hard enough time understanding Lisp semantics.
> > Lisp1 and Lisp2 semantics have reasonable philosophical explanations.
> > Mixing them would make a mess and make it harder to defend, IMO.
>
> With respect, I think that the "consistent semantics" ship sailed a
> very long time ago for common lisp. It's quite clearly a multi-
> paradigm language, and that's a good thing. It's confusing only if one
> approaches it expecting a jewel-like, TOOWTDI design.
>
> A language as lumpy as common lisp only improves when more
> capabilities are added. No one is required to use additional features,
> and as long as they are backward compatible, I think additional
> features are a win.
I second that!
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
Andr� Thieme wrote:
> ·····@franz.com schrieb:
>> On May 2, 11:44 am, Andr� Thieme <address.good.until.
>> ···········@justmail.de> wrote:
>>> Pascal Costanza schrieb:
>>>
>>>> Andr� Thieme wrote:
>>>> There are enough people who think that a Lisp-2, or Lisp-n, is superior
>>>> to a Lisp-1, among other reasons because they make macros more
>>>> reliable.
>>>> To me, whenever a new Lisp dialect comes out that chooses to go the
>>>> Lisp-1 route, this seems like a major step back to me.
>>> I think that is also about personal preference.
>>> For Clojure Lisp-1 makes more sense in my opinion, as it is typical to
>>> pass functions around and call them.
>>
>> Be careful how strongly opposed to Lisp-n you are. At the ILC09
>> tutorial I went up to Rich Hickey and asked hom what his reasons were
>> for selecting Lisp-1, and his answer was "I just want to allow
>> arbitrary things to be in the functional position in a list". I
>> pointed out that yes, CL doesn't allow arbitrary items in the first
>> position in a list, but only because of how it's specified. But a case
>> could be made in a Lisp that is not CL for spefying that to evaluate
>> a list one could take the first element and if it is a symbol, use its
>> function cell, or otherwise assume it is a call-able value and just
>> call it. It would certainly satisfy Hickey's goal of allowing any
>> arbitrary value in the functional position. This was during a break,
>> and RH seemed interested in the concept but we never finished
>> discussing it because the break was over and he had to continue the
>> discussion.
>>
>> So as you take a strong stand based on what Clojure does, be careful.
>> Who knows? Clojure could change out from under you and embarrass you a
>> little...
>
> I just wanted to write something similar in another post in this thread,
> but the opposit way around.
> I believe that some people defend Lisp-2 simply because that is the way
> of CL. I think that if there exists a parallel universe in which CL is a
> Lisp-1 then some of those hardcore Lisp-2 advocates in this universe
> would argue in favour of Lisp-1.
Sure. You are all rational, while everybody else is irrational.
It's a very simple world.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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 schrieb:
> Andr� Thieme wrote:
>> I just wanted to write something similar in another post in this thread,
>> but the opposit way around.
>> I believe that some people defend Lisp-2 simply because that is the way
>> of CL. I think that if there exists a parallel universe in which CL is a
>> Lisp-1 then some of those hardcore Lisp-2 advocates in this universe
>> would argue in favour of Lisp-1.
>
> Sure. You are all rational, while everybody else is irrational.
>
> It's a very simple world.
Ah, Pascal Costanza replies to my post - that's a 90% guarantee that a
personal attack is made :)
Your answer is obviously irony. That means that you say that I am
irrational.
The consequence is that following the discussion is easier for you at
that point, because you put yourself into the position where you can
cherry pick what postings of me you can simply ignore as irrational.
It is more difficult to accept a discussian partner as okay.
I am aware that you and my other critics are good developers, in some
domains even experts and intelligent people. I like to talk to you
during some lisp meetings or conferences, as always nice.
It's just that sometimes I have the feeling we should leave the
personal stuff behind.
Anyway, back to the Lisp-1 vs Lisp-n issue: I don't see Lisp-n as
a big problem and admit that I can prefer it over Lisp-1 in some
cases. Objectively it has advantages over Lisp-1.
My personal preferrence is in general that I prefer Lisp-1, which
btw. also has objectively its advantages.
Now a discussion about those styles started, and I am not even
interested in that. There were enough discussions about that issue in
the past, and some days ago Duane suggested me to not repeat things.
Now we three are guilty to repeat to talk about an issue which has been
discussed deeply. I should not have said anything about Lisp-1/n and
not have quoted Dan, which I did to support my point that today the HS
would look different.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Andr� Thieme wrote:
> Pascal Costanza schrieb:
>> Andr� Thieme wrote:
>
>>> I just wanted to write something similar in another post in this thread,
>>> but the opposit way around.
>>> I believe that some people defend Lisp-2 simply because that is the way
>>> of CL. I think that if there exists a parallel universe in which CL is a
>>> Lisp-1 then some of those hardcore Lisp-2 advocates in this universe
>>> would argue in favour of Lisp-1.
>>
>> Sure. You are all rational, while everybody else is irrational.
>>
>> It's a very simple world.
>
> Ah, Pascal Costanza replies to my post - that's a 90% guarantee that a
> personal attack is made :)
> Your answer is obviously irony. That means that you say that I am
> irrational.
> The consequence is that following the discussion is easier for you at
> that point, because you put yourself into the position where you can
> cherry pick what postings of me you can simply ignore as irrational.
> It is more difficult to accept a discussian partner as okay.
How does "some of those hardcore Lisp-2 advocates" qualify as
considering discussion partners as "okay", especially when you suspect
them to change their opinions in arbitrary ways?
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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 May 2, 7:16 pm, Pascal Costanza <····@p-cos.net> wrote:
> There are enough people who think that a Lisp-2, or Lisp-n, is superior
> to a Lisp-1, among other reasons because they make macros more reliable.
>
> To me, whenever a new Lisp dialect comes out that chooses to go the
> Lisp-1 route, this seems like a major step back to me.
I wouldn't say that Lisp-1 is a major step back. Its more of a
consensus what is more important for the language designer(s) and
their needs. When I the problem calls for functional style, cl funcall
& #: is inconvenience, though far from showstopper. For the other
styles Lisp-2 is usually better choice. I really want to have list as
parameter and mean it something different than function list.
Bobi
http://slobodanblazeski.blogspot.com
Andr� Thieme <······························@justmail.de> wrote:
>I consider for example Common Lisp as ?out of date?.
...
>The CL standard does not explicitly support threading.
Hehe... that's almost as hilarious as those "C sucks because it can't do
graphics!" acts.
>Having separate "value cells" and "function cells" (to use the "street
>language" way of saying it) was one of the most unfortuanate issues.
No.
Enjoy your meal.
Andr� Thieme <...> writes:
> What criterias would a Lisp dialect have to fullfil to be called
> modern rightfully?
It should exhibit clear improvements in a variety of cases from current
praxis in the Lisp community. As a result, it may also make contemporary
dialects obsolete.
(Mind you, perhaps Clojure can be considered a modern language in the
field of parallel programming languages---I don't see myself in the
position to judge about that.)
-T.
bridgetrix <········@gmail.com> writes:
> Could anyone recommend a LISP environment? I have a ten-year old
> version of Harlequin on a PC and a 15-year-old version of MCL on a 120
> mh Mac clone. Are the Mac LISPs sufficiently better than the PC LISPs
> to justify buying a new Mac?
So a good LISP environment. The best would probably to find a 7090 in
working condition, but you'd need to have quite a budget for the
electricity bill. If that's not the case, you may use an emulator:
http://www.cozx.com/~dpitts/ibm7090.html
Then you can fetch the LISP 1.5 sources:
http://www.informatimago.com/develop/lisp/lisp15-0.0.2.tar.gz
and assemble them with the 7090 assembler, and boot it.
That would give you a good 47 years old LISP (1.5) environment. (*)
Now, if you prefer a good Common Lisp environment, you may use the
advices given in the other answers ;-)
(*): Probably with more required hand assembly and debugging.
--
__Pascal Bourguignon__