From: Ray Blaak
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <uae703xdn.fsf@infomatch.com>
"Julian Morrison" <······@extropy.demon.co.uk> writes:
> Please tell me the parts of (1)Common Lisp (2) Scheme that are "broken as
> designed".
For scheme: Lack of standardized namespaces. Many (most?) implementations
supply some sort of module/unit support, but porting between them is a pain.
Without decent static namespaces, programming "in the large" is not properly
doable.
This is such a basic necessity that it needs to be in the standard language
itself.
Also, lack of a standard defstruct/define-record. Such a fundamental data
structure is absolutely essential, and should be in the standard. That you can
roll your own with the macro system alleviates this somewhat, but since this
is so basic, one shouldn't need to invent this all the time.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: David Rush
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <okfn1azjmiw.fsf@bellsouth.net>
Ray Blaak <·····@infomatch.com> writes:
> "Julian Morrison" <······@extropy.demon.co.uk> writes:
> > Please tell me the parts of (1)Common Lisp (2) Scheme that are "broken as
> > designed".
> Also, lack of a standard defstruct/define-record. Such a fundamental data
> structure is absolutely essential, and should be in the standard. That you can
> roll your own with the macro system alleviates this somewhat, but since this
> is so basic, one shouldn't need to invent this all the time.
Fixed. See SRFI-9 <http://srfi.schemers.org>
Extra credit: Tell what is the *real* broken part behind this.
david rush
--
The beginning of wisdom for a [software engineer] is to recognize the
difference between getting a program to work, and getting it right.
-- M A Jackson, 1975
David Rush <····@bellsouth.net> writes:
> Ray Blaak <·····@infomatch.com> writes:
> > "Julian Morrison" <······@extropy.demon.co.uk> writes:
> > > Please tell me the parts of (1)Common Lisp (2) Scheme that are "broken as
> > > designed".
>
> > Also, lack of a standard defstruct/define-record. Such a fundamental data
> > structure is absolutely essential, and should be in the standard. That you can
> > roll your own with the macro system alleviates this somewhat, but since this
> > is so basic, one shouldn't need to invent this all the time.
>
> Fixed. See SRFI-9 <http://srfi.schemers.org>
>
> Extra credit: Tell what is the *real* broken part behind this.
That it took more than 10 years to fix (17 since CLtL1), it is not in
R^nRS and that staggering amount of resources were thrown at this just
ti reinvent a wheel?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Ray Blaak <·····@infomatch.com> writes:
> For scheme: Lack of standardized namespaces. Many (most?)
> implementations supply some sort of module/unit support, but
> porting between them is a pain.
>
> Without decent static namespaces, programming "in the large" is not
> properly doable.
I guess that depends on what you mean by "properly" doable. There are
other languages which are used for programming "in the large" that
don't have namespaces. It's nice to have namespaces & it's a little
ugly to work around not having them. But in Scheme & Lisp working
around something is not nearly as hard as it is in languages like C &
C++.
In that a design fault is the failure to meet a design goal, I find it
hard to say that the lack of namespaces is a design fault in Scheme.
After all, programming "in the large" wasn't one of the design goals
for Scheme.
Scheme was intended to be simple and concise. If all the "design
faults" people have mentioned were incorporated into the language,
then it wouldn't be simple & concise any longer. It would no longer
meet its design criteria & *then* would have a design fault.
--
Harvey Stein
Bloomberg LP
·······@bfr.co.il
From: Ray Blaak
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <uae6y3dcg.fsf@infomatch.com>
·······@bfr.co.il (Harvey J. Stein) writes:
> Ray Blaak <·····@infomatch.com> writes:
> > Without decent static namespaces, programming "in the large" is not
> > properly doable.
>
> I guess that depends on what you mean by "properly" doable.[...]
>
> In that a design fault is the failure to meet a design goal, I find it
> hard to say that the lack of namespaces is a design fault in Scheme.
> After all, programming "in the large" wasn't one of the design goals
> for Scheme.
Fair enough. What I like about Scheme, though, is how its core design is
fundamentally extensible in almost any direction. It is a great language for
experimentation.
The lack of standardized namespaces are the one missing core feature (well,
aside from optional type declarations) needed to be able to do anything in
Scheme.
Also, namespace support is present in many Scheme implementations, so even if
not an original design goal, it certainly is considered a useful feature. As
such, it would benefit from being standardized.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
...
> Fair enough. What I like about Scheme, though, is how its core design is
> fundamentally extensible in almost any direction. It is a great language for
> experimentation.
What I like about CL, though, is how its core design is fundamentally
extensible in almost any direction. It is a great language for
experimentation.
Given that CL gives you enormous advantages over Scheme in terms of
extisibility, why don't you switch? (Assuming you haven't turn on the
Dark Side yet :) )
> Also, namespace support is present in many Scheme implementations, so even if
> not an original design goal, it certainly is considered a useful feature. As
> such, it would benefit from being standardized.
Packages are in CL. They have been there since 1984. What else do you
need?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: David Rush
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <okfofvei212.fsf@bellsouth.net>
Erik Naggum <····@naggum.net> writes:
> How do I get real symbols in Scheme? How do I get two namespaces? How
> do I get a programmable reader that the compiler will also obey? How do
> I get packages?
These are all well-solved problems, Erik. If you bothered to be as
well-informed on Scheme as you are on CL, you would know that.
> Fact is, Scheme is _not_ extensible in any direction that can be
> construed as being towards Common Lisp.
Fact is, you are confusing your opinions with facts. Try not to repeat
this mistake in the future.
david rush
--
To get anywhere with programming we must be free to discuss and
improve subjective phenomena. and leave the objective metrics to
resultants such as bug reports.
-- The Programmer's Stone (Alan Carter & Colston Sanger)
From: Thant Tessman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <3AA65760.941290@acm.org>
Erik Naggum wrote:
> [...] please inform
> me of how you can give a Scheme real symbols with a functional value in
> addition to the variable value. That is, suppose I want to _experiment_
> with the Common Lisp way from within Scheme where the following code has
> the expected meaning:
>
> (define foo (x) (+ 1 x))
>
> (let ((foo 41))
> (foo foo))
Chez Scheme's syntax-case macro system supports syntax extension of
singleton identifiers. So a CL interpretation of the above Scheme code
should be possible. But my question is why would you want to? I thought
the original reason to keep functions in separate namespaces was to
allow for optimizations that now days aren't really relevant. It
certainly seems anti-intuitive to me.
-thant
From: Thant Tessman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <3AA6757A.6CC3B566@acm.org>
Erik Naggum wrote:
>
> * Thant Tessman <·····@acm.org>
[...CL-style separate namespaces...]
> > But my question is why would you want to?
>
> That is not for anyone to question.
My question was not rhetorical. I was not arguing that you shouldn't be
able to. I'm fairly convinced that in Scheme you can. I was asking why
you would want to.
I build what might loosely be considered separate namespaces all the
time. But I've always wanted them to be explicit, not built into the
language. Who says that dividing namespaces into functions and
non-functions is always (or even usually) what you want? My 'namespaces'
are usually far more semantically-constrained than that.
Since we're talking about experimenting, it should be mentioned that
it's trivial to build an interpreter in Scheme with whatever evaluation
rules you want. And I assume the same goes for CL. The question merely
becomes: What and how much default behavior do you want to borrow from
(or carry around with) your implementation language?
I'm not sure what to make of your noun/verb example. In Scheme, whether
a value is to be treated as a 'noun' or 'verb' is, just like in CL, a
matter of how you use it. And in Scheme, just like in CL (if I
understand correctly), a function can be treated just like a value. That
is, in the terms of your example, a verb can be treated as a noun when
necessary. The difference is only that CL requires extra syntax to do
it. And adding extra syntax to a language just to allow an identifier to
denote more than one value within a single expression just seems very
strange to me. Do you have more than your word to convince me that the
decision to implement separate namespaces for functions in CL isn't
about early compiler implementation details, or at best an accident of
history?
If you think the reliance on context to disambiguate the value denoted
by a given identifier is a good thing, check out C++. Each scoping rule
of C++ can be fairly well-justified in isolation. But their interaction
is monstrously complicated.
[...]
-thant
From: Thant
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <3AA64D28.B6B53D7A@acm.org>
Erik Naggum wrote:
> [...] People _want_ to be able to use the same spelling for
> words of different kinds without having to deal with arbitrary
> conventions in the normal case. There _is_ no extra syntax
> added in the normal case. [...]
What is the "normal" case depends entirely on whether you want to
emphasize the use of higher-order functions as a common programming
idiom or not. If not for higher-order functions, why prefer Scheme *or*
Common Lisp over FORTRAN, COBOL, Pascal, C, Smalltalk, Modula-*, Eiffel,
C++, Java, C#, etc., etc.?
Multiple namespaces add semantic complexity. What does this semantic
complexity buy one other than the fact that it suits you?
> > Do you have more than your word to convince me that the
> > decision to implement separate namespaces for functions
> > in CL isn't about early compiler implementation details,
> > or at best an accident of history?
>
> You'll have to be satisfied with somebody's word, so you
> can keep this up as long as you want, which means I'm not
> goign to entertain you.
I got my impressions from the first few chapters of Christian Queinnec's
"Lisp in Small Pieces". Maybe I've misread him. Maybe he's not as
clued-in as you are. But you haven't given me or any others still
bothering to read this thread any reason to give your opinion more
weight than his.
In the mean-time, I'll continue to consider CL's separate namespace for
functions a flaw rather than a feature. Oh yeah, and arguing that Scheme
is different from Common Lisp is not the same thing as arguing that
Scheme is no good for experimenting.
-thant
Thant <·····@acm.org> writes:
> What is the "normal" case depends entirely on whether you want to
> emphasize the use of higher-order functions as a common programming
> idiom or not. If not for higher-order functions, why prefer Scheme *or*
> Common Lisp over FORTRAN, COBOL, Pascal, C, Smalltalk, Modula-*, Eiffel,
> C++, Java, C#, etc., etc.?
>
> Multiple namespaces add semantic complexity. What does this semantic
> complexity buy one other than the fact that it suits you?
I simply don't find #' or (function blah) a hindrance for doing real
programming with higher-order functions, and the ability to have data
variables and functions with the same name is something that I do
appreciate every day.
I wrote alot of code, I spend all day writing code. This particular
optimization for semantic complexity doesn't buy anything or me, while
the CL behavior does (functions and variables with the same name).
Another example is lisp macros versus scheme macros. Scheme macros
are indeed "cleaner", but I find them much less useful. The
"problems" in CL macros they try and avoid have not been real problems
for me in the past, and the advantages that the CL system has have
bought me real advantages.
Like I said, I'm not an academic tho. I'm much more like the "working
programmer" of Larry Paulson's "ML for the Working Programmer".
> I got my impressions from the first few chapters of Christian
> Queinnec's "Lisp in Small Pieces". Maybe I've misread him. Maybe
> he's not as clued-in as you are. But you haven't given me or any
> others still bothering to read this thread any reason to give your
> opinion more weight than his.
Well, I think he has. You gave your opinion and Erik and others,
myelf included, have given you ours. As for weight to opinions, it
doesn't mean shit. If you really want to know the answer I'm sure
that some reasearch thru the historical documents of the CL
standardization process, or direct interviewing with those who
participated in the languages evolution would be feasible.
Quiennec's opinion could also be effected by the fact that he is
writing a book about implementing lisps, so the implementation
optimization becomes important. If he hasn't done alot of CL
programming then the other advantages that we have pointed out would
never become apparent to him. I don't recall him supporting this
opinion with documentation, but I can't check since my copy is at
home.
> In the mean-time, I'll continue to consider CL's separate namespace
> for functions a flaw rather than a feature. Oh yeah, and arguing
> that Scheme is different from Common Lisp is not the same thing as
> arguing that Scheme is no good for experimenting.
Sure, to each his own. Arguing that Scheme is simple doesn't mean
it's good for experimentation. I think Erik has done more than just
argue for the difference between the two.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
In article <··············@piracy.red-bean.com>, Craig Brozefsky wrote:
> ...
>Well, I think he has. You gave your opinion and Erik and others,
>myelf included, have given you ours. As for weight to opinions, it
>doesn't mean shit. If you really want to know the answer I'm sure
>that some reasearch thru the historical documents of the CL
>standardization process, or direct interviewing with those who
>participated in the languages evolution would be feasible.
possibly including "we did it for compatibility reasons, but nobody remembers
why it was there in the first place", or "because that was the only way to
get the standard approved"? ;-)
hs
From: Janis Dzerins
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <87k860lg5q.fsf@asaka.latnet.lv>
··@paradise.nirvananet (Hartmann Schaffer) writes:
> In article <··············@piracy.red-bean.com>, Craig Brozefsky wrote:
> > ...
> >Well, I think he has. You gave your opinion and Erik and others,
> >myelf included, have given you ours. As for weight to opinions, it
> >doesn't mean shit. If you really want to know the answer I'm sure
> >that some reasearch thru the historical documents of the CL
> >standardization process, or direct interviewing with those who
> >participated in the languages evolution would be feasible.
>
> possibly including "we did it for compatibility reasons, but nobody remembers
> why it was there in the first place", or "because that was the only way to
> get the standard approved"? ;-)
This is silly and not funny. Calling those smart people who did the
standard incompetent makes yourself silly. Please be so kind and do
your homework before posting such crap.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
From: George Neuner
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <3ab29634.89859140@helice>
On 08 Mar 2001 12:16:17 +0200, Janis Dzerins <·····@latnet.lv> wrote:
>··@paradise.nirvananet (Hartmann Schaffer) writes:
>
>> In article <··············@piracy.red-bean.com>, Craig Brozefsky wrote:
>> > ...
>> >Well, I think he has. You gave your opinion and Erik and others,
>> >myelf included, have given you ours. As for weight to opinions, it
>> >doesn't mean shit. If you really want to know the answer I'm sure
>> >that some reasearch thru the historical documents of the CL
>> >standardization process, or direct interviewing with those who
>> >participated in the languages evolution would be feasible.
>>
>> possibly including "we did it for compatibility reasons, but nobody remembers
>> why it was there in the first place", or "because that was the only way to
>> get the standard approved"? ;-)
>
>This is silly and not funny. Calling those smart people who did the
>standard incompetent makes yourself silly. Please be so kind and do
>your homework before posting such crap.
Ever hear the saying, "a camel is a horse designed by committee"?
Or better: "A committee is the process by which a number of people,
all of whom think 'X', get together and compromise on 'Y'."
[paraphrased from the original daffynition]
Hartmann Schaffer may have been referring to the politics that are
inherent in any committee process. The committee members certainly
know why a certain decision was made, yet they may *all* personally
disagree with aspects of that decision. This is not inconsistent.
George
In article <·················@helice>, George Neuner wrote:
>On 08 Mar 2001 12:16:17 +0200, Janis Dzerins <·····@latnet.lv> wrote:
>
>>··@paradise.nirvananet (Hartmann Schaffer) writes:
>>
>>> In article <··············@piracy.red-bean.com>, Craig Brozefsky wrote:
>>> > ...
>>> >Well, I think he has. You gave your opinion and Erik and others,
>>> >myelf included, have given you ours. As for weight to opinions, it
>>> >doesn't mean shit. If you really want to know the answer I'm sure
>>> >that some reasearch thru the historical documents of the CL
>>> >standardization process, or direct interviewing with those who
>>> >participated in the languages evolution would be feasible.
>>>
>>> possibly including "we did it for compatibility reasons, but nobody remembers
>>> why it was there in the first place", or "because that was the only way to
>>> get the standard approved"? ;-)
>>
>>This is silly and not funny. Calling those smart people who did the
>>standard incompetent makes yourself silly. Please be so kind and do
>>your homework before posting such crap.
no, it is neither, and i had no intent of calling them incompetent. but it
is a fact of life that one of the objectives of standard committees is to
maintain compatibility with existing implementations, at the time when the
common lisp standard was developed probable even more so then now. if there
are too many incompatibilities with existing implementations the standard
draft has a damned good chance of being rejected.
somebody who was on the committee that issued the fortran 64 standard once
told me that he spent the night before the final vote rewriting one section
of the draft to make it sufficiently *ambiguous* lest the standard would be
voted down.
>Ever hear the saying, "a camel is a horse designed by committee"?
actually, imo the common lisp standard shows very little of this (fortunately)
>Or better: "A committee is the process by which a number of people,
>all of whom think 'X', get together and compromise on 'Y'."
>[paraphrased from the original daffynition]
>
>
>Hartmann Schaffer may have been referring to the politics that are
>inherent in any committee process. The committee members certainly
>know why a certain decision was made, yet they may *all* personally
>disagree with aspects of that decision. This is not inconsistent.
many years ago i was on a standards committee. it was an eyeopener ;-(
hs
Thant <·····@acm.org> writes:
...
> In the mean-time, I'll continue to consider CL's separate namespace for
> functions a flaw rather than a feature.
You are free to do so. Meanwhile you will have to re-invent the wheel
any time you use a slightly different implementation of Scheme.
> Oh yeah, and arguing that Scheme is different from Common Lisp is
> not the same thing as arguing that Scheme is no good for
> experimenting.
That is not the argument. The rock-solid-and-so-far-unrefuted claim
is that CL is way better for "experimenting" than Scheme is, because
of the simple and true fact that CL is bigger, fatter, more useful and
more usable that Scheme. The Dark Side wins. :)
And now, back to program in Java. :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
"Thant" <·····@acm.org> wrote in message ······················@acm.org...
> In the mean-time, I'll continue to consider CL's separate namespace for
> functions a flaw rather than a feature.
You may believe that, but that still doesn't mean you're correct :-).
> Oh yeah, and arguing that Scheme
> is different from Common Lisp is not the same thing as arguing that
> Scheme is no good for experimenting.
No, but arguing that Scheme has some severe limits on what aspects of the
language can be experimented with or that it might be too under-powered to
use as a convenient base for useful experimentation, may be the same thing.
A question of "why do you want to do that" often masks the real expression
"oh no - we can't do that (at least not easily)". Perhaps one should ask if
Scheme, having never made the jump to a fully functional language base for
building real systems, might also be nearing the end of its useful life as a
research vehicle. Just a thought...
faa
From: Thant Tessman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <3AA7B82C.2C218A5F@acm.org>
"Frank A. Adrian" wrote:
> No, but arguing that Scheme has some severe limits on what aspects of the
> language can be experimented with or that it might be too under-powered to
> use as a convenient base for useful experimentation, may be the same thing.
> A question of "why do you want to do that" often masks the real expression
> "oh no - we can't do that (at least not easily)".
Let's start over.
I'm implementing an interpreter. Normally this isn't a big deal
(especially among this crowd), but for reasons that would bore you and
embarrass me, I'm implementing it in C++ as a scripting language for
C++. And although the interpreter I'm building borrows many ideas from
Scheme, it will not be Scheme. Consequently I'm very interested in the
subject of namespaces right now.
I asked why one would prefer the behavior of symbols in CL to the
behavior of symbols in Scheme--not to argue that what CL does is
'wrong', but to invite folks to convince me that there is a significant
advantage to doing something in a way that at least to me seems very
unintuitive. Given the thread's emphasis on experimentation, I hoped for
a response of the form: "Here's a problem. Here's a solution without
multiple namespaces. Here's a solution with multiple namespaces." But
the most thought-provoking response so far was Erik Naggum's file path
analogy, and even it was more of an issue of personal style.
And to bring it back to the original subject...
> Perhaps one should ask if
> Scheme, having never made the jump to a fully functional language base for
> building real systems, might also be nearing the end of its useful life as a
> research vehicle. Just a thought...
I'm not an academic. I *have* used Scheme in "real" systems. I'm not
qualified to compare it to CL, but in my experience the advantage of
Scheme is that it is very easy to extend its semantics to better suit a
given application domain--that is, it is a very good language for
building (or, dare I say it, experimenting with) languages. I attribute
this strength of Scheme to dynamic typing, higher-order functions,
macros, call/cc, and the fact that the core language is small.
I will readily admit that Scheme (at least by itself) may not be
appropriate for really large modular projects, or projects where safety
and performance are bigger concerns. For such things I would prefer a
language with modules and a decent type system.
-thant
"Thant Tessman" <·····@acm.org> wrote in message
······················@acm.org...
> Let's start over.
Fine.
> I'm implementing an interpreter. Normally this isn't a big deal
> (especially among this crowd), but for reasons that would bore you and
> embarrass me, I'm implementing it in C++ as a scripting language for
> C++.
I feel your pain :-).
> And although the interpreter I'm building borrows many ideas from
> Scheme, it will not be Scheme. Consequently I'm very interested in the
> subject of namespaces right now.
Understandably...
> I asked why one would prefer the behavior of symbols in CL to the
> behavior of symbols in Scheme--not to argue that what CL does is
> 'wrong', but to invite folks to convince me that there is a significant
> advantage to doing something in a way that at least to me seems very
> unintuitive.
One person's unintuitive is another person's best mode of thought. Here is
one thing that bugged the hell out of me when I used Scheme. Here's a
function:
(defun wibble (lst)
(let ((l2 (copy-list lst)))
(list l2 lst)))
All over the place I was forced to use "lst" as an artificial abbreviation
for list to avoid naming collisions with the function "list". One may argue
that my variable names sucked (although this usually happened with utilities
that actually worked on lists) or that the name of the function list was a
holdover from the bad days of Lisp and that make-list would be much better,
but it doesn't change the fact that a single namespace can be just as
confusing as a multiple namespace system, especially when the objects
involved are SO different as to be easily distinguishable by context.
> Given the thread's emphasis on experimentation, I hoped for
> a response of the form: "Here's a problem. Here's a solution without
> multiple namespaces. Here's a solution with multiple namespaces."
> But
> the most thought-provoking response so far was Erik Naggum's file path
> analogy, and even it was more of an issue of personal style.
Language is always an issue of personal style. Why do you think we have so
many of them? The bottom line is that once a certain level of power is
passed, it is extremely difficult to make any sort of valid ranking based on
any local feature. Is APL better than Lisp because it can express
analgorithm in fewer characters? Is C++ better than C because it has (badly
designed) objects?
The problem is that when an example shows one language has a given (even
perhaps elegant) solution to a given problem, the respondant can always come
back with "Yeah! But what about this pathological counter example?" In
almost all cases, nothing is resolved because ones personal valuation
function about what is important makes the final decision.
So, asking for an "experiment" is no more valid than asking a stranger on
the street, "Which is better? The full moon or the new moon?" A
star-crossed lover will give you a much different opinion than a cat
burglar. As such, your question has no correct answer. However, you have
opened the door to an advocate's debate, so don't be surprised that you find
people whacking on you...
> I'm not an academic. I *have* used Scheme in "real" systems.
Wow! You are brave!
> I'm not
> qualified to compare it to CL, but in my experience the advantage of
> Scheme is that it is very easy to extend its semantics to better suit a
> given application domain--that is, it is a very good language for
> building (or, dare I say it, experimenting with) languages.
I've done it,too. Scheme is better than C++ (which isn't saying much), but
its lack of standardized libraries, a decent macro system, and standardized
object system make it much more difficult to construct this type of system
than in, say... Common Lisp?
> I attribute
> this strength of Scheme to dynamic typing, higher-order functions,
> macros, call/cc, and the fact that the core language is small.
I'd agree with the first two, agree partly with the third (because the silly
hygenic macro thing just kills the power of the macro system), disagree
somewhat with the fourth, and absolutely disagree with the fifth.
> I will readily admit that Scheme (at least by itself) may not be
> appropriate for really large modular projects, or projects where safety
> and performance are bigger concerns. For such things I would prefer a
> language with modules and a decent type system.
Well, that last statement is a problem, too.
faa
From: Janis Dzerins
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <87d7brjjqn.fsf@asaka.latnet.lv>
"Frank A. Adrian" <·······@uswest.net> writes:
> So, asking for an "experiment" is no more valid than asking a stranger on
> the street, "Which is better? The full moon or the new moon?" A
> star-crossed lover will give you a much different opinion than a cat
> burglar. As such, your question has no correct answer.
Nasrudin walked into a teahouse and declaimed, "The moon is more useful
than the sun."
"Why?", he was asked.
"Because at night we need the light more."
[There's nothing between the lines.]
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
From: Thant Tessman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <3AABB449.4823839B@acm.org>
"Frank A. Adrian" wrote:
[...]
> Language is always an issue of personal style. Why do you think we have so
> many of them? [...]
I'd like to think that at least a small part of the reason is that
different languages are better at different tasks by some objective
measure. What makes it all interesting is when you look at it from the
point-of-view of using a language to build a language.
As for discussion of multiple namespaces, even I've thought of a more
substantial benefit than variable/function name clashes. I haven't
convinced myself of anything, but what role, for example, does C++'s
single global static namespace play in C++'s static multiple dispatch or
type-safe genericity via templates?
-thant
From: Kent M Pitman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <sfwzoexw5t1.fsf@world.std.com>
[ comp.lang.scheme removed.
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Thant <·····@acm.org> writes:
> Erik Naggum wrote:
>
> > [...] People _want_ to be able to use the same spelling for
> > words of different kinds without having to deal with arbitrary
> > conventions in the normal case. There _is_ no extra syntax
> > added in the normal case. [...]
>
> What is the "normal" case depends entirely on whether you want to
> emphasize the use of higher-order functions as a common programming
> idiom or not.
Right. And the point is that there is a community that doesn't want to
empahsize this and a community that does.
The CL community QUITE EXPLICITLY (I was there in tne room while the
decision was made) did not buy into the notion of higher order
functions being as casual as your'e saying. Everyone in our community
and yours likes having them, but we do not all want to be a community
whose central core theme IS higher order programming. We wanted the
case-marking to call attention to the places where it was happening,
for two reasons: one is that we felt it's unusual and worth
highlighting, and two is because we want the value of being able to
get at both namespaces by positional information in the case where we
are NOT doing this.
It is a design trade-off, and we made it one way for reasons of aesthetics
that make no sense to you but are dear to us, while you made it the other
way for reasons of aesthetics that make no sense to us but are dear to you.
> If not for higher-order functions, why prefer Scheme *or*
> Common Lisp over FORTRAN, COBOL, Pascal, C, Smalltalk, Modula-*, Eiffel,
> C++, Java, C#, etc., etc.?
There is a difference between "having" higher order functions and promoting
them as the answer to all the world's problems.
In the CL community, many of us would first seek to solve problems in other
ways before resorting to them. They are an abstraction tool, but they give
no guidance to efficiency. Scheme eschews any effort to communicate notions
of efficiency to the processor at all. The decision to do f(x) vs to inline
the contents of f(x) is an important core distinction in CL. We call
functions when we're willing to take function call overhead. Sometimes we
make functions and then ask for them to be inlined to buy back the overhead
of a function call boundary. This notion of the expense of the function call
boundary is critical all the way back to FORTRAN, where one did not call
functions for something unless it was worth the overhead. Scheme, on the
other hand, has hand-waved away the cost of function calls and said they are
always cheap. This isn't really possible to do. Static analysis can't
always tell you when it's right to inline a function and when it's right to
call it closed, and so Scheme encourages a programming style in which people
are constantly making functions without regard to whether there is overhead
for so doing. CL is not about that. Scheme also doesn't teach people to be
concerned about the difference between (lambda (x) x) and (lambda () x).
These are just both functions in Scheme, but in Lisp one is a function and
one is a closure, and any decent text tells people to be a lot more concerned
about the latter than the former, since the latter will typically cons and
the former will not. And certainly (catch 'foo x) vs (call/cc (lambda (x) ..))
encourages a programming style that will potentially cons in a situation where
CL does not.
THAT is why prefer CL over Fortran and Scheme--because it has higher order
functions and it has a notion of what responsible use is. Scheme teaches
that any use of functions is good and any non-use of functions is bad.
I simply don't believe that.
> Multiple namespaces add semantic complexity. What does this semantic
> complexity buy one other than the fact that it suits you?
Multiple letters add complexity, too. Why not just label everthing in
binary? Answer: We are equipped in wetware to make this distinction.
No point in igorning it. If we could not distinguish X from Y then definitely
putting that in our programming languages would be bad. But since we are
worse at the computationally simpler task of distinguishing a binary number
from another binary number than distinguishing a higher-order radix number
(such as a base 10 number or an alphanumeric) from another, we prefer to use
the more complex system.
If you can't see that programming languages EXIST to suit me and that buying
me that privilege is the whole goal, there's probably nothing more to say
between us. You ahve to acknowledge this is a legitimate first-order goal
or I will begin, for debate purposes, not to acknowledge any first-order goal
you might have.
Kent M Pitman <······@world.std.com> writes:
> Scheme eschews any effort to communicate notions of efficiency to
> the processor at all.
Certainly there is no standard way of providing hints to the scheme
system.
> The decision to do f(x) vs to inline the contents of f(x) is an
> important core distinction in CL.
The fact that the most popular commercial lisp, AllegroCL, ignores
inline declarations seems to indicate that not everyone agrees.
> Scheme, on the other hand, has hand-waved away the cost of function
> calls and said they are always cheap. This isn't really possible to
> do.
You are no doubt familiar with
G.L.Steele: "Debunking the `Expensive Procedure Call' Myth",
Proc AMC National Conference (Seattle, Oct 1977)
also AI Memo 443
Function calls can be made *very* cheap --- usually no more than a
half-dozen instructions. In more modern machines, any overhead
associated with a function call is often more than made up for by the
instruction cache hit you would get by inlining.
If the software is dynamically optimized (see HP's Dynamo project) or
`JIT' compiled (see Transmeta) the cost is exactly zero. Even
your run-of-the-mill pentium can avoid overhead here.
What *is* expensive is continuation (stack frame) management and
variable lookup when you have to fetch values from lexical contexts.
> Scheme also doesn't teach people to be concerned about the
> difference between (lambda (x) x) and (lambda () x). These are just
> both functions in Scheme, but in Lisp one is a function and one is a
> closure, and any decent text tells people to be a lot more concerned
> about the latter than the former, since the latter will typically
> cons and the former will not.
There is really no reason to be afraid of consing under normal
circumstances. In the past, before ephemeral GC's and megabyte RAMs,
yes, it was a concern.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Thant <·····@acm.org> writes:
> I got my impressions from the first few chapters of Christian Queinnec's
> "Lisp in Small Pieces". Maybe I've misread him. Maybe he's not as
> clued-in as you are. But you haven't given me or any others still
> bothering to read this thread any reason to give your opinion more
> weight than his.
It's a great book, but there are a number of errors in it with respect
to CL. He uses as reference Steele's CLtL 2nd edition and ANSI CL has
deviated from that in points that matter in his book. I haven't kept
my notes when I was reading it and a casual browse through the index
didn't find what I had in mind, but I remember noticing.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
From: Ray Blaak
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <u3dcpcoo1.fsf@infomatch.com>
Erik Naggum <····@naggum.net> writes:
> If a language is touted as being useful for experimentation, either it is,
> and allows _me_ to think up weird stuff I want to try out, or it is not,
> and allows someone else to tell me what I can be allowed to think up.
> Scheme is touted as good for experimentation, until you actually try to do
> something that some Scheme freak tells you that you should not be
> experimenting with. At that point it is obvious that Scheme is not a
> language suitable for experimentation.
Why be so pendantic about it? Do you really think that I said it is useful
for every single possible kind of experimentation that can exist now or in the
future?
So it is not useful for your kind of experimentation. So what? You use
something else.
The fact of the matter is that Scheme *is* being used for experimentation (it
is primarily a teaching/research language, after all). At the very least *I*
find it useful for experimentation.
At any rate, the original point was that Scheme was missing namespaces, and
even if namespaces were not part of the original design goals, it is still a
good idea to stick them in, because of the current uses of Scheme today.
All this fuss about an off the cuff opinion of mine is definitely not worth
the trouble.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Ray Blaak
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <uzoexb76j.fsf@infomatch.com>
Erik Naggum <····@naggum.net> writes:
> One man's off the cuff opinion is another man's serious issue. If you
> post an unsupportable claim about Scheme to some non-Scheme newsgroup, I
> suggest you prepare for a rebuttal. Not all of us think Scheme is the
> 8th wonder of the world.
Fair enough in as far as that goes.
However, I was not posting an unsupportable claim (in the non-pendantic
sense), and I don't think Scheme is the 8th wonder of the world. Furthermore,
nothing I have said indicates that I think it is either.
I *like* it, but I also like many languages. I am also aware of its warts,
again as with many other languages.
I *dislike* freaks for any language, and intolerance in general.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
> I *dislike* freaks for any language, and intolerance in general.
That's a rather intolerant view.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Ray Blaak
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <uwva1b24v.fsf@infomatch.com>
Joe Marshall <···@content-integrity.com> writes:
> Ray Blaak <·····@infomatch.com> writes:
>
> > I *dislike* freaks for any language, and intolerance in general.
>
> That's a rather intolerant view.
Yes indeed. I am fundamentally against fundamentalists.
It is a contradiction I am willing to live with.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak writes:
>Yes indeed. I am fundamentally against fundamentalists.
>
>It is a contradiction I am willing to live with.
You may be willing to live with it.
But why should others respect this incoherent viewpoint?
--
Fred Gilham ······@csl.sri.com
Jordan Hubbard: We have a crash bug. It needs to be fixed. We DO NOT
need to know how to print 3000 spaces in 11 different languages! :-)
Daniel Sobral: I concur. But if anyone wants to do it with the loader,
: 3kbl 3000 0 do bl emit loop ; 3kbl will do the trick.
From: Ray Blaak
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <ubsrcvv5z.fsf@infomatch.com>
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> Ray Blaak writes:
> >Yes indeed. I am fundamentally against fundamentalists.
> >
> >It is a contradiction I am willing to live with.
>
> You may be willing to live with it.
>
> But why should others respect this incoherent viewpoint?
Why should they indeed? And why shouldn't they? They will or they won't.
Everyone has opinions about what they like/dislike, are tolerant/intolerant
about, etc. Why should others respect any particular opinion?
If I have no friends because of my particular intolerance, then I suppose I
would have to change my attitude, assuming I care enough about not being
lonely. If a large enough group of people share my opinion, then I am ok.
Anyways, I was being a little facetious above. The "joke" is that if one
pretends to hate intolerance, they are in fact being intolerant in that one
case.
Have you ever met anyone who was tolerant about *everything*?
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
> Erik Naggum <····@naggum.net> writes:
> > If a language is touted as being useful for experimentation, either it is,
> > and allows _me_ to think up weird stuff I want to try out, or it is not,
> > and allows someone else to tell me what I can be allowed to think up.
> > Scheme is touted as good for experimentation, until you actually try to do
> > something that some Scheme freak tells you that you should not be
> > experimenting with. At that point it is obvious that Scheme is not a
> > language suitable for experimentation.
>
> Why be so pendantic about it? Do you really think that I said it is useful
> for every single possible kind of experimentation that can exist now
> or in the future?
>
> So it is not useful for your kind of experimentation. So what? You use
> something else.
>
> The fact of the matter is that Scheme *is* being used for experimentation (it
> is primarily a teaching/research language, after all). At the very least *I*
> find it useful for experimentation.
The problem is that the "experimental usefulness envelope" of Scheme
is a strict (and small) subset of the "experimental usefulness
envelope" of Common Lisp. That's all.
Hence you should turn to the Dark Side.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Kent M Pitman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <sfwr9094l5b.fsf@world.std.com>
[ comp.lang.scheme removed.
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Thant Tessman <·····@acm.org> writes:
> Erik Naggum wrote:
>
> > [...] please inform
> > me of how you can give a Scheme real symbols with a functional value in
> > addition to the variable value. That is, suppose I want to _experiment_
> > with the Common Lisp way from within Scheme where the following code has
> > the expected meaning:
> >
> > (define foo (x) (+ 1 x))
> >
> > (let ((foo 41))
> > (foo foo))
>
> Chez Scheme's syntax-case macro system supports syntax extension of
> singleton identifiers. So a CL interpretation of the above Scheme code
> should be possible. But my question is why would you want to? I thought
> the original reason to keep functions in separate namespaces was to
> allow for optimizations that now days aren't really relevant. It
> certainly seems anti-intuitive to me.
No, the original reason is to allow people to use the same name in different
contexts to mean different things.
(defun foo (list)
(loop for x in list
collect (list (third x) (first x))))
where the variable in line 1 is what is referred to in line 2, but where
the function call in line 3 is to the good old trusted LIST function.
You may not have a strong desire to do this, but those of us who like
Lisp2's generally do.
This capability is mirrored in natural language, and we're used to doing
it. The equivalent in English might be "He boxed the boxes." There's
no ambiguity here of the two references to box. We are plenty equipped
in wetware to resolve it contextually; Scheme ignores this ability of
people and tries to make us run with half our brain tied behind our back.
This capability also allows us to understand the well-formedness (if
not the meaning) of pathological sentences like the english "Buffalo
buffalo buffalo." The Spanish "Como como como." is yet another, which
has the virtue of being easier to both easy to see as well-formed but
also intelligible and something you actually might want to say sometimes.
(The english is "subject verb object", by the way, while the Spanish is
"clause connective clause". But the point is that the like-spelled words
mean different things in different contexts, and it's not a burden on the
speaker to figure out... other than that the verb "buffalo" is an obscure
English verb to begin with.)
I cite these natural language cases as evidence that there is a natural
desire to make a namespace distinction, and that it is Scheme which is
arguably unnatural for trying to fight this desire.
From: Dorai Sitaram
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <98602o$k35$1@news.gte.com>
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Thant Tessman <·····@acm.org> writes:
>>
>> But my question is why would you want to? I thought
>> the original reason to keep functions in separate namespaces was to
>> allow for optimizations that now days aren't really relevant. It
>> certainly seems anti-intuitive to me.
>
>No, the original reason is to allow people to use the same name in different
>contexts to mean different things.
>
> (defun foo (list)
> (loop for x in list
> collect (list (third x) (first x))))
>
>where the variable in line 1 is what is referred to in line 2, but where
>the function call in line 3 is to the good old trusted LIST function.
>
>You may not have a strong desire to do this, but those of us who like
>Lisp2's generally do.
>
>This capability is mirrored in natural language, and we're used to doing
>it. The equivalent in English might be "He boxed the boxes." There's
>no ambiguity here of the two references to box. We are plenty equipped
>in wetware to resolve it contextually; Scheme ignores this ability of
>people and tries to make us run with half our brain tied behind our back.
>
>This capability also allows us to understand the well-formedness (if
>not the meaning) of pathological sentences like the english "Buffalo
>buffalo buffalo." The Spanish "Como como como." is yet another, which
>has the virtue of being easier to both easy to see as well-formed but
>also intelligible and something you actually might want to say sometimes.
>(The english is "subject verb object", by the way, while the Spanish is
>"clause connective clause". But the point is that the like-spelled words
>mean different things in different contexts, and it's not a burden on the
>speaker to figure out... other than that the verb "buffalo" is an obscure
>English verb to begin with.)
>
>I cite these natural language cases as evidence that there is a natural
>desire to make a namespace distinction, and that it is Scheme which is
>arguably unnatural for trying to fight this desire.
Not really. There are _two_ sets of word-strings
where the same word-string is used as both noun and
verb, and Lisp1 allows the larger, more intuitive set
whereas Lisp2 allows the smaller, less intuitive set.
These two sets can be characterized by their
representative members "help" and "can".
The word-string "help" can be used as a noun (=
assistance) and as a verb (= to render assistance).
Ie, it is the same word "help", sometimes used as
a noun and sometimes as a verb. Compare with Lisp1
(help me)
(give me help)
The word-string "can" can be used as a noun (=
container). Its Lisp1-like verb counterpart is "can"
in the sense of "put in a can". So far, this is not
different from the "help" example. But there is also
the auxiliary verb "can" denoting ability. This "can"
is unrelated to the container "can" even though
it is spelled like it. The pair "can" (ability) and
"can" (container) therefore exhibit a Lisp2 rather than
a Lisp1 character.
The Lisp1-like set is by far the larger of the two, eg,
help, dig, can (_not_ in the sense of ability, where it
is also Lisp2), head, lead (_not_ in the sense of Pb,
where it is also Lisp2), bed, love, make, do (hair- or
dog-), throw, catch, request, produce, kill, atrophy,
dye, color, sound, impact, requisition, position,
control, function, use, talk, walk, go, say (noun
in "to have a say in the matter"), matter, mind, think
("you've got another think coming"), read (noun in
computerspeak), write, table, list, start, end, figure,
set, structure, email, program, lisp, scheme
and there is no end in sight because the set is
generative rather than a fixed table. Ie, people use
words in Lisp1 fashion intuitively to the extent of
creating Lisp1 usage even if none is authoratitively
sanctioned, even if this activity is sometimes
unavailingly frowned upon as Haigspeak, and even if
"verbing weirds language". <grin> (which, by the way,
is also Lisp1, as also "smile", "laugh", and "humor").
--d
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> No, the original reason is to allow people to use the same name in
> different
> contexts to mean different things.
>
> (defun foo (list)
> (loop for x in list
> collect (list (third x) (first x))))
>
> where the variable in line 1 is what is referred to in line 2, but where
> the function call in line 3 is to the good old trusted LIST function.
>
> You may not have a strong desire to do this, but those of us who like
> Lisp2's generally do.
I not only have no string desire to do this, I have a strong desire to
*not* do it.
A number of people have mentioned this exact same example of "list". I
would have thought that creating a 2nd namespace just to deal with one
historically poorly-named primitive is a bit of an overreaction! Either
rename the primitive to "make-list" (which you can do yourself while
importing the library) or else rename the argument. I'd use "L" myself,
and if it's important that the thing passed is actually a list then I'd
indicate that by declaring the type of the argument explicitly.
> This capability is mirrored in natural language, and we're used to doing
> it. The equivalent in English might be "He boxed the boxes." There's
> no ambiguity here of the two references to box. We are plenty equipped
> in wetware to resolve it contextually; Scheme ignores this ability of
> people and tries to make us run with half our brain tied behind our back.
Actually, I find that both these natural language sentences and programs
that pun names (or nearly pun them, such as MyList and myList) are
unambiguous and possible to understant, but they definitely require a
mental "gear shift" each time I see them, and that takes a non-trivial
part of my mental bandwidth. I don't have much to spare, so try to
economise the use of it where possible!
-- Bruce
From: Janis Dzerins
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <87snkolgxj.fsf@asaka.latnet.lv>
Bruce Hoult <·····@hoult.org> writes:
> Actually, I find that both these natural language sentences and programs
> that pun names (or nearly pun them, such as MyList and myList) are
> unambiguous and possible to understant, but they definitely require a
> mental "gear shift" each time I see them, and that takes a non-trivial
> part of my mental bandwidth. I don't have much to spare, so try to
> economise the use of it where possible!
[almost joking]
See -- you need a "gear shift" to get your other half of brain to get
working. Programming in Lisp1 you don't need that, do you?
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Erik Naggum <····@naggum.net> writes:
> Do you consider the difference between verbs and nouns with the exact
> same spelling anti-intuitive? I don't. Quite the contrary, in fact, I
> consider languages that try desperately to make the verb different from
> the obviously related noun counter-intuitive.
You should drop your obviously germanic assumptions about what is
intuitive in a language. There are plenty of languages where a verb
and a related noun are not spelled the same (Finnish among them), and
I can assure you that the native speakers find it quite intuitive.
In fact, I find the ability to form sentences like "Buffalo buffalo
buffalo" as a shortcoming, not a virtue of the English language.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
From: Valeriy E. Ushakov
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <987f38$1l2v$1@news.spbu.ru>
In comp.lang.lisp Kelloma:ki Pertti <··@arokyyhky.cs.tut.fi> wrote:
> Erik Naggum <····@naggum.net> writes:
>
> > Do you consider the difference between verbs and nouns with the exact
> > same spelling anti-intuitive? I don't. Quite the contrary, in fact, I
> > consider languages that try desperately to make the verb different from
> > the obviously related noun counter-intuitive.
>
> You should drop your obviously germanic assumptions about what is
> intuitive in a language. There are plenty of languages where a verb
> and a related noun are not spelled the same (Finnish among them), and
> I can assure you that the native speakers find it quite intuitive.
As a native speaker of Russian I concur, but I want to add that
languages that can easily verb nouns usually pay the price of fixed
word order. Since all (I believe) programming languages use fixed
word order, germanic language intuition applies to them to a certain
extent - i.e. in the case of Lisp, since postition of a function is
fixed by the word order - why don't exploit this fact and allow puns
(second namespace).
> > I consider context a very valuable part of human communication. A
> > tremendous amount of computer "science" is about destroying the
> > notion of context. I think this is a very serious mistake.
Human languages that "make the verb different from the obviously
related noun" (e.g. Finnish, Russian etc) usually don't do this "to
destroy the notion of context". Such languages just form context in a
different way.
SY, Uwe
--
···@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
"Valeriy E. Ushakov" <···@ptc.spbu.ru> writes:
> Since all (I believe) programming languages use fixed word order...
Damien Conway suggests using a computer language that uses inflection
rather than fixed word order. He has written a module that translates
Latin into Perl.
maximum inquementum tum biguttam egresso scribe.
meo maximo vestibulo perlegamentum da.
da duo tum maximum conscribementa meis listis.
dum listis decapitamentum damentum nexto
fac sic
nextum tum novumversum scribe egresso.
lista sic hoc recidementum nextum cis vannementa da listis.
cis.
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Kent M Pitman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <sfwg0golksh.fsf@world.std.com>
[ comp.lang.scheme removed.
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Kellom{ki Pertti <··@arokyyhky.cs.tut.fi> writes:
>
> Erik Naggum <····@naggum.net> writes:
> > Do you consider the difference between verbs and nouns with the exact
> > same spelling anti-intuitive? I don't. Quite the contrary, in fact, I
> > consider languages that try desperately to make the verb different from
> > the obviously related noun counter-intuitive.
>
> You should drop your obviously germanic assumptions about what is
> intuitive in a language. There are plenty of languages where a verb
> and a related noun are not spelled the same (Finnish among them), and
> I can assure you that the native speakers find it quite intuitive.
>
> In fact, I find the ability to form sentences like "Buffalo buffalo
> buffalo" as a shortcoming, not a virtue of the English language.
The fact that you can get used to a one namespace system doesn't prove
that it's unnatural for others to use a two namespace system.
The world can accomodate both needs.
Tolerance here demands that people from each community understand that the
others desires are reasonable and legitimate. There is nothing that
uniquely determines either a Lisp1 or a Lisp2 as conceptually best.
What's clear is that people can, if they want to, accomodate a Lisp2
mentally; it's inappropriate to claim that Lisp2 is necessarily harder to
think about. But if all you want ot say is that there are some people who
can live with and even enjoy a Lisp1, certainly the popularity of Scheme
is enough testimony to that.
As a general meta-rule, I've found in life that it'e far easier to
learn to like a new thing you didn't used to like than to learn to
unlike something you like. It's far more likely that Lisp1 people can
learn to appreciate the Lisp2 point of view, or vice versa, than that
a Lisp1 person can be taught to not like Lisp1 or that a Lisp2 person
can be taught to not like a Lisp2. People on both sides of this
debate should stop trying to convince people to unlike what they like.
It won't work...
Kent M Pitman <······@world.std.com> writes:
> Tolerance here demands that people from each community understand that the
> others desires are reasonable and legitimate. There is nothing that
> uniquely determines either a Lisp1 or a Lisp2 as conceptually best.
Exactly. I have no problems understanding how people would like a
Lisp2 better than a Lisp1. I have a very hard time understanding
people who think that a Lisp2 is some kind of global optimum. Maybe I
am reading too much to some of the postings here, but I get the
impression that this is a belief held by many people (not you, though).
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
From: Kent M Pitman
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <sfwofvcmi2p.fsf@world.std.com>
Kellom{ki Pertti <··@arokyyhky.cs.tut.fi> writes:
> Kent M Pitman <······@world.std.com> writes:
> > Tolerance here demands that people from each community understand that the
> > others desires are reasonable and legitimate. There is nothing that
> > uniquely determines either a Lisp1 or a Lisp2 as conceptually best.
>
> Exactly. I have no problems understanding how people would like a
> Lisp2 better than a Lisp1. I have a very hard time understanding
> people who think that a Lisp2 is some kind of global optimum. Maybe I
> am reading too much to some of the postings here, but I get the
> impression that this is a belief held by many people (not you, though).
My best attempt to be neutral on this point says that the problem, at least
from the lisp2 side, is "provoked" when lisp1 folk try to assert a metric of
"simplicity" that says that what I personally think is essentially an
arbitrary preference should dominate for reasons of simplicity.
I personally define simplicity in this context as a deviation from a desired
norm which has been determined suitable for a purpose. I am perhaps exprssing
this badly, but my point is that simplicity arguments are inappropriate here
because those of us who use Lisp2 are wanting the noun/verb distinction in
our programming languages to map to the noun/verb distinction in our human
languages. That you want the non-distinction in your programming language
to map to the non-distinction in your natural language is neither more nor
less simple. It is equivalently simple.
What appears to cause people from the lisp2 community to get up in arms is
when people from the Scheme community apply their personal notions of
simplicity without questioning whether those notions of simplicity are
uniquely determined and acceptable to all parties of the conversation.
Reflecting back a meta-level, then, one also needs to tolerate that each
community has actually different notion of simplicity.
I often repeat the mantra:
There are two kinds of people in the world: people who think there are
two kinds of people and people who don't.
I don't know who originally said it, but it captures the humor/frustration
of talking between these two cultures. The design of Scheme, in its attempt
to find a one and only one right way to do each thing, tends to attract
people who think that there IS one and only one right way to do each thing,
some of them not appearing to understand that there are multiple right ways.
As such, the kind of intolerance we see from the Scheme community appears
to be a consistent desire to beat out alternate ways of doing things.
The sort of programmatic equivalent of people who program with polar
coordinates trying to beat down fans of cartesian coordinates, or vice versa.
The hard thing to appreciate is that the lisp2 community is not built of
people who are uniformly tolerant either. Instead, we are built of people
who often want, to use my previous metaphor, either polar coordinates or
cartesian coordinates, but we want to live in a world where we don't get
beaten up for it. But when provoked into a fight, many of our people will
respond defensively of their preferred stlye (which is usually one or the
other, not both, and so they will appear to be defending a single way of
life.. but that's usually just an artifact of the way the discussion begins
and the way people get hot and out of control quickly when taken by surprise
in a debate they are not used to being in). I don't doubt that some of us
here (I'll assume I'm included in this, though I have no specific examples,
mostly because it's just human nature) are at least some of the time saying
things that are more inspired by anger than reason because the initial
question which appears to have provoked things was "intolerant", and that
makes people see red, and once you see red, it's hard to see much else.
Kellom{ki Pertti <··@arokyyhky.cs.tut.fi> writes:
> Kent M Pitman <······@world.std.com> writes:
> > Tolerance here demands that people from each community understand that the
> > others desires are reasonable and legitimate. There is nothing that
> > uniquely determines either a Lisp1 or a Lisp2 as conceptually best.
>
> Exactly. I have no problems understanding how people would like a
> Lisp2 better than a Lisp1. I have a very hard time understanding
> people who think that a Lisp2 is some kind of global optimum. Maybe I
> am reading too much to some of the postings here, but I get the
> impression that this is a belief held by many people (not you, though).
The vehemence you'll encounter in this debate from the Lisp2 side IMHO
mostly stems from the fact that nearly all of the discussions on Lisp1
vs. Lisp2 start off with an attack from a Lisp1-supporter on Lisp2,
daring us to defend our "obviously flawed" Lisp2 approach, usually not
pausing for a second to realize that maybe the Lisp1 approach needs as
much defending, as the Lisp2 approach. There usually is this
underlying bias towards a Lisp1, in that it should somehow be the
default case, and we'd better have very good reasons to defend our
deviation (i.e. Occam's razor applied). That we might legitimately
consider it the other way round is dismissed out of hand.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Kellom{ki Pertti <··@arokyyhky.cs.tut.fi> writes:
> In fact, I find the ability to form sentences like "Buffalo buffalo
> buffalo" as a shortcoming, not a virtue of the English language.
I guess that baffling bovids are less common in Finland than in New York.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: George Neuner
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <3aa9615d.198093022@helice>
On 08 Mar 2001 09:14:44 -0500, Joe Marshall
<···@content-integrity.com> wrote:
>Kellom{ki Pertti <··@arokyyhky.cs.tut.fi> writes:
>
>> In fact, I find the ability to form sentences like "Buffalo buffalo
>> buffalo" as a shortcoming, not a virtue of the English language.
>
>I guess that baffling bovids are less common in Finland than in New York.
>
AFAIK there is only one Buffalo in New York and FWIW, the 'a' is
silent. 8-)
I'm not aware of any actual buffalo [the animal] here in North
America, although there could be a couple stuck in a zoo somewhere.
Our native critter is the bison, which is only distantly related to
the african or asian buffalo.
We now return to our regularly scheduled program.
George
From: Barry Margolin
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <T6eq6.48$%h5.24649@burlma1-snr2>
In article <··················@helice>, George Neuner <·······@dyn.com> wrote:
>On 08 Mar 2001 09:14:44 -0500, Joe Marshall
><···@content-integrity.com> wrote:
>
>>Kellom{ki Pertti <··@arokyyhky.cs.tut.fi> writes:
>>
>>> In fact, I find the ability to form sentences like "Buffalo buffalo
>>> buffalo" as a shortcoming, not a virtue of the English language.
>>
>>I guess that baffling bovids are less common in Finland than in New York.
>>
>
>AFAIK there is only one Buffalo in New York and FWIW, the 'a' is
>silent. 8-)
>
>I'm not aware of any actual buffalo [the animal] here in North
>America, although there could be a couple stuck in a zoo somewhere.
>Our native critter is the bison, which is only distantly related to
>the african or asian buffalo.
One of the wonderful features of human languages is that they can be used
to refer to things that don't exist (dinosaurs, buffalo), and even things
that cannot possibly exist (a barber who shaves all the people in town who
don't shave themselves). We can have discussions about whether an
omnipotent god can create something too heavy for himself to lift.
If the power of language comes at the cost of allowing some sentences that
are a little difficult to parse, I think it's a worthwhile tradeoff.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
·······@dyn.com (George Neuner) writes:
> I'm not aware of any actual buffalo [the animal] here in North
> America, although there could be a couple stuck in a zoo somewhere.
> Our native critter is the bison, which is only distantly related to
> the african or asian buffalo.
Yep. Of course, most people from the US will identify the bison as a
`buffalo'. So many, in fact, that this is considered a standard
definition in Merriam-Webster (despite it being scientifically
inaccurate).
Pedantically yours,
jrm
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Kellom{ki Pertti <··@arokyyhky.cs.tut.fi> writes:
> Erik Naggum <····@naggum.net> writes:
> > Do you consider the difference between verbs and nouns with the exact
> > same spelling anti-intuitive? I don't. Quite the contrary, in fact, I
> > consider languages that try desperately to make the verb different from
> > the obviously related noun counter-intuitive.
>
> You should drop your obviously germanic assumptions about what is
> intuitive in a language. There are plenty of languages where a verb
> and a related noun are not spelled the same (Finnish among them), and
> I can assure you that the native speakers find it quite intuitive.
As a student of Finnish[1] let me say that although that is true in
theory it does not seem to be the case in practice. I cannot begin to
count the number of times I have been totally confused or
misunderstood because of two totally unrelated words which have the
same spelling. Agreed, this does not directly parallel the "buffalo"
case above where one could argue that a noun has been verbed since
there would be a verb marker added to the stem word. The pifalls in
Finnish come from the complex interactions between the cases,
declensions, and tenses in the language. In many cases one cannot
look at a word in isolation and know what it means. For instance
"tuli" means fire but it is also one of the past tense forms of
"tulla" which means "to come".
When you look at the actual linguistic processes that are going on in
Finnish you will see that there are several instances when the same
transformations are used in forming conjugations and declensions which
are parallel. For instance many of the infinitive markers that are
used with verbs, like "-a" and "-[l]la", perform different tasks like
indicating "some" and "on top of" when applied to nouns and
adjectives. The "I do" form of a verb and the genitive of a noun are
formed identically. This is really a good thing since you only need
to internalize one transformation and the you can use it to convey
different meanings in different situations.
In English the collision between a noun and its verbed form are clear,
in Finnish the collision will be more subtle. It won't generally
collide directly, rather, some specific forms will collide with other
unrelated words. So in reality the situation in Finnish is very much
a parallel to the English situation it is just that the lines are
drawn in different places.
To address the point that my comparison is disingenuous since I am
allowing all the forms of a given word in Finnish the same thing is
being done in the English example. The infinitive of "buffalo" in
English is "to buffalo". Just because the English case uses a marker
word it is not fundamentally different from an infinitive marking
suffix.
Finally, to try to pull this back into something related to Lisp and
Scheme I would have to say that Finnish is most certainly not a Lisp1
but rather a Lisp2 in the case of verbs and nouns. If I really wanted
to push it I would say that Finnish is a Lisp(N) with dynamic name
space creation. That is a given verb establishes a set of relevant
name spaces in which the other words are gathered via cases. For
instance consider the verb "to look" = "katsoa"
Verb Katsoa:
Name Space #1 (case +a): That which is looked at:
Koira+a - dog
Iso+a - big
Name Space #2 (case +sta): From something, through
Ikkuna+sta - window
Name Space #3 (case +lla): Via some means
Kaukoputki+lla - telescope
Vanha+lla - old
Name Space #4 (case nominative): Who is looking.
Pekka - a name (must match verb declension)
This allows us to create sentences like:
"Pekka katsoi isoa koiraa ikkunasta vanhalla kaukoputkilla."
"Pekka katsoi ikkunasta vanhalla kaukoputkilla isoa koiraa."
"Isoa koiraa Pekka katsoi ikkunasta vanhalla kaukoputkilla."
The word order doesn't matter since the the case markers sort our the
roles played by the various objects and well as to which objects the
adjectives belong. The reason I say that this is dynamic is that
different verbs take different cases and assign different meanings to
those cases. This is a direct parallel with the use of propositions in
English. There is a parallel between function calls in Ada and Lisp
in here also but this is getting too long as it is.
>
> In fact, I find the ability to form sentences like "Buffalo buffalo
> buffalo" as a shortcoming, not a virtue of the English language.
Here is a good example of a Finnish conversation which illustrates its
virtue over the English language.:-):-):-):-):-):-):-):-)
Person 1: "Kokko, Kokoon koko kokko."
("Kokko, gather together the whole bonfire.")
Person 2: "Kokoko kokko?"
("The _whole_ bonfire?")
Person 1: "Koko kokko, Kokko."
("The whole bonfire, Kokko.")
All in good fun,
-Eric "Will they still let me visit..." Dahlman
> --
> Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
Footnotes:
[1] Actually, what I have learned is a heavy Savo dialect
of Finnish. If I admitted that though I would have even less
credibility than I do already.
From: Lieven Marchand
Subject: Re: OT: Finnish name spaces (was: Re: please tell me the design faults of CL & Scheme)
Date:
Message-ID: <m3elw89gat.fsf@localhost.localdomain>
eric dahlman <·······@cs.colostate.edu> writes:
> Finally, to try to pull this back into something related to Lisp and
> Scheme I would have to say that Finnish is most certainly not a Lisp1
> but rather a Lisp2 in the case of verbs and nouns. If I really wanted
> to push it I would say that Finnish is a Lisp(N) with dynamic name
> space creation. That is a given verb establishes a set of relevant
> name spaces in which the other words are gathered via cases.
I find the grammar of Finnish reasonably clear and orthogonal, once
you get used to the agglutinating type of language, which is hard for
Indo-European speakers. Finnish has the morphology from hell, though.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
From: Martti Halminen
Subject: Re: OT: Finnish name spaces (was: Re: please tell me the design faults of CL & Scheme)
Date:
Message-ID: <3AA8BF8C.3DA8E30C@solibri.com>
eric dahlman wrote:
>
>
> Verb Katsoa:
> Name Space #3 (case +lla): Via some means
> Kaukoputki+lla - telescope
> Vanha+lla - old
It isn't this simple: while "kaukoputki" is singular, "kaukoputkilla" is
plural, i.e. you're looking with several telescopes. "kaukoputkella"
would be using just one.
> This allows us to create sentences like:
>
> "Pekka katsoi isoa koiraa ikkunasta vanhalla kaukoputkilla."
> "Pekka katsoi ikkunasta vanhalla kaukoputkilla isoa koiraa."
> "Isoa koiraa Pekka katsoi ikkunasta vanhalla kaukoputkilla."
>
> The word order doesn't matter since the the case markers sort our the
> roles played by the various objects and well as to which objects the
> adjectives belong.
Strictly speaking the word order is still significant: these sentences
have different implications on which data is the important part of the
sentence.
> Here is a good example of a Finnish conversation which illustrates its
> virtue over the English language.:-):-):-):-):-):-):-):-)
- Well, obviously a rather contrived example.
> Person 1: "Kokko, Kokoon koko kokko."
> ("Kokko, gather together the whole bonfire.")
> Person 2: "Kokoko kokko?"
This should be "Koko kokkoko?".
--
From: eric dahlman
Subject: Re: OT: Finnish name spaces (was: Re: please tell me the design faults of CL & Scheme)
Date:
Message-ID: <tz4bsra6hbj.fsf@sibelius.cs.colostate.edu>
Martti Halminen <···············@solibri.com> writes:
> eric dahlman wrote:
> [snip -ed]
>
> It isn't this simple: while "kaukoputki" is singular, "kaukoputkilla" is
> plural, i.e. you're looking with several telescopes. "kaukoputkella"
> would be using just one.
You cut the bit where I mentioned that Finnish was not my mother
tongue, the i->e thing was just sloppy on my part. I expected to be
taken to task for something in that example, I just made it up off the
top of my head. I am kind of proud of myself if that was the only nit
to pick.
>
>
> > This allows us to create sentences like:
> >
> > "Pekka katsoi isoa koiraa ikkunasta vanhalla kaukoputkilla."
> > "Pekka katsoi ikkunasta vanhalla kaukoputkilla isoa koiraa."
> > "Isoa koiraa Pekka katsoi ikkunasta vanhalla kaukoputkilla."
> >
> > The word order doesn't matter since the the case markers sort our the
> > roles played by the various objects and well as to which objects the
> > adjectives belong.
> Strictly speaking the word order is still significant: these sentences
> have different implications on which data is the important part of the
> sentence.
That is true and I am sorry if I gave the impression that the word
order did not carry some emphatic information. I was arguing from the
earlier poster's position that word order did not matter at all. It
just seemed a little too pedantic to go into the subtle implications
of word order since my post had already gotten way too long. In an on
topic sort of way this only goes to reinforce the position that
Finnish is not a Lisp1. By the way I kept the modifier+nouns together
because anything else sounded stupid but would something like:
"Isoa ikkunasta vanhalla Pekka katsoi koiraa kaukoputkella."
be parseable by a native speaker? I certainly would not imagine
anyone speaking that way but it has a strangely poetic quality.
> > Here is a good example of a Finnish conversation which illustrates its
> > virtue over the English language.:-):-):-):-):-):-):-):-)
>
> - Well, obviously a rather contrived example.
Well, obviously eight smilies preceded the example ;-) I also do not
think that it is any more contrived than the "Buffalo buffalo buffalo"
example it was contrasted with.
>
> > Person 1: "Kokko, Kokoon koko kokko."
> > ("Kokko, gather together the whole bonfire.")
> > Person 2: "Kokoko kokko?"
>
> This should be "Koko kokkoko?".
I just called my "Native Speaker" wife on this one and she agreed with
my original rendition. I feel that it emphasizes the whiney "Do I
gotta do the *whole* thing?" character of the response. Whereas your
version is more a matter-of-fact-did-I-miss-something-you-said type
response.
-Eric
From: Martti Halminen
Subject: Re: OT: Finnish name spaces (was: Re: please tell me the design faults of CL & Scheme)
Date:
Message-ID: <3AA90B47.76E85120@solibri.com>
eric dahlman wrote:
>... In an on
> topic sort of way this only goes to reinforce the position that
> Finnish is not a Lisp1. By the way I kept the modifier+nouns together
> because anything else sounded stupid but would something like:
>
> "Isoa ikkunasta vanhalla Pekka katsoi koiraa kaukoputkella."
>
> be parseable by a native speaker? I certainly would not imagine
> anyone speaking that way but it has a strangely poetic quality.
It would be understandable, though decidedly odd-sounding.
> > This should be "Koko kokkoko?".
>
> I just called my "Native Speaker" wife on this one and she agreed with
> my original rendition. I feel that it emphasizes the whiney "Do I
> gotta do the *whole* thing?" character of the response. Whereas your
> version is more a matter-of-fact-did-I-miss-something-you-said type
> response.
That particular phrase was stated to be an error in my Finnish grammar
book, IIRC. On the other hand I haven't read that book in 20 years, so I
might be wrong.
--
In article <·················@solibri.com>,
Martti Halminen <···············@solibri.com> wrote:
>eric dahlman wrote:
>>... In an on
>> topic sort of way this only goes to reinforce the position that
>> Finnish is not a Lisp1. By the way I kept the modifier+nouns together
>> because anything else sounded stupid but would something like:
>>
>> "Isoa ikkunasta vanhalla Pekka katsoi koiraa kaukoputkella."
>>
>> be parseable by a native speaker? I certainly would not imagine
>> anyone speaking that way but it has a strangely poetic quality.
>
>It would be understandable, though decidedly odd-sounding.
It may be understandable, but not grammatical. The _order_ of the
constituents in a phrase is free in Finnish, but you still have to keep them
in one piece. "vanhalla kaukoputkella" is an NP, you can't put extraneous
stuff inside it. Likewise for "isoa koiraa".
Well, actually, in Finnish there _are_ cases where it might be arguably
legal to have non-continuous constituents, but this is not one of those.
This discussion really belongs to either sci.lang or sfnet.keskustelu.kieli...
Lauri Alanko
··@iki.fi
Lauri Alanko <··@iki.fi> writes:
> The _order_ of the constituents in a phrase is free in Finnish, but
> you still have to keep them in one piece. "vanhalla kaukoputkella"
> is an NP, you can't put extraneous stuff inside it.
So that would make NP complete....?
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Not much to do with CL or Scheme any more, so I should probably
refrain. This is Usenet, though, so...
Erik Naggum <····@naggum.net> writes:
> If Scheme users are predominantly Finnish, then it would make sense to
> bring this argument up. Since Scheme was designed by English-speaking
> people, do you think they were politically correct in catering to what
> people in some miniscule foreign country find intuitive?
Of course not, but I'm glad their choice makes sense to me.
> Incidentally, Norwegian tends to append an "e" to a noun to make it a
> verb. house -> house in English, hus -> huse in Norwegian. list -> list
> in English, liste -> liste in Norwegian. ran -> rane in Norwegian,
> robbery -> rob in English. interest -> interest in English, interesse ->
> interessere in Norwegian.
So Norwegian is counter-intuitive to you? Earlier you wrote:
> Erik Naggum <····@naggum.net> writes:
> > Quite the contrary, in fact, I
> > consider languages that try desperately to make the verb different from
> > the obviously related noun counter-intuitive.
> So obviously _germanic_ assumptions, eh?
I knew I was going to be shot for this.
> Anything that can increase playfulness is
> good, and English is a just plain _fun_ language with its very rich
> overloading of meaning. Of course, if you don't think lexicography is
> fun and you don't read (or produce) dictionaries, you may come to a
> different conclusion.
Ambiguity caused by overloading can indeed be fun. Somehow it is not a
property I would want from my programming language, though.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
In article <···············@arokyyhky.cs.tut.fi>, Kellom{ki Pertti
<··@arokyyhky.cs.tut.fi> wrote:
...deleted
>
> Ambiguity caused by overloading can indeed be fun. Somehow it is not a
> property I would want from my programming language, though.
This viewpoint is argued for in OOSC(2) by Bertrand Meyer. He is talking
about Eiffel, and not Scheme, but makes a convincing case (IMHO).
Erik Naggum <····@naggum.net> writes:
> * Erik Naggum
> > How do I get real symbols in Scheme? How do I get two namespaces? How
> > do I get a programmable reader that the compiler will also obey? How do
> > I get packages?
>
> * David Rush
> > These are all well-solved problems, Erik. If you bothered to be as
> > well-informed on Scheme as you are on CL, you would know that.
>
> Obviously, I'm not, so instead of such idiotic "arguments", please inform
> me of how you can give a Scheme real symbols with a functional value in
> addition to the variable value. That is, suppose I want to _experiment_
> with the Common Lisp way from within Scheme where the following code has
> the expected meaning:
>
> (define foo (x) (+ 1 x))
>
> (let ((foo 41))
> (foo foo))
>
> If this is all well-solved problem, David, you should be able to whip up
> at least one URL for me. Thank you in advance.
I don't see why it is a problem at all. Is there some task that you
can't accomplish because of this?
From: David Rush
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <okfzoewh8wp.fsf@bellsouth.net>
Erik Naggum <····@naggum.net> writes:
Thank you Erik, you have proven entirely true to form.
> * David Rush
> > These are all well-solved problems, Erik. If you bothered to be as
> > well-informed on Scheme as you are on CL, you would know that.
>
> Obviously, I'm not, so instead of such idiotic "arguments", please inform
> me of how you can give a Scheme real symbols with a functional value in
> addition to the variable value.
Not exactly what you want, but indicative of the way in which you'd
go about it (and also IMO a particularly gross hack)
SRFI-17 <http://srfi.schemers.org/srfi-17>
> That is, suppose I want to _experiment_
> with the Common Lisp way from within Scheme where the following code has
> the expected meaning:
You mean "the meaning Erik Naggum expects". I (and others) do not
consider that meaning reasonable. In fact many find it confusing or
indicative of sloppy thinking.
> (define foo (x) (+ 1 x))
> (let ((foo 41))
> (foo foo))
I believe that I could devise some magic within a letrec-syntax, but
why would I bother? I'd have a chunk of Common Lisp floating
about. Now, since you're happy with having differing notations for
differing uses of identifiers, what's wrong with:
(define (foo x) (+ 1 x))
(let-context ((foo 41))
(foo (in-context 'foo)))
This is the same argument as your your argument for #'foo.
david rush
--
To get anywhere with programming we must be free to discuss and
improve subjective phenomena. and leave the objective metrics to
resultants such as bug reports.
-- The Programmer's Stone (Alan Carter & Colston Sanger)
From: David Rush
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <okfvgpkgzjs.fsf@bellsouth.net>
Erik Naggum <····@naggum.net> writes:
> * David Rush <····@bellsouth.net>
> > Thank you Erik, you have proven entirely true to form.
>
> Your "argument" was just plain idiotic, just what you know that I
> hate
Argument via authority is your standard tactic in c.l.l. I was
wondering if you would recognize its validity elsewhere...
> tell me that you did it in order to have your prejudices proven,
No I did not say that. I said that my expectation did occur.
I argued from authority in order to shut you up.
> you continue to refuse to do something smarter.
I answered your questions, too. Didn't I?
> You're doing a lot of good work to confirm my general impression of
> Scheme freaks as extremely uptight people, too.
PKB.
> One of the reasons I dislike Scheme is that it's such a religious
> cult, and I _really_ dislike religious cults.
And Naggum-ism isn't?
> > You mean "the meaning Erik Naggum expects". I (and others) do not
> > consider that meaning reasonable. In fact many find it confusing or
> > indicative of sloppy thinking.
>
> In other words: "Don't experiment with that!"
No. It means that your expectations are not considered universally
reasonable. Why must you infer that I mean more than I say?
> Which means, in plain language, that Scheme sucks unless you buy
> into _all_ of its mindset.
Which means, in plain language, *that Erik Naggum thinks* that Scheme
sucks unless you buy into all of its mindset. You continually confuse
your opinions with facts. The technical issue (disambiguating
identifier semantics via syntactic context) has been resolved in a
reasonable way (which you personally dislike) in Scheme. That it takes
effort (which you are apparently unwilling to spend) to code
differently, should not be surprising to one of your deep insight into
language design issues. It certainly does not mean that Scheme sucks.
In fact if I were to follow your logic perfectly, I would be saying
that CL sucks. But that's not terribly logical, is it?
> Since I consider that mindset a symptom of a mental disorder, what do I
> care that you consider it "confusing" or "sloppy thinking"?
This refers to the alleged religious mind-set of the Scheme community,
does it? You haven't proven your assertion. That seems to be sloppy
thinking to me.
> If I want to experiment with something, the _last_ thing I need is some
> Scheme freak come and tell me that I shouldn't do it because it doesn't
> fit the Scheme religion.
I *never* said that. I merely questioned the universality of your
assumptions. Who is behaving like a religious maniac here?
>If Scheme is really good for experimentation,
Actually, I never claimed that either. The discussion is about what in
the languages is "broken by design". As someone else pointed out, you
have to consider the design goals is answering that question. *I* like
Scheme for engineering. Clean, regular semantics go a long, long,
way. There *are* some significant holes in Scheme, but discussing them
with you would be pointless.
> insisting that people who want something that Scheme cannot offer
> are wrong-headed.
Wrong again, Erik. I'm just suggesting that *you* are wrong-headed,
dogmatic, close-minded, arrogant, and slanderous. Unfortunately, you
are also pretty smart so it's easy for you to bully people around in
c.l.l. It's clear that you don't know what you're talking about here,
and that you are not actually interested in learning anything either.
> That's so _uninteresting_.
My point. Follow-ups set to c.l.l where they appear to *like* this
sort of thing...
david rush
--
Finding a needle in a haystack is a lot easier if you burn down the
haystack and scan the ashes with a metal detector.
-- the Silicon Valley Tarot
From: David Rush
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <okfae6uhlfj.fsf@bellsouth.net>
Erik Naggum <····@naggum.net> writes:
> * David Rush
> > I argued from authority in order to shut you up.
>
> You are indeed true to form, David.
As you are also, Erik.
david rush
--
If you give someone Fortran, he has Fortran.
If you give someone Lisp, he has any language he pleases.
-- Guy L. Steele Jr.
From: Tim Bradshaw
Subject: Re: please tell me the design faults of CL & Scheme
Date:
Message-ID: <ey3n1azneso.fsf@cley.com>
* Harvey J Stein wrote:
> Scheme was intended to be simple and concise. If all the "design
> faults" people have mentioned were incorporated into the language,
> then it wouldn't be simple & concise any longer. It would no longer
> meet its design criteria & *then* would have a design fault.
I think that the CL attitude would be that simple and concise *is* a
design fault in a language design, because it leads to complex and
verbose programs. At least both scheme and CL are doing better than
C++ which succeeds neither in being a simple and concise language nor
in allowing simple and concise programs!
--tim