Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What gives you power in CL, that you don't have in other languages

41 views
Skip to first unread message

Dimiter "malkia" Stanev

unread,
Jan 27, 2009, 9:45:17 PM1/27/09
to
To me, as a newbie common-lisper (I am in my 2nd year - still wet
behind the ears), these are three of the many features that I simply
wished were in my daily-work languages (C++ and sons):
- The iteration cycle -- the best old idea - modify your
application as it runs. It's dirty, mostly non-deterministic, and you
might not be able to reproduce the same steps if you started again, but
hey - sometimes you just need to attach to your stuff change it on the
fly and keep going - without hefty restarts.
- Dynamic special variables -- the ability to "hook" and change
something deep, communicating with it through a *special* medium created
at lexical scope (binding). This is just too awesome to skip in other
languages! I miss it a lot! It's not a global variable really - it's
more than that literally!
- Multiple Value Returns -- and not like Python, where you need to
take care of not caring about values you do not care - this simply beats
everything else I've used! You can safely extend your API with cases
that you have not accounted for, and still the old code would work just
fine.
- The CLOS multiple-dispatch -- this is the best idea I've heard in
all the OO I did - combined with the eql matching - this is so much
needed techniquie - no more visitor pattern indeed. I've actually
grokked the visitor pattern, after I understood how the
multiple-dispatch works.

Off course there are others things: macroses, exception-handling, etc
and many others... But I'm still learning these, so I can't tell yet.


Kenneth Tilton

unread,
Jan 28, 2009, 12:56:29 AM1/28/09
to
Dimiter "malkia" Stanev wrote:
> To me, as a newbie common-lisper (I am in my 2nd year - still wet
> behind the ears), these are three of the many features that I simply
> wished were in my daily-work languages (C++ and sons):
> - The iteration cycle -- the best old idea - modify your
> application as it runs. It's dirty, mostly non-deterministic, and you
> might not be able to reproduce the same steps if you started again, but
> hey - sometimes you just need to attach to your stuff change it on the
> fly and keep going - without hefty restarts.
> - Dynamic special variables -- the ability to "hook" and change
> something deep, communicating with it through a *special* medium created
> at lexical scope (binding). This is just too awesome to skip in other
> languages! I miss it a lot! It's not a global variable really - it's
> more than that literally!

so far so good.

> - Multiple Value Returns -- and not like Python, where you need
> to take care of not caring about values you do not care - this simply
> beats everything else I've used! You can safely extend your API with
> cases that you have not accounted for, and still the old code would work
> just fine.
> - The CLOS multiple-dispatch -- this is the best idea I've heard
> in all the OO I did - combined with the eql matching - this is so much
> needed techniquie - no more visitor pattern indeed. I've actually
> grokked the visitor pattern, after I understood how the
> multiple-dispatch works.

two things that are indeed special and I use 0.1% of the time. Not sure
how that multiplies out.

>
> Off course there are others things: macroses, exception-handling,
> etc and many others... But I'm still learning these, so I can't tell yet.

Yes, it is a list, macros possibly being the only thing some other
language will not have. Hell, even Scheme does not have useful macros.

kth

GP lisper

unread,
Jan 27, 2009, 11:43:27 PM1/27/09
to
On Tue, 27 Jan 2009 18:45:17 -0800, <mal...@mac.com> wrote:
>What gives you power in CL, that you don't have in other languages

It's a blind men and the elephant situation. For instance:

> - Multiple Value Returns -- and not like Python, where you need to
> take care of not caring about values you do not care - this simply beats
> everything else I've used! You can safely extend your API with cases
> that you have not accounted for, and still the old code would work just
> fine.

I've done that, and until I read this, I never would have mentioned it
as a 'power' in that elephant.


--
Lisp : a multi-fetish language

Slobodan Blazeski

unread,
Jan 28, 2009, 3:27:32 AM1/28/09
to
On Jan 28, 3:45 am, "Dimiter \"malkia\" Stanev" <mal...@mac.com>
wrote:

Multiple value returns are something I really miss in C#, I could
mimic with references but it's not the same thing.
Lambda, very convenient.
High order functions.
...
Though other langauges have many of those, they are usually not well
integrated, unnatural and cumbersome to use. Something like making
octopus by adding extra legs to a dog.
So it's very important if language integrates some feature else nobody
will use it, except some experts in a pissing contests.


bobi

Robert Dodier

unread,
Jan 28, 2009, 12:01:48 PM1/28/09
to
The interesting, useful major feature of Lisp is that code = data.
Lots of other useful stuff derives from that.

Robert Dodier

java...@gmail.com

unread,
Jan 28, 2009, 1:28:49 PM1/28/09
to
On 28 Gen, 03:45, "Dimiter \"malkia\" Stanev" <mal...@mac.com> wrote:
> Lisp

The real unique distinctive of Lisp is that it's absolutely
invincible.
So you can either love it or hate (read: envy) it, but you can't beat
it...

Rainer Joswig

unread,
Jan 28, 2009, 2:00:47 PM1/28/09
to
In article
<f8636591-0b09-4d94...@z6g2000pre.googlegroups.com>,
Robert Dodier <robert...@gmail.com> wrote:

I would go back one step. The interesting, useful major
feature of Lisp is computing with symbolic expressions.


McCarty, 1960
'Recursive Functions of Symbolic Expressions
and Their Computation by Machine, Part I'

http://www-formal.stanford.edu/jmc/recursive.ps

It lists the following applications (page 22):

1. Writing a compiler to compile LISP programs into machine language.
2. Writing a program to check proofs in a class of formal logical systems.
3. Writing programs for formal differentiation and integration.
4. Writing programs to realize various algorithms for generating proofs in predicate calculus.
5. Making certain engineering calculations whose results are formulas rather than numbers.
6. Programming the Advice Taker system.


'code as data' is then an application of computing with symbol expressions.

--
http://lispm.dyndns.org/

guen...@gmail.com

unread,
Jan 28, 2009, 3:56:56 PM1/28/09
to

Indeed. Lisp has many advantages, but Multiple Value Returns is much
nicer done in FORTH (or other stack oriented languages?). Now FORTH
might be a good idea which time has come and gone and I don't really
miss stack counting, but it has some beauty to it.

Marek Kubica

unread,
Jan 28, 2009, 6:03:40 PM1/28/09
to
On Wed, 28 Jan 2009 12:56:56 -0800 (PST)
guen...@gmail.com wrote:

> Now FORTH might be a good idea which time has come and gone and I don't really
> miss stack counting, but it has some beauty to it.

I have tried Factor recently, a Factor/Lisp/Joy-inspired stack
language.. it is quite fun, although I have no idea how to get useful
stuff done with it.

regards,
Marek

William James

unread,
Jan 28, 2009, 7:17:56 PM1/28/09
to
java...@gmail.com wrote:

I've beaten it many times, but the religious zealots refused
to admit it.

Kenneth Tilton

unread,
Jan 28, 2009, 7:35:54 PM1/28/09
to

We prefer "savages".

hth,kxo

Message has been deleted

asan...@gmail.com

unread,
Jan 29, 2009, 5:45:32 AM1/29/09
to

It depends on what you call "useful".

-alex

Kenneth Tilton

unread,
Jan 29, 2009, 6:46:59 PM1/29/09
to

Here, I'll use it in a sentence:

"Anyone not clear on the meaning of useful would love writing macros in
Scheme."

hth,kth

Jon Harrop

unread,
Jan 30, 2009, 1:27:37 PM1/30/09
to
Dimiter "malkia" Stanev wrote:
> - Multiple Value Returns -- and not like Python, where you need to
> take care of not caring about values you do not care - this simply beats
> everything else I've used! You can safely extend your API with cases
> that you have not accounted for, and still the old code would work just
> fine.

Multiple values are handled much more elegantly in other languages, like
tuples in OCaml, Haskell and F#.

> - The CLOS multiple-dispatch -- this is the best idea I've heard in
> all the OO I did - combined with the eql matching - this is so much
> needed techniquie - no more visitor pattern indeed. I've actually
> grokked the visitor pattern, after I understood how the
> multiple-dispatch works.

Pattern matching is related but not a replacement for multiple dispatch that
you may like to look at.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Kaz Kylheku

unread,
Jan 30, 2009, 4:23:21 PM1/30/09
to
On 2009-01-30, Jon Harrop <j...@ffconsultancy.com> wrote:
> Dimiter "malkia" Stanev wrote:
>> - Multiple Value Returns -- and not like Python, where you need to
>> take care of not caring about values you do not care - this simply beats
>> everything else I've used! You can safely extend your API with cases
>> that you have not accounted for, and still the old code would work just
>> fine.
>
> Multiple values are handled much more elegantly in other languages, like
> tuples in OCaml, Haskell and F#.

Remember the song folks:

You can lead him to Lisp, but he sees just parentheses.
But syntax he likes looks like ve-ne-re-al disease.

Even if tuples in and of themselves are nice in these languages, the overall
syntax is indecipherable dog's breakfast that is more geared toward obfuscated
programming contests than real work.

Look at Haskell. The Haskell 98 spec has to use a special superscript notation
to collapse the million precedence levels. Any language in whose syntactic
specification there is a need to use variables over the domain of precedence
levels, and discuss them algebraically, should be tossed out the window by
anyone with a shred of sanity.

Jon Harrop

unread,
Jan 31, 2009, 8:19:43 PM1/31/09
to
Kaz Kylheku wrote:
> Even if tuples in and of themselves are nice in these languages, the
> overall syntax is indecipherable dog's breakfast that is more geared
> toward obfuscated programming contests than real work.

No reason why Lisp 3.0 cannot have decent support for tuples and do away
with cons cells, multiple value bind, values, separate namespaces and all
the other useless cruft.

Marco Antoniotti

unread,
Feb 1, 2009, 10:36:35 AM2/1/09
to
On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
> > Even if tuples in and of themselves are nice in these languages, the
> > overall syntax is indecipherable dog's breakfast that is more geared
> > toward obfuscated programming contests than real work.
>
> No reason why Lisp 3.0 cannot have decent support for tuples and do away
> with cons cells, multiple value bind, values, separate namespaces and all
> the other useless cruft.
>

But CL has support for tuples. We call them vectors. CONS cells are
there in any functional language that supports lists (I may be stupid,
but I fail to see what 1::[2; 3] is... also considering how this
operator is called in the OCaml manual). Multiple Value Bind can be
macroed away. Separate namespaces are an intriguing beast. I do
think that they are not all that needed, at least the one separating
functions from values, but then again, there are separate namespaces
in other languages as well.

Of course, your definition of "cruft" may vary. If you want to look
at some crufty code you can peruse a source file to be fed fed to
camlp4. Looks like the "look ma, no cons cells" has some drawbacks
after all. :)

Cheers
--
Marco


Tamas K Papp

unread,
Feb 1, 2009, 10:57:18 AM2/1/09
to

I think that lists built of cons cells are very neat, because Lisp
exposes the mechanism of constructing simple linked lists and you can
go under the hood if you prefer. I would never trade this for an
"abstract" list mechanism that has some interface for traversing the
list, but if one is bothered by cons cells, such a mechanism can be
easily implemented in Lisp. Again, the fact that it is not done
should be a hint.

I don't see why we should do away with multiple values. Tuples are
not a replacement, since functions that return multiple values can
behave as single-values functiond if the caller does not capture the
other values. Consider

(defun plot-function (function ...)
;; plots the univariate function
...)

(plot-function (lambda (x) (sin x)) ...)
(plot-function (lambda (x) (floor x)) ...)

With tuples, one would have to extract the first value of the tuple,
which is a nice pastime for F# programmers who love to waste their
time with patterns, but I don't really care for it.

Separate namespaces are something completely orthogonal to the issues
above. I personally like them and they don't bother me at all.

Tamas

Michael Ekstrand

unread,
Feb 1, 2009, 11:34:01 AM2/1/09
to
Marco Antoniotti <mar...@gmail.com> writes:
> On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Kaz Kylheku wrote:
>> > Even if tuples in and of themselves are nice in these languages, the
>> > overall syntax is indecipherable dog's breakfast that is more geared
>> > toward obfuscated programming contests than real work.
>>
>> No reason why Lisp 3.0 cannot have decent support for tuples and do away
>> with cons cells, multiple value bind, values, separate namespaces and all
>> the other useless cruft.
>>
>
> But CL has support for tuples. We call them vectors.

Vectors would be the CL equivalent of OCaml's arrays, not tuples.
Tuples are kind of their own thing without a direct CL conceptual
equivalent. Sometimes they're replaced by lists, sometimes multiple
value return. Sometimes cons cells are used where an OCaml programmer
would use 2-tuples.

> CONS cells are there in any functional language that supports lists (I
> may be stupid, but I fail to see what 1::[2; 3] is... also considering
> how this operator is called in the OCaml manual).

1::[2; 3] is (cons 1 '(2 3)). So yes, OCaml has cons cells with the
caveat that the cdr is only allowed to point to another cons cell or nil
(improper lists are prohibited).

- Michael

--
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files? I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

Marco Antoniotti

unread,
Feb 1, 2009, 2:44:58 PM2/1/09
to
On Feb 1, 5:34 pm, Michael Ekstrand <mich...@elehack.net> wrote:

> Marco Antoniotti <marc...@gmail.com> writes:
> > On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> >> Kaz Kylheku wrote:
> >> > Even if tuples in and of themselves are nice in these languages, the
> >> > overall syntax is indecipherable dog's breakfast that is more geared
> >> > toward obfuscated programming contests than real work.
>
> >> No reason why Lisp 3.0 cannot have decent support for tuples and do away
> >> with cons cells, multiple value bind, values, separate namespaces and all
> >> the other useless cruft.
>
> > But CL has support for tuples.  We call them vectors.
>
> Vectors would be the CL equivalent of OCaml's arrays, not tuples.
> Tuples are kind of their own thing without a direct CL conceptual
> equivalent.  Sometimes they're replaced by lists, sometimes multiple
> value return.  Sometimes cons cells are used where an OCaml programmer
> would use 2-tuples.

Yes. This is the fine print and everybody here - pardon my sarcasm,
not directed at you :) - is aware of that. (aren't we all?!?)

> > CONS cells are there in any functional language that supports lists (I
> > may be stupid, but I fail to see what 1::[2; 3] is... also considering
> > how this operator is called in the OCaml manual).
>
> 1::[2; 3] is (cons 1 '(2 3)). So yes, OCaml has cons cells with the
> caveat that the cdr is only allowed to point to another cons cell or nil
> (improper lists are prohibited).

Of course. I think people here are also aware of *that*... (again,
aren't we all?!?) :) You for sure are. I am, long time CLLers
are... :)

Cheers
--
Marco

Jon Harrop

unread,
Feb 1, 2009, 4:42:47 PM2/1/09
to
Tamas K Papp wrote:
> I think that lists built of cons cells are very neat, because Lisp
> exposes the mechanism of constructing simple linked lists and you can
> go under the hood if you prefer.

Can you elaborate with an example of what you mean by "going under the
hood"?

> I would never trade this for an
> "abstract" list mechanism that has some interface for traversing the
> list, but if one is bothered by cons cells, such a mechanism can be
> easily implemented in Lisp. Again, the fact that it is not done
> should be a hint.

That's some seriously flawed logic right there. Modern features do not get
successfully retrofitted onto Lisp because the people familiar with these
features never go back to Lisp and the few who continue to use Lisp remain
blissfully unaware of what they are missing out on.

Indeed, the confusion surrounding tuples in this thread would have
highlighted this your you had you known what tuples were used for. As it
is, you could only resort to considering far more people are choosing OCaml
and Haskell over Lisp.

> I don't see why we should do away with multiple values. Tuples are
> not a replacement, since functions that return multiple values can
> behave as single-values functiond if the caller does not capture the
> other values. Consider
>
> (defun plot-function (function ...)
> ;; plots the univariate function
> ...)
>
> (plot-function (lambda (x) (sin x)) ...)
> (plot-function (lambda (x) (floor x)) ...)
>
> With tuples, one would have to extract the first value of the tuple,
> which is a nice pastime for F# programmers who love to waste their
> time with patterns, but I don't really care for it.

That great "benefit" of silently dropping parts of your data.

> Separate namespaces are something completely orthogonal to the issues
> above. I personally like them and they don't bother me at all.

Ironically, the code you just wrote was needlessly obfuscated by this
ridiculous flaw in Lisp. Specifically, you used lambdas as a workaround for
separate namespaces.

In OCaml or F#, you just do:

plot sin
plot floor

because the "sin" function is just another variable (and floor doesn't
return the fractional part).

jos...@corporate-world.lisp.de

unread,
Feb 1, 2009, 5:27:48 PM2/1/09
to
On 1 Feb., 22:42, Jon Harrop <j...@ffconsultancy.com> wrote:

> Ironically, the code you just wrote was needlessly obfuscated by this
> ridiculous flaw in Lisp. Specifically, you used lambdas as a workaround for
> separate namespaces.
>
> In OCaml or F#, you just do:
>
>   plot sin
>   plot floor

(plot 'sin) or (plot #'sin) works fine.

>
> because the "sin" function is just another variable (and floor doesn't
> return the fractional part).

CL-USER 34 > (floor 3.5)
3
0.5

CL-USER 35 > (identity (floor 3.5))
3


Read a Lisp book before you post again.

Jon Harrop

unread,
Feb 1, 2009, 8:18:25 PM2/1/09
to
jos...@corporate-world.lisp.de wrote:
> On 1 Feb., 22:42, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Ironically, the code you just wrote was needlessly obfuscated by this
>> ridiculous flaw in Lisp. Specifically, you used lambdas as a workaround
>> for separate namespaces.
>>
>> In OCaml or F#, you just do:
>>
>> plot sin
>> plot floor
>
> (plot 'sin) or (plot #'sin) works fine.

Which is comparable verbosity to the destructuring that Tamas was referring
to.

>> because the "sin" function is just another variable (and floor doesn't
>> return the fractional part).
>
> CL-USER 34 > (floor 3.5)
> 3
> 0.5
>
> CL-USER 35 > (identity (floor 3.5))
> 3
>
> Read a Lisp book before you post again.

$ ocaml
Objective Caml version 3.10.2

# floor 2.3;;
- : float = 2.

Read the context before you post again.

Kaz Kylheku

unread,
Feb 1, 2009, 8:25:33 PM2/1/09
to
On 2009-02-01, Michael Ekstrand <mic...@elehack.net> wrote:
> Marco Antoniotti <mar...@gmail.com> writes:
>> On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>>> Kaz Kylheku wrote:
>>> > Even if tuples in and of themselves are nice in these languages, the
>>> > overall syntax is indecipherable dog's breakfast that is more geared
>>> > toward obfuscated programming contests than real work.
>>>
>>> No reason why Lisp 3.0 cannot have decent support for tuples and do away
>>> with cons cells, multiple value bind, values, separate namespaces and all
>>> the other useless cruft.
>>>
>>
>> But CL has support for tuples. We call them vectors.
>
> Vectors would be the CL equivalent of OCaml's arrays, not tuples.

Only restricted uses of vectors in CL are equivalent to OCaml arrays.

Don't forget that a vector in CL can have heterogeneous contents.

> Tuples are kind of their own thing without a direct CL conceptual
> equivalent.

When you write the syntax for a tuple, you're making something that might be
called an anonymous struct. It's compatible with other such structs that have
the same number of elements, of the same types, in the same order.

It is kind of to structs what lambda is to functions, loosely speaking.

It's not impossible to visualize a Lisp extension for this. Regular Lisp
structs are not anonymous. They are named, and use name equivalence. So they
can't be used directly. I don't see how anonymous structs like tuples would be
all that useful in Lisp. They have no reason to exists, because if you want to
represent a pair of values, which are integer and string, respectively, just
go ahead and use a vector or list:

#(123 "456") ;; effectively a tuple

Tuples are used in these autistic languages like Haskell and OCaml in
situations when the programmer wants a collection of values of heterogeneous
types, but the type system gets in the way of a vector or list being used.

The problem that tuples solve does not have a counterpart in Common Lisp.

>> CONS cells are there in any functional language that supports lists (I
>> may be stupid, but I fail to see what 1::[2; 3] is... also considering
>> how this operator is called in the OCaml manual).
>
> 1::[2; 3] is (cons 1 '(2 3)). So yes, OCaml has cons cells with the
> caveat that the cdr is only allowed to point to another cons cell or nil

You mean to another cons cell which holds an integer! Oops.

jos...@corporate-world.lisp.de

unread,
Feb 1, 2009, 8:35:36 PM2/1/09
to

You are in the wrong context. This is not fa.caml. This is c.l.l.

Both (plot 'sin) and (plot 'floor) work fine.
The lambdas in Tamas post were not needed and your
post about some namespace blabla is only babbling.
The LAMBDA macro is also not a workaround since it is not needed,
since the functions objects can be passed directly.

You should better work on your F# business instead of
wasting time with comp.lang.lisp.

Jon Harrop

unread,
Feb 3, 2009, 6:33:16 PM2/3/09
to
jos...@corporate-world.lisp.de wrote:
> On Feb 2, 2:18 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Read the context before you post again.
>
> You are in the wrong context. This is not fa.caml. This is c.l.l.

He explicitly drew a comparison with an ML.

> Both (plot 'sin) and (plot 'floor) work fine.
> The lambdas in Tamas post were not needed and your
> post about some namespace blabla is only babbling.
> The LAMBDA macro is also not a workaround since it is not needed,
> since the functions objects can be passed directly.
>
> You should better work on your F# business instead of
> wasting time with comp.lang.lisp.

Why are you so afraid of comparing Lisp and ML?

Jon Harrop

unread,
Feb 3, 2009, 7:02:35 PM2/3/09
to
Kaz Kylheku wrote:
> It's not impossible to visualize a Lisp extension for this.

All modern FPLs may be considered as very advanced extensions to Lisp.

> Regular Lisp
> structs are not anonymous. They are named, and use name equivalence. So
> they
> can't be used directly. I don't see how anonymous structs like tuples
> would be
> all that useful in Lisp. They have no reason to exists, because if you
> want to represent a pair of values, which are integer and string,
> respectively, just go ahead and use a vector or list:
>
> #(123 "456") ;; effectively a tuple

Your "tuple" incurs costly heap allocation when it is created and bounds
checks when it is read, precisely because it is incapable of conveying the
same information.

Multiple return values have another needlessly-separate representation in
Lisp that also has its own peculiar shortcomings.

Tuples unify all of these use cases without their shortcomings.

> Tuples are used in these autistic languages like Haskell and OCaml in
> situations when the programmer wants a collection of values of
> heterogeneous types,

That is incorrect. Tuples are not collections. They do not have push, pop,
add, take, length etc. because they have a fixed number of elements.

> but the type system gets in the way of a vector or list being used.

That is also incorrect. You can avoid tuples in ML if you wish, by using
lists or arrays, but it only serves to degrade the utility of the language
to that of Lisp.

> The problem that tuples solve does not have a counterpart in Common Lisp.

Because tuples convey information that Lisp is incapable of expressing.

For example, combining a tuple and list type allows ML to express a type
representing lists that contain at least one element:

'a * 'a list

Any attempt to create a container of this type with zero elements will be
caught at compile time as a static type error. Lisp is completely incapable
of this.

jos...@corporate-world.lisp.de

unread,
Feb 3, 2009, 7:05:54 PM2/3/09
to
On 4 Feb., 00:33, Jon Harrop <j...@ffconsultancy.com> wrote:
> jos...@corporate-world.lisp.de wrote:
> > On Feb 2, 2:18 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> >> Read the context before you post again.
>
> > You are in the wrong context. This is not fa.caml. This is c.l.l.
>
> He explicitly drew a comparison with an ML.
>
> > Both (plot 'sin) and (plot 'floor) work fine.
> > The lambdas in Tamas post were not needed and your
> > post about some namespace blabla is only babbling.
> > The LAMBDA macro is also not a workaround since it is not needed,
> > since the functions objects can be passed directly.
>
> > You should better work on your F# business instead of
> > wasting time with comp.lang.lisp.
>
> Why are you so afraid of comparing Lisp and ML?

You could also go to hubFS and help people having problems with your
book code (see for example 'Problem with F# for Scientists'
from jan 2nd) instead of wasting time here. Maybe that
would help to revive your business. Lisp is dead,
nothing to see here.


jos...@corporate-world.lisp.de

unread,
Feb 3, 2009, 7:16:20 PM2/3/09
to
On 4 Feb., 01:05, "jos...@corporate-world.lisp.de" <jos...@corporate-

I mean 1st feb.

Kaz Kylheku

unread,
Feb 3, 2009, 9:02:50 PM2/3/09
to
On 2009-02-04, Jon Harrop <j...@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> It's not impossible to visualize a Lisp extension for this.
>
> All modern FPLs may be considered as very advanced extensions to Lisp.

Or, reductions of.

>> #(123 "456") ;; effectively a tuple
>
> Your "tuple" incurs costly heap allocation when it is created and bounds
> checks when it is read, precisely because it is incapable of conveying the
> same information.

Which is probably why you wouldn't use it when you want multiple values,
right? Multiple values don't occur heap allocation. Period.

> Multiple return values have another needlessly-separate representation in
> Lisp that also has its own peculiar shortcomings.

Such as? Multiple values are the inverse of function arguments. Functions are
not restricted to take one argument. Why shouldn't they return multiple values?

M come in, N come out.

> Tuples unify all of these use cases without their shortcomings.

Tuples are just another type. A function that returns a tuple has a /single/
return value of tuple type. The caller has to deal with that tyle. There
may be syntactic sugar for that, but it doesn't change the fact.

It's like returning a struct in C:

struct foo { int x, char *s } foo(void)
{ return (struct foo) { 3, "foo" }; }

And yes, the compound literal is in fact C syntax now as of C99.

There you go, tuples in C. Statically typed and everything. So with the
above you can do:

printf("foo().s == %s\n", foo().s);

>> Tuples are used in these autistic languages like Haskell and OCaml in
>> situations when the programmer wants a collection of values of
>> heterogeneous types,
>
> That is incorrect. Tuples are not collections. They do not have push, pop,

Push and pop are thought of as destructive (this is cross-posted to
comp.lang.lisp!) A collection doesn't have to have such things to be a
collection. There could be functional push and pop, of course.

> add, take, length etc.

Length could be implemented; it would be a compile-time constant, along
the lines:

len (1, 2, 3) -> 3

adding an item could be a functional tuple -> tuple operation,
that returns a new tuple:

tuple-cons 1 ("foo", 2)

-> (1, "foo", 2)

tuple-rest (1, "foo", 2) -> ("foo", 2)

Perfectly consistent with the notion of tuples, statically typed and all.

Jon Harrop

unread,
Feb 3, 2009, 10:06:55 PM2/3/09
to
jos...@corporate-world.lisp.de wrote:
>> You could also go to hubFS and help people having problems with your
>> book code (see for example 'Problem with F# for Scientists'
>> from jan 2nd) instead of wasting time here.
>
> I mean 1st feb.

His problem seems to have been resolved in a few hours.

jos...@corporate-world.lisp.de

unread,
Feb 3, 2009, 10:33:51 PM2/3/09
to
On Feb 4, 4:06 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> His problem seems to have been resolved in a few hours.

Great.

You should be more present there.

André Thieme

unread,
Feb 4, 2009, 8:25:07 PM2/4/09
to
Jon Harrop schrieb:

> That is incorrect. Tuples are not collections. They do not have push, pop,
> add, take, length etc. because they have a fixed number of elements.

By the way, in Clojure there are no tuples. But if you create a list,
vector, set or hashmap, then those also have a fixed number of elements
and it is not possible to change those.
(def x [10 20 30 40]) <--- x can be seen as a constant.
But still, the vector (or other types I mentioned) are collections.
And one can push an element onto them, where push is called “conj”:
(conj collection new-element)
Conj returns a new instance of a vector (list, set, ... depending on
the type of its collection argument) that contains all of collection
plus the new-element.
One can call pop on them. This is like first.
One can add elements, via conj (again), and take their length with count.
None of these functions can change x, as this is immutable. But it still
makes sense to have these functions defined even for immutable data.


> For example, combining a tuple and list type allows ML to express a type
> representing lists that contain at least one element:
>
> 'a * 'a list
>
> Any attempt to create a container of this type with zero elements will be
> caught at compile time as a static type error. Lisp is completely incapable
> of this.

Lisp is a dynamic system. You can compare it in some sense with a living
organism in which things can change. A bit like an operating system.
Imagine you would have to decide what programs you want to run before
you start Windows, and also decide in what order you want to start them.
If you were sure that this time Firefox won’t be needed, but then you
suddenly get an interesting email with a link, you first have to shutdown
your system, modify your list of programs, and reboot Windows.
The Lisp approach is, that while Windows is still running you can change
your mind and start (for example) Firefox.
So, in Lisp one can do things which are not possible in ML/OCaml/F#/Haskell.
People felt the need to have a system that can be changed at runtime.
This has advantages if your specification is not very clear or likely
to change while, or if you need to explore more about your problem domain.
The disadvantage is that this makes it impossible to write a very
reliable type checker. One could do this in principle for dynamic
systems such as Lisp or Python. But the problem is of course that if one
changes the system itself while it is running the proof is not nessecarily
correct anymore. So, one would have to check everything again, and
the system must be stopped as this happens, to make sure that no other
change is done during the new type check. Or one could forbid changes
at all. Both alternatives basically kill the dynamism which one wanted
to have in the first place. This eliminates the edit->compile->run
cycle and typically improves productivity.
Some people like the approach to write their prototype in a dynamic
system, and as soon they understand enough of the problem domain, they
rewrite it in a statically typed system. This could be for example F#,
which offers modern abstractions and runs on a VM with a lot of libs,
which makes it interesting for practical use.
In the end it is possible to develop everything in a static system or
in a dynamic one. Mostly a question of taste. Both sides showed that
it can be done. Big systems were created in a static system and the
authors made it without dynamism. Big systems were created in dynamic
system, and they run without drowning in type problems.


André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/

Kaz Kylheku

unread,
Feb 4, 2009, 10:00:03 PM2/4/09
to
On 2009-02-04, Jon Harrop <j...@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> #(123 "456") ;; effectively a tuple
>
> Your "tuple" incurs costly heap allocation when it is created and bounds

And by the way, it would be a lousy Lisp that heap-allocates a literal
constant! :)

Jon Harrop

unread,
Feb 4, 2009, 11:03:25 PM2/4/09
to
Kaz Kylheku wrote:
> On 2009-02-04, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Your "tuple" incurs costly heap allocation when it is created and bounds
>> checks when it is read, precisely because it is incapable of conveying
>> the same information.
>
> Which is probably why you wouldn't use it when you want multiple values,
> right? Multiple values don't occur heap allocation. Period.

Ideally, yes. They actually do in many languages though, including OCaml.

>> Multiple return values have another needlessly-separate representation in
>> Lisp that also has its own peculiar shortcomings.
>
> Such as?

The number of elements cannot reliably exceed 20.

> Multiple values are the inverse of function arguments. Functions
> are not restricted to take one argument. Why shouldn't they return
> multiple values?
>
> M come in, N come out.

Exactly. But why restrict multiple values to return values? Why not allow
multiple values (aggregate values) anywhere without the overhead of cons,
lists and vectors? That is precisely what tuples do.

>> Tuples unify all of these use cases without their shortcomings.
>
> Tuples are just another type. A function that returns a tuple has a
> /single/ return value of tuple type.

Yes. You can also say that all functions accept and return a single value
that may be a tuple. That simplifies things.

> The caller has to deal with that
> tyle. There may be syntactic sugar for that, but it doesn't change the
> fact.

The caller has to deal with multiple return values anyway. The ability to
silently drop some in Lisp is not particularly useful because you usually
want all of the return values.

> It's like returning a struct in C:
>
> struct foo { int x, char *s } foo(void)
> { return (struct foo) { 3, "foo" }; }
>
> And yes, the compound literal is in fact C syntax now as of C99.
>
> There you go, tuples in C. Statically typed and everything. So with the
> above you can do:
>
> printf("foo().s == %s\n", foo().s);

The concepts are almost identical and, in fact, I am using LLVM's support
for first-class structs to implement tuples. However, tuples are
structurally typed as you said earlier whereas C structs are nominally
typed. In other words, you don't have to define a new tuple type for every
pair you handle.

>>> Tuples are used in these autistic languages like Haskell and OCaml in
>>> situations when the programmer wants a collection of values of
>>> heterogeneous types,
>>
>> That is incorrect. Tuples are not collections. They do not have push,
>> pop,
>
> Push and pop are thought of as destructive (this is cross-posted to
> comp.lang.lisp!) A collection doesn't have to have such things to be a
> collection. There could be functional push and pop, of course.

Collections contain a variable number of elements but tuples contain a
constant (at compile time) number of elements.

>> add, take, length etc.
>
> Length could be implemented; it would be a compile-time constant, along
> the lines:
>
> len (1, 2, 3) -> 3

Right but a function that returns the length of a triple is pointless.

Jon Harrop

unread,
Feb 4, 2009, 11:28:22 PM2/4/09
to

But vectors and lists in Lisp are mutable so they are not constants and
cannot be hoisted. So they are highly likely to incur allocation.

Jon Harrop

unread,
Feb 4, 2009, 11:44:01 PM2/4/09
to
André Thieme wrote:
> Jon Harrop schrieb:
>> That is incorrect. Tuples are not collections. They do not have push,
>> pop, add, take, length etc. because they have a fixed number of elements.
>
> By the way, in Clojure there are no tuples. But if you create a list,
> vector, set or hashmap, then those also have a fixed number of elements
> and it is not possible to change those.
> (def x [10 20 30 40]) <--- x can be seen as a constant.
> But still, the vector (or other types I mentioned) are collections.
> And one can push an element onto them, where push is called “conj”:
> (conj collection new-element)
> Conj returns a new instance of a vector (list, set, ... depending on
> the type of its collection argument) that contains all of collection
> plus the new-element.
> One can call pop on them. This is like first.
> One can add elements, via conj (again), and take their length with count.
> None of these functions can change x, as this is immutable. But it still
> makes sense to have these functions defined even for immutable data.

I don't follow. If you can mutate the container to insert more elements then
in what sense does it have "a fixed number of elements"?

>> For example, combining a tuple and list type allows ML to express a type
>> representing lists that contain at least one element:
>>
>> 'a * 'a list
>>
>> Any attempt to create a container of this type with zero elements will be
>> caught at compile time as a static type error. Lisp is completely
>> incapable of this.
>
> Lisp is a dynamic system. You can compare it in some sense with a living
> organism in which things can change. A bit like an operating system.
> Imagine you would have to decide what programs you want to run before
> you start Windows, and also decide in what order you want to start them.

That is a false analogy. You can simply take what Lisp has and add optional
static typing (as Qi does). You have not lost anything.

> If you were sure that this time Firefox won’t be needed, but then you
> suddenly get an interesting email with a link, you first have to shutdown
> your system, modify your list of programs, and reboot Windows.
> The Lisp approach is, that while Windows is still running you can change
> your mind and start (for example) Firefox.
> So, in Lisp one can do things which are not possible in
> ML/OCaml/F#/Haskell.

F# is by far the closest to Lisp but it does not have restartable
exceptions.

> People felt the need to have a system that can be
> changed at runtime. This has advantages if your specification is not very
> clear or likely to change while, or if you need to explore more about your
> problem domain. The disadvantage is that this makes it impossible to write
> a very reliable type checker. One could do this in principle for dynamic
> systems such as Lisp or Python. But the problem is of course that if one
> changes the system itself while it is running the proof is not nessecarily
> correct anymore. So, one would have to check everything again, and
> the system must be stopped as this happens, to make sure that no other
> change is done during the new type check. Or one could forbid changes
> at all. Both alternatives basically kill the dynamism which one wanted
> to have in the first place.

Yes.

> This eliminates the edit->compile->run cycle and typically improves
> productivity.

The former is incorrect and I do not believe the latter. Statically typed
FPLs do not require compilation so there are arguably no such cycle to
begin with. Lack of static typing massively degrades productivity when
writing difficult code, IME.

Kaz Kylheku

unread,
Feb 5, 2009, 12:58:22 AM2/5/09
to
On 2009-02-05, Jon Harrop <j...@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2009-02-04, Jon Harrop <j...@ffconsultancy.com> wrote:
>>> Your "tuple" incurs costly heap allocation when it is created and bounds
>>> checks when it is read, precisely because it is incapable of conveying
>>> the same information.
>>
>> Which is probably why you wouldn't use it when you want multiple values,
>> right? Multiple values don't occur heap allocation. Period.
>
> Ideally, yes. They actually do in many languages though, including OCaml.
>
>>> Multiple return values have another needlessly-separate representation in
>>> Lisp that also has its own peculiar shortcomings.
>>
>> Such as?
>
> The number of elements cannot reliably exceed 20.

You mean portably. The number of elements cannot exceed some minimum limit
in order for the program to be a maximally portable ANSI CL program. If you're
targetting specific implemenentations, you can decide to take advantage of
whatever they can do.

>> Multiple values are the inverse of function arguments. Functions
>> are not restricted to take one argument. Why shouldn't they return
>> multiple values?
>>
>> M come in, N come out.
>
> Exactly. But why restrict multiple values to return values? Why not allow
> multiple values (aggregate values) anywhere

Two part answer. Firstly, this is like asking ``Why restrict argument value
passing to functions and operators? Why not pass arguments anywhere?''

Be that as it may, what do you mean by anywhere? Anywhere you need a form to
produce multiple values, you can evaluate a (values ...) form. You don't have
to embed that into a function and call it.

> without the overhead of cons,
> lists and vectors? That is precisely what tuples do.

Anywhere you evaluate (1, 2, 3) you have a tuple, and anywhere you evaluate
(values 1 2 3) you have three values.

>>> Tuples unify all of these use cases without their shortcomings.
>>
>> Tuples are just another type. A function that returns a tuple has a
>> /single/ return value of tuple type.
>
> Yes. You can also say that all functions accept and return a single value
> that may be a tuple. That simplifies things.

Does it also simplify things that all function take one argument, where
multiple arguments are represented by a tuple?

Hey, perl works that way, right? Pretty much.

Lisp macros work that way under the hood---they are one-parameter functions
that take the whole form---but the defmacro language provides the lambda list
destructuring so we don't have to deal with the form as one big parameter!

The idea isn't that far fetched.

>
>> The caller has to deal with that
>> tyle. There may be syntactic sugar for that, but it doesn't change the
>> fact.
>
> The caller has to deal with multiple return values anyway. The ability to
> silently drop some in Lisp is not particularly useful because you usually
> want all of the return values.

Look, you obviously don't program in Lisp. If you could not silently drop the
additional values, it would be very cumbersome. Yes, in many situations, the
multiple values are designed such that the first one is the main attraction,
so to speak, and the others are some supplementary info that you don't always
need. You want examples:

;; often interested in integer quotient, not remainder
(truncate x y) -> (values quotient remainder)

;; often interested in macro-expanded form, not the flag
;; which says whether or not the form is a macro call!
(macroexpand form) -> (values expanded-form {nil | t})

;; if NIL doesn't occur as valid data, don't care about the flag:
(gethash key table) -> (value { nil | t })

This thread started with a root article in which a newbie described
the convenience of being able to ignore extra multiple values.

It's true that you sometimes want all of the values, but it's not accurate to
say ``usually''. Ignoring the supplementary return values is routine.

In fact multiple-values in Lisp seem to be contrived so that you don't even
know they are there.

>> push and pop are thought of as destructive (this is cross-posted to


>> comp.lang.lisp!) A collection doesn't have to have such things to be a
>> collection. There could be functional push and pop, of course.
>
> Collections contain a variable number of elements but tuples contain a
> constant (at compile time) number of elements.

So they are a compile-time collection.

>>> add, take, length etc.
>>
>> Length could be implemented; it would be a compile-time constant, along
>> the lines:
>>
>> len (1, 2, 3) -> 3
>
> Right but a function that returns the length of a triple is pointless.

What about static polymorphism? If the tuple comes in as an argument x to a
polymorphic function, the length of x could yield different constants in
different compile-time instantiations of that function, which could be useful
in some way. Compile-time access to various properties is not pointless.

Anagram

unread,
Feb 5, 2009, 1:45:32 AM2/5/09
to
Jon Harrop <j...@ffconsultancy.com> wrote in
news:5pmdnZIZwsRj_hfU...@posted.plusnet:

> The caller has to deal with multiple return values anyway. The ability
> to silently drop some in Lisp is not particularly useful because you
> usually want all of the return values.

A common use of returning multiple values is to return the desired result
as a single value and return incidental information as additional values.
If most callers want the desired result, and only a few want the incidental
information, then the ability to silently drop some values is indeed
useful.

Matthias Buelow

unread,
Feb 5, 2009, 9:52:28 AM2/5/09
to
Jon Harrop wrote:

> The caller has to deal with multiple return values anyway. The ability to
> silently drop some in Lisp is not particularly useful because you usually
> want all of the return values.

Don't state things in that offhand pseudo-factual way when they aren't
actually facts, and in this case, are most likely wrong in most
situations. Most of the time I want only the first value, the second (or
more) are reserved as additional information for special cases.
Therefore it is good practice by the language to silently drop all
values except for the first. It also allows one to change the number of
values returned by a function without breaking/having to change any
existing code. Very useful at times, especially during development (I
presume you don't actually program, therefore such detail might elude you.)

Slobodan Blazeski

unread,
Feb 5, 2009, 11:17:30 AM2/5/09
to
On Feb 5, 5:03 am, Jon Harrop <j...@ffconsultancy.com> wrote:

> The caller has to deal with multiple return values anyway. The ability to
> silently drop some in Lisp is not particularly useful because you usually
> want all of the return values.

Not usually, sometimes I want all the return value. And when I don't
care about the rest of the values I don't want language to bother me
trivia.

bobi

Jon Harrop

unread,
Feb 5, 2009, 2:07:33 PM2/5/09
to
Kaz Kylheku wrote:
> On 2009-02-05, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Kaz Kylheku wrote:
>>> On 2009-02-04, Jon Harrop <j...@ffconsultancy.com> wrote:
>>>> Your "tuple" incurs costly heap allocation when it is created and
>>>> bounds checks when it is read, precisely because it is incapable of
>>>> conveying the same information.
>>>
>>> Which is probably why you wouldn't use it when you want multiple values,
>>> right? Multiple values don't occur heap allocation. Period.
>>
>> Ideally, yes. They actually do in many languages though, including OCaml.
>>
>>>> Multiple return values have another needlessly-separate representation
>>>> in Lisp that also has its own peculiar shortcomings.
>>>
>>> Such as?
>>
>> The number of elements cannot reliably exceed 20.
>
> You mean portably. The number of elements cannot exceed some minimum limit
> in order for the program to be a maximally portable ANSI CL program. If
> you're targetting specific implemenentations, you can decide to take
> advantage of whatever they can do.

Yes. It is still a rather silly restriction.

>>> Multiple values are the inverse of function arguments. Functions
>>> are not restricted to take one argument. Why shouldn't they return
>>> multiple values?
>>>
>>> M come in, N come out.
>>
>> Exactly. But why restrict multiple values to return values? Why not allow
>> multiple values (aggregate values) anywhere
>
> Two part answer. Firstly, this is like asking ``Why restrict argument
> value passing to functions and operators? Why not pass arguments
> anywhere?''
>
> Be that as it may, what do you mean by anywhere?

For example, a "let" binding:

let x = 2 in x + 3

May be rephrased as a lambda:

(fun x -> x + 3) 2

They are exactly equivalent but only the latter has "return values".

> Anywhere you need a form to produce multiple values, you can evaluate a
> (values ...) form. You don't have to embed that into a function and call
> it.

Right but it is tedious and uncommon when it could be a lot easier.

>> without the overhead of cons,
>> lists and vectors? That is precisely what tuples do.
>
> Anywhere you evaluate (1, 2, 3) you have a tuple, and anywhere you
> evaluate (values 1 2 3) you have three values.

You might as well just have the tuple.

>>>> Tuples unify all of these use cases without their shortcomings.
>>>
>>> Tuples are just another type. A function that returns a tuple has a
>>> /single/ return value of tuple type.
>>
>> Yes. You can also say that all functions accept and return a single value
>> that may be a tuple. That simplifies things.
>
> Does it also simplify things that all function take one argument, where
> multiple arguments are represented by a tuple?
>
> Hey, perl works that way, right? Pretty much.

I am not familiar with Perl but OCaml, SML, Haskell and F# work that way and
it works well.

> Lisp macros work that way under the hood---they are one-parameter
> functions that take the whole form---but the defmacro language provides
> the lambda list destructuring so we don't have to deal with the form as
> one big parameter!

Yes.

>>> The caller has to deal with that
>>> tyle. There may be syntactic sugar for that, but it doesn't change the
>>> fact.
>>
>> The caller has to deal with multiple return values anyway. The ability to
>> silently drop some in Lisp is not particularly useful because you usually
>> want all of the return values.
>
> Look, you obviously don't program in Lisp. If you could not silently drop
> the additional values, it would be very cumbersome. Yes, in many
> situations, the multiple values are designed such that the first one is
> the main attraction, so to speak, and the others are some supplementary
> info that you don't always need. You want examples:
>
> ;; often interested in integer quotient, not remainder
> (truncate x y) -> (values quotient remainder)
>
> ;; often interested in macro-expanded form, not the flag
> ;; which says whether or not the form is a macro call!
> (macroexpand form) -> (values expanded-form {nil | t})
>
> ;; if NIL doesn't occur as valid data, don't care about the flag:
> (gethash key table) -> (value { nil | t })
>
> This thread started with a root article in which a newbie described
> the convenience of being able to ignore extra multiple values.
>
> It's true that you sometimes want all of the values, but it's not accurate
> to say ``usually''. Ignoring the supplementary return values is routine.
>
> In fact multiple-values in Lisp seem to be contrived so that you don't
> even know they are there.

You could rewrite such functions to avoid the superfluous data.

>>> push and pop are thought of as destructive (this is cross-posted to
>>> comp.lang.lisp!) A collection doesn't have to have such things to be a
>>> collection. There could be functional push and pop, of course.
>>
>> Collections contain a variable number of elements but tuples contain a
>> constant (at compile time) number of elements.
>
> So they are a compile-time collection.

In a sense, yes. Although they still do not support many conventional
operations on collections.

>>>> add, take, length etc.
>>>
>>> Length could be implemented; it would be a compile-time constant, along
>>> the lines:
>>>
>>> len (1, 2, 3) -> 3
>>
>> Right but a function that returns the length of a triple is pointless.
>
> What about static polymorphism? If the tuple comes in as an argument x to
> a polymorphic function, the length of x could yield different constants in
> different compile-time instantiations of that function, which could be
> useful in some way. Compile-time access to various properties is not
> pointless.

That would undermine the type system because your constant is now variable.

Javier

unread,
Feb 5, 2009, 4:42:22 PM2/5/09
to
java...@gmail.com escribió:
> The real unique distinctive of Lisp is that it's absolutely
> invincible.

What kind of argument is that?

Kenneth Tilton

unread,
Feb 5, 2009, 5:16:16 PM2/5/09
to

A lot better than "but everybody else uses X!".

hth,kth

William James

unread,
Feb 5, 2009, 7:54:44 PM2/5/09
to
Kenneth Tilton wrote:

If that is a logical argument that works for Commune LISP, then
it works just as logically for COBOL:

The real unique distinctive of COBOL is that it's absolutely
invincible.

Yes, folks, CommuneLISP fanatics see nothing wrong with this kind of
"reasoning" when it is used to bolster their religion.

They are the most irrational, dishonest, and savage of all programmers
(if you can call the bloated, feculent garbage they disgorge
"programs").

jos...@corporate-world.lisp.de

unread,
Feb 5, 2009, 8:07:48 PM2/5/09
to
On Feb 6, 1:54 am, "William James" <w_a_x_...@yahoo.com> wrote:
> Kenneth Tilton wrote:
> > Javier wrote:
> > > java....@gmail.com escribió:

You might want to consult M-x doctor.


Kenneth Tilton

unread,
Feb 5, 2009, 8:51:00 PM2/5/09
to

It drives you crazy how happy we all are with Lisp, eh? Instead of
fighting it you should take The Hint(tm) and try it yourself. It's kinda
obvious you are getting tired of flopping onto your belly for those
little ten foot slides.

hth, kth

Thomas F. Burdick

unread,
Feb 6, 2009, 4:30:17 AM2/6/09
to
On Feb 6, 2:07 am, "jos...@corporate-world.lisp.de" <jos...@corporate-

Cool, even eliza can figure out that he doesn't make any sort of
coherent argument, but just takes wild jags:

If that is a logical argument that works for Commune LISP, then
it works just as logically for COBOL

Is it because is a logical argument that works for commune lisp then
it works just as logically for cobol that you came to me?

The real unique distinctive of COBOL is that it's absolutely
invincible.

Does it bother you that it's absolutely invincible?

Yes

I see... Well, why do you say this is so?

folks, CommuneLISP fanatics see nothing wrong with this kind of
"reasoning" when it is used to bolster their religion

What happened when it is used to bolster their religion?

They are the most irrational, dishonest, and savage of all programmers

What makes you believe that?

if you can call the bloated, feculent garbage they disgorge
"programs"

Earlier you said is a logical argument that works for commune lisp
then it works just as logically for cobol?

jos...@corporate-world.lisp.de

unread,
Feb 6, 2009, 4:36:19 AM2/6/09
to

haha!

Javier

unread,
Feb 6, 2009, 5:09:37 AM2/6/09
to
Kenneth Tilton escribió:

Ey boys I left you just for some months and you continue with the same grap?

You lispers have no solution.

Thomas A. Russ

unread,
Feb 6, 2009, 2:53:20 PM2/6/09
to
Javier <jav...@gmail.com> writes:

> java...@gmail.com escribi受:


> > The real unique distinctive of Lisp is that it's absolutely
> > invincible.
>
> What kind of argument is that?

I believe the technical term might be an "ex cathedra" argument,
although perhaps it might be an "ad antiquitatem" argument instead.

--
Thomas A. Russ, USC/Information Sciences Institute

Pillsy

unread,
Feb 6, 2009, 6:59:39 PM2/6/09
to
On Feb 4, 11:28 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
[...]

> > And by the way, it would be a lousy Lisp that heap-allocates a literal
> > constant! :)

> But vectors and lists in Lisp are mutable so they are not constants and
> cannot be hoisted.

Um, modifying a *literal* vector (like #(123 "456")) or list (like '(a
b c)) is undefined according to the CLHS.

Cheers,
Pillsy

William James

unread,
Feb 6, 2009, 10:43:20 PM2/6/09
to
Pillsy wrote:

> On Feb 4, 11:28 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> > Kaz Kylheku wrote:
> [...]
> > > And by the way, it would be a lousy Lisp that heap-allocates a
> > > literal constant! :)
>
> > But vectors and lists in Lisp are mutable so they are not constants
> > and cannot be hoisted.
>
> Um,

What language do you think that you are attempting to write?
There is no word "um" in English.

Pillsy

unread,
Feb 6, 2009, 11:03:20 PM2/6/09
to
On Feb 6, 10:43 pm, "William James" <w_a_x_...@yahoo.com> wrote:
> Pillsy wrote:
[...]
> > Um,

> What language do you think that you are attempting to write?
> There is no word "um" in English.

http://dictionary.reference.com/browse/um

Cheers,
Pillsy

Kaz Kylheku

unread,
Feb 6, 2009, 11:08:49 PM2/6/09
to

Yes, um is a word.

From http://www.merriam-webster.com/dictionary/um:

Main Entry: um
Pronunciation: \a prolonged m sound, .m\
Function: interjection
Date: 1672
.used to indicate hesitation <well, um, I don't know>


From: The Oxford Pocket Dictionary of Current English

um / (.)m/
interj. expressing hesitation or a pause in speech: anyway, um, where was I?

Now Apologize to Pillsy, you mentally-deranged, unemployable fuck!

You're supposed to be busy finding the Message-ID of that article that proves a
certain claim that you made earlier.

Oh, and while you are at it, could you cite the Message-ID of one, just one,
one single comp.lang.lisp article, from any time in the newsgroup's history,
where you are the author, and that article isn't flamebait, but actually
something topical?

It's time to plonk you. More than a few years overdue.

Jon Harrop

unread,
Feb 11, 2009, 3:09:13 AM2/11/09
to

The people here are more in need of my help.

0 new messages