from my computation linguistics class about why it's a bad idea
to use linguistic arguments for language issues:
1.) We polish the Polish furniture.
2.) He could lead if he would get the lead out.
3.) A farm can produce produce.
4.) The dump was so full it had to refuse refuse.
5.) The soldier decoded to desert in the desert.
6.) The resent is a good time to present the present.
7.) At the Army base, a bass was painted on the head of a bass drum.
8.) The dove dove into the bushes.
9.) I did not object to the object.
10.) The insurance for the invalid was invalid.
11.) The bandage was wound around the wound.
12.) There was a row among the oarsmen about how to row.
13.) The were too close to the door to close it.
14.) The buck does funny things when the does are present.
15.) They sent a sewer down to stitch the tear in the sewer line.
16.) To help with planting, the farmer taught his sow to sow.
17.) The wind was too strong to wind the sail.
18.) After a number of Novocain injections, my jaw got number.
19.) I shed a tear when I saw the tear in my clothes.
20.) I has to subject the subject to a series of tests.
21.) How can I intimate this to my most intimate friend?
22.) I spent last evening evening out a pile of dirt.
Now let's see a lot of English words have multiple meanings. Let's not waste
a lot of bandwidth arguing about what "free" or "lisp" mean and just accept
that one word can mean many different things as my list has shown.
Try arguing that one word can only mean one thing with all the sentences on
this list; if you are successful, pat your selves on the back--you have just
made computation linguistics much much simpler. :-D
"Franz Kafka" wrote :
> 1.) We polish the Polish furniture.
I heard Microsoft has a fund to fund deeps discounts of
their software so entire governments wouldn't switch to
open source. "Under NO circumstances lose to Linux"
said an internal MS e-mail, supposedly. But Germany
(or some German city) rejected the offer and decided to
switch anyway. Is this true?
"c hore" <·······@yahoo.com> wrote in message
·································@posting.google.com...
> "Franz Kafka" wrote :
> > 1.) We polish the Polish furniture.
>
> I heard Microsoft has a fund to fund deeps discounts of
> their software so entire governments wouldn't switch to
> open source. "Under NO circumstances lose to Linux"
> said an internal MS e-mail, supposedly. But Germany
> (or some German city) rejected the offer and decided to
> switch anyway. Is this true?
this was russia too from what I remember?...
"c hore" <·······@yahoo.com> wrote in message
·································@posting.google.com...
> "Franz Kafka" wrote :
> > 1.) We polish the Polish furniture.
>
> I heard Microsoft has a fund to fund deeps discounts of
> their software so entire governments wouldn't switch to
> open source. "Under NO circumstances lose to Linux"
> said an internal MS e-mail, supposedly. But Germany
> (or some German city) rejected the offer and decided to
> switch anyway. Is this true?
The people who Microsoft keep away from Linux, turn to warez, so Microsoft
is loosing the war but winning the battle.
The MS OS is passed around like E at a Rave; the authorities don't like it
but it's done anyway. :-D
From: Martin Rubey
Subject: Re: For People who use Linguistic arguments here is a list
Date:
Message-ID: <whfd6hwbsda.fsf@invite02.labri.fr>
·······@yahoo.com (c hore) writes:
> I heard Microsoft has a fund to fund deeps discounts of
> their software so entire governments wouldn't switch to
> open source. "Under NO circumstances lose to Linux"
> said an internal MS e-mail, supposedly. But Germany
> (or some German city) rejected the offer and decided to
> switch anyway. Is this true?
Yes, nearly. Munich rejected Microsofts offer on May 28 I believe. It is nearly
certain that IBM/SUSE will win, though there are other offers to consider, too.
The last part ("though ...") seems very strange to me, look it up yourself:
http://derstandard.at/standard.asp?id=1318215
or
http://derstandard.at/standard.asp?id=1315877
(this is an Austrian newspaper, you might be better off finding a German, or
Munich specific one)
Martin
·······@yahoo.com (c hore) writes:
> I heard Microsoft has a fund to fund deeps discounts of
> their software so entire governments wouldn't switch to
> open source. "Under NO circumstances lose to Linux"
> said an internal MS e-mail, supposedly. But Germany
> (or some German city) rejected the offer and decided to
> switch anyway. Is this true?
It was M�nchen which is one of the largest cities in Germany.
And yes it is true.
Oh and ... No. M�nchen isn't capital of germany. Neither is it germany.
And No. This is not Lisp related
Norman
--
Norman Werner (Zi. 307)
J. G. Nathusius Ring 7 (WH6)
39106 Magdeburg
·············@student.uni-magdeburg.de
Norman Werner <·············@student.uni-magdeburg.de> writes:
> ·······@yahoo.com (c hore) writes:
>
>
> > I heard Microsoft has a fund to fund deeps discounts of ... [snip]...
^^^ ^^^
Seems nobody caught this, nobody noticed the English-2. Goes to show
that Lisp-2 ought to be a natural fit for the human mind.
> And No. This is not Lisp related
Well, I think it is. You just did not notice because you were focusing
on the surface meaning of the words. That you were able to do so shows
that it is possible to disambiguate the various meanings a word has
without even thinking about it.
--
H�kon Alstadheim, hjemmepappa.
From: Karl A. Krueger
Subject: Re: For People who use Linguistic arguments here is a list
Date:
Message-ID: <bbi6jv$1ug$1@baldur.whoi.edu>
H?kon Alstadheim <······@online.no> wrote:
> Norman Werner <·············@student.uni-magdeburg.de> writes:
>> ·······@yahoo.com (c hore) writes:
>>
>> > I heard Microsoft has a fund to fund deeps discounts of ... [snip]...
> ^^^ ^^^
> Seems nobody caught this, nobody noticed the English-2. Goes to show
> that Lisp-2 ought to be a natural fit for the human mind.
So it should be written: I heard Microsoft has a fund to #'fund ... :)
You know, as a CL newbie with some Scheme background I never found Lisp-2
at all confusing. The rule can be stated very easily: "When you are
referring to a function rather than calling it, mark its name with a
sharp-quote. And you're allowed to have a variable with the same name
as a function, like 'list', because the preceding rule makes it never
ambiguous which one you mean."
What is supposed to be so hard about that for me?
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
From: Pascal Costanza
Subject: Re: For People who use Linguistic arguments here is a list
Date:
Message-ID: <3EDCC346.40904@web.de>
Karl A. Krueger wrote:
> You know, as a CL newbie with some Scheme background I never found Lisp-2
> at all confusing. The rule can be stated very easily: "When you are
> referring to a function rather than calling it, mark its name with a
> sharp-quote. And you're allowed to have a variable with the same name
> as a function, like 'list', because the preceding rule makes it never
> ambiguous which one you mean."
>
> What is supposed to be so hard about that for me?
My current tentative conclusion is that the Lisp-1 vs. Lisp-2 discussion
is a red herring. It's just part of a possible technical solution for a
totallly different issue.
In a certain functional programming style, as obviously preferred to a
certain extent by Schemers, you want to treat the first position of an
sexpr as all the other positions. This makes it possible to write code
like this:
(let ((f (lambda (x) (+ x x)))
(g (lambda (x) (lambda (y) (+ x y)))))
(f ((g 5) 6)))
While in Common Lisp you have to insert explicit funcalls:
(let ((f (lambda (x) (+ x x)))
(g (lambda (x) (lambda (y) (+ x y)))))
(funcall f (funcall (funcall g 5) 6)))
(Of course, you can define f and g via flet and make this particular
example a little bit less cumbersome. But that's besides the point - in
larger examples _expressed in a certain functional programming style_
the situation occurs more often and obviously cannot be transformed that
easily.)
There are two different issues involved:
(1) How do you treat the first position of an sexpr when it is a symbol?
(say (f 5))
(2) How do you treat the first position of an sexpr when it is a cons?
(say ((g 5) 6))
(1) If you want to always treat symbols as variables, no matter where
they appear, and thus make functions bindable by let (instead of an
additional flet construct), you need Lisp-1 semantics.
(2) If you want to treat conses in the first position as expressions
that ultimately result in function objects that can be applied in turn,
you can just define the semantics like that. This is not directly
related to the Lisp-1 vs. Lisp-2 issue - it could even be defined like
that in Common Lisp (as Erann Gat has recently demonstrated here with a
compiler hack for MCL).
So why is not defined like that in Common Lisp? I guess that the
important point here is that it would be unnatural to treat conses as
expressions but symbols as something different at the same time when
they appear in first positions. (The "natural" interpretation of symbol
as an expression is to treat it just like a variable.) The rules for
changed Common Lisp semantics would be roughly as follows:
+ For the first positions do the following: Interpret them as
expressions except when they are symbols - then interpret them as
references to function cells.
+ For the other positions treat them always as expressions.
(I have left out the cases for special forms, macros and lambda forms.)
The Common Lisp designers obviously have decided to go for the somewhat
simpler rule for the first case: Treat the first position specially,
except when you can't - then just reject it. This effectively means that
Common Lisp only treats symbols in the first positions but not arbitrary
expressions.
So what is supposed to be so hard for you? (Well, not you specifically... ;)
- The language semantics of Common Lisp has more special cases than
Scheme, so you need to learn more. (But it could have been worse. ;)
- Code written in Common Lisp is harder to understand when written in a
certain functional programming style.
That's it.
As I said, this is a tentative conclusion.
And: I am currently working on a set of macros that allows you to have
the same level of aesthetics for that programming style in Common Lisp
as you can take for granted in Scheme. The important point is that they
will be embedded in the Lisp-2 semantics of Common Lisp, and don't need
to simulate an environment with Lisp-1 semantics. (That's why I think
that the Lisp-1 vs. Lisp-2 discussion is indeed a red herring.)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <··············@web.de>, Pascal Costanza <········@web.de> wrote:
> My current tentative conclusion is that the Lisp-1 vs. Lisp-2 discussion
> is a red herring.
Yes, I think that is certainly true.
> - The language semantics of Common Lisp has more special cases than
> Scheme, so you need to learn more. (But it could have been worse. ;)
Scheme has two cases: the first position is an expression, or the first
position is a special form (or macro). Common Lisp has three cases: the
first position is a symbol that names a function, the first position is a
symbol that names a special form (or macro), or the first position is a
lambda expression.
> - Code written in Common Lisp is harder to understand when written in a
> certain functional programming style.
It's not at all clear to me that:
((((f g) h) i) j)
is necessarily easier to understand than
(call (call (call (f g) h) i) j)
The CL version is longer and perhaps more complicated to write an
interpreter for, but it's not a slam-dunk that it's harder to understand.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> It's not at all clear to me that:
>
> ((((f g) h) i) j)
>
> is necessarily easier to understand than
>
> (call (call (call (f g) h) i) j)
>
> The CL version is longer and perhaps more complicated to write an
> interpreter for, but it's not a slam-dunk that it's harder to understand.
I want to add some commentary to two pieces of this--the "more
complicated interpreter" and "harder to understand" parts. I'll take
the second part first...
========================================
I think that it depends on what kind of background one is from.
English speakers are (in many cases) taught that parens (i.e., parentheses)
contain text that is optional and can be (more or less) safely ignored.
Mathemeticians are (re)taught that parentheses are quite important and are
used not for providing optional information, but that they occupy a certain
kind of operator power like nearly everything in math. In math, case, font,
etc. all convey meaningful information. The R that is the real number is
not the R that may be a set and is not the r that is an index variable in
a summation. f(x) means apply f to x while f x means f*x in some contexts
and f of x in other contexts. Every detail of notation has potentially
complicated rules to mathemeticians. So it's of little surprise that they
are willing to hang an important piece of functionality on a small nuance
of syntax.
In CL, we have ventured down a certain distance into the realm of attaching
semantics to characters, but we have largely stopped at the line of making
that syntax information imply "structural composition" and not "semantic
composition". There are, in fact, some places where we ventured across the
line on this. `, is one of them, and ~ notation in FORMAT is another.
However, as an informal design rule, we have gone cautiously. Semantic
distinctions are largely manifest in forms. So some of us have resisted the
idea that CALL should have the abbreviated notation ((f x) y) because we
feel it's not visually emphasizing the fact of the call. Furthermore,
the same people are not coincidentally willing to tolerate #'car as the
name for the function car in order to emphasize our sense that this is a
different kind of variable than car. I'm not trying to claim the design
rule is tightly applied, but I am trying to say that there is evidence that
the community was not ultra-gung-ho on the design principle of minimal syntax.
I think for a certain audience, FP is not everything, and case-marking a call
isn't bad.
My real point is that it's all what you're used to. Scheme, IMO, has gone
heavy on the mathy end, and tends to appeal to those with years of exposure
to math more than it appeals to those who haven't, IMO... [It'd be useful to
have actual stats on this to form better opinions, of course..]
Count me as someone who eschews math notation, though he understands why it
arose. And so that's why a move more toward the lambda calculus does nothing
to make me feel warmer. In light of recent news [1], I personally find it
ironic that Sussman and Steele feel that the more compact (and I think
cryptic) notation is a good idea.
[1] http://web.mit.edu/newsoffice/tt/2003/may21/ed-computer.html
reported also at Slashdot
http://science.slashdot.org/science/03/06/02/2034234.shtml?tid=146&tid=99
(Incidentally, there is a nice photo of Sussman and Abelson with the
MIT news url above.)
========================================
Now, on the issue of making interpreters more complicated, I think it's a
design error that Scheme didn't define CALL as a primitive special form and
((f x) ...) as a macro syntax for (CALL (f x) ...). This isn't an argument
based on Lisp1/Lisp2 issues [since it would still leave Scheme a Lisp1] but
is rather an issue based on the inner dispatch of the Scheme engine. In
other words, it seems to me that the unmarked function call should disappear
at macroexpansion time and that the expanded code should be more regular
to reduce interpreter complexity.
In other words, I think ALL special forms should be compound expressions
whose car is a special operator. And I think it makes Scheme more
complicated to do otherwise, this issue notwithstanding, since you already
have to do
(if (atom x)
(eval-variable x)
(if (member (car x) the-special-forms)
(eval-special x)
(eval-application x)))
and if my claimed rule were used, the inner rule [post macroexpansion]
would have been just
(ecase (car form)
((var) (eval-variable form))
((call) (eval-call form))
((if) ...)
...)
with nothing but non-atomic special forms.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Now, on the issue of making interpreters more complicated, I think it's a
> design error that Scheme didn't define CALL as a primitive special form and
> ((f x) ...) as a macro syntax for (CALL (f x) ...). This isn't an argument
> based on Lisp1/Lisp2 issues [since it would still leave Scheme a Lisp1] but
> is rather an issue based on the inner dispatch of the Scheme engine. In
> other words, it seems to me that the unmarked function call should disappear
> at macroexpansion time and that the expanded code should be more regular
> to reduce interpreter complexity.
>
> In other words, I think ALL special forms should be compound expressions
> whose car is a special operator. And I think it makes Scheme more
> complicated to do otherwise, this issue notwithstanding, since you already
> have to do
> (if (atom x)
> (eval-variable x)
> (if (member (car x) the-special-forms)
> (eval-special x)
> (eval-application x)))
> and if my claimed rule were used, the inner rule [post macroexpansion]
> would have been just
> (ecase (car form)
> ((var) (eval-variable form))
> ((call) (eval-call form))
> ((if) ...)
> ...)
> with nothing but non-atomic special forms.
Which of these methods really yields a simpler interpreter depends a bit
on how you count (and how you format your code).
In the Scheme case you arguably end up with five extra lines of code (or
three if you write it as a COND), but on the other hand, eval-special
becomes two lines shorter because it no longer has to handle VAR and
CALL. This might look like a (small) win for your method in terms of
complexity, but then you have to count the extra complexity (and consing)
of the separate macroexpansion pass that your method requires.
However, I think it's important to point out also that you get a big
architectural payoff from the extra complexity of building in a required
macroexpansion phase, because a macroexpander is really a (partial)
compiler. You've reduced the complexity of the interpreter at the expense
of increasing the complexity of the compiler. Keep pushing on this design
philosophy and you keep reducing the complexity of the interpreter at the
expense of much larger increases in the complexity of the
macroexpander/compiler, until you eventually reduce the complexity of the
interpreter to zero with a full native-code compiler. Most people
consider this a net win, despite the fact that few would consider it a
reduction in overall system complexity.
E.
In article <····················@k-137-79-50-101.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) wrote:
> In article <··············@web.de>, Pascal Costanza <········@web.de> wrote:
>
> > My current tentative conclusion is that the Lisp-1 vs. Lisp-2 discussion
> > is a red herring.
>
> Yes, I think that is certainly true.
>
> > - The language semantics of Common Lisp has more special cases than
> > Scheme, so you need to learn more. (But it could have been worse. ;)
>
> Scheme has two cases: the first position is an expression, or the first
> position is a special form (or macro). Common Lisp has three cases: the
> first position is a symbol that names a function, the first position is a
> symbol that names a special form (or macro), or the first position is a
> lambda expression.
That's certainly also my impression - Scheme is not as clean and minimal
as advertised.
The most minimal descendant of Lisp that I have come across is Pico: http://pico.vub.ac.be/
> > - Code written in Common Lisp is harder to understand when written in a
> > certain functional programming style.
>
> It's not at all clear to me that:
>
> ((((f g) h) i) j)
>
> is necessarily easier to understand than
>
> (call (call (call (f g) h) i) j)
>
> The CL version is longer and perhaps more complicated to write an
> interpreter for, but it's not a slam-dunk that it's harder to understand.
Your example isn't very concrete. The idea of Lisp is to adapt the
language to the needs of the problem domain - but your example doesn't
reflect any problem domain.
The example Joe has given recently is taken from some concrete domain,
and in that domain, the "functional" style is obviously aesthetically
more appealing. And I think that aesthetics and understandability can be
closely related.
Pascal
From: Joe Marshall
Subject: Re: For People who use Linguistic arguments here is a list
Date:
Message-ID: <r86b6qc8.fsf@ccs.neu.edu>
Pascal Costanza <········@web.de> writes:
> My current tentative conclusion is that the Lisp-1 vs. Lisp-2
> discussion is a red herring. It's just part of a possible technical
> solution for a totallly different issue.
I use both Scheme and Common Lisp professionally and that is the
conclusion that I have come to. There are some *consequences* that
follow from the choice of Lisp-1 vs. Lisp-2, but they are hardly
overwhelming. A Lisp-1 is more prone to variable name capture, thus
there is a greater need for assistance in writing correct macros.
(I'm deliberately avoiding the `H' word. You want to avoid variable
name capture in both Lisp-1 and Lisp-2. Since it is harder to do so
in Lisp-1, there is a more complex mechanism to automate it.) A
Lisp-2, on the other hand, requires namespace qualifiers at certain
times.
Can we debate the philosophy of Thomas Aquinas now?
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Can we debate the philosophy of Thomas Aquinas now?
Of course - do you like it or not? ;)
Pascal
From: Duane Rettig
Subject: Re: For People who use Linguistic arguments here is a list
Date:
Message-ID: <4isropi4w.fsf@beta.franz.com>
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> from my computation linguistics class about why it's a bad idea
> to use linguistic arguments for language issues:
Disagreed. See below.
> 1.) We polish the Polish furniture.
> 2.) He could lead if he would get the lead out.
> 3.) A farm can produce produce.
> 4.) The dump was so full it had to refuse refuse.
> 5.) The soldier decoded to desert in the desert.
> 6.) The resent is a good time to present the present.
==========^ "The present is a good time..."
> 7.) At the Army base, a bass was painted on the head of a bass drum.
> 8.) The dove dove into the bushes.
> 9.) I did not object to the object.
> 10.) The insurance for the invalid was invalid.
> 11.) The bandage was wound around the wound.
> 12.) There was a row among the oarsmen about how to row.
> 13.) The were too close to the door to close it.
> 14.) The buck does funny things when the does are present.
> 15.) They sent a sewer down to stitch the tear in the sewer line.
> 16.) To help with planting, the farmer taught his sow to sow.
> 17.) The wind was too strong to wind the sail.
> 18.) After a number of Novocain injections, my jaw got number.
> 19.) I shed a tear when I saw the tear in my clothes.
> 20.) I has to subject the subject to a series of tests.
> 21.) How can I intimate this to my most intimate friend?
> 22.) I spent last evening evening out a pile of dirt.
>
> Now let's see a lot of English words have multiple meanings. Let's not waste
> a lot of bandwidth arguing about what "free" or "lisp" mean and just accept
> that one word can mean many different things as my list has shown.
Agreed, trivially. However, what you've presented as an argument against
arguing about what "free" or "lisp" mean, is not really a good argument
at all, since it doesn't apply here; all of the words in these sentences
that are duplicated with multiple meanings form sentences each of which
have only one meaning. There is no ambiguity here, as there is when the
terms "free" or "lisp" are used without enough context.
What you _have_ argued very effectively for is the fact that Lisp-2 is so
much like natural language, and doesn't suffer for it...
> Try arguing that one word can only mean one thing with all the sentences on
> this list; if you are successful, pat your selves on the back--you have just
> made computation linguistics much much simpler. :-D
You'd be just as famous if you successfully argued that putting better
fuel in your automobile would make your airplane go faster.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Franz Kafka
Subject: Re: For People who use Linguistic arguments here is a list (The picky people here like 2 argue about words. :) )
Date:
Message-ID: <9MUCa.943$en7.764@news01.roc.ny.frontiernet.net>
"Duane Rettig" <·····@franz.com> wrote in message
··················@beta.franz.com...
> "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
writes:
>
>
> > Now let's see a lot of English words have multiple meanings. Let's not
waste
> > a lot of bandwidth arguing about what "free" or "lisp" mean and just
accept
> > that one word can mean many different things as my list has shown.
>
> Agreed, trivially. However, what you've presented as an argument against
> arguing about what "free" or "lisp" mean, is not really a good argument
> at all, since it doesn't apply here; all of the words in these sentences
> that are duplicated with multiple meanings form sentences each of which
> have only one meaning. There is no ambiguity here, as there is when the
> terms "free" or "lisp" are used without enough context.
>
> What you _have_ argued very effectively for is the fact that Lisp-2 is so
> much like natural language, and doesn't suffer for it...
>
> > Try arguing that one word can only mean one thing with all the sentences
on
> > this list; if you are successful, pat your selves on the back--you have
just
> > made computation linguistics much much simpler. :-D
>
> You'd be just as famous if you successfully argued that putting better
> fuel in your automobile would make your airplane go faster.
>
> --
> Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
> 555 12th St., Suite 1450 http://www.555citycenter.com/
> Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In that case:
1a.) We have free pizza. (Free implies it cost no $$$) better stated as: "We
have free slices of pizza., etc."
1b.) We have fat free pizza. (Free implies lack of fat--it still could cost
$$$)
1c.) We are free to eat the pizza when we want. (Free implies rights to eat
the pizza at any time--it still could cost $$$)
1d.) We have free slices of fat free pizza. (implies 1a & 1b)
2a.) The programmer uses Lisp. (In this thread usually means Common Lisp)
2b.) The programmer has a Lisp. (Lisp implies Speach Problems.)
2c.) Gifted students use a version of Lisp from Schemers.com at my school.
(Lisp implies language that processes Lists--not Common Lisp)
2d.) The programmer who uses Lisp has a Lisp. (implies both 2a & 2b)
3a.) There's a free version of ACL. (Free /w Limits.)
3b.) CLisp is a free Lisp. (Free unless you want to sell it.)
3c.) On a warez site you can get Visual Studio .Net or Windows 2000 Server
for free.
(this free implies theft and is illegal)
pick pick pick.
just read the license or ask the person for some context; don't complain
that "free" and
"lisp" have many meanings--that's why we say things like "Common Lisp",
"Interlisp",
"Zetalisp", "Franz Lisp", "Lisp Machine Lisp", "Scheme and Logo are Lisp
dialects."
so people understand what we mean when we say Lisp. (of course, we could be
talking
about a speach problem.) With free -- we say "Free Coffee is Here" "Give me
fat free
coffee" "Give me free software" "I want to be free to use my software"
Free applyed to money-item = it doesn't cost any money.
Free applyed to human-rights = right to automatity.
Free applyed to non-money-item = the item is removed from the product
But people can extend the meaning of free because English is a living
language, as long as:
1.) The write what the new definition is 2.) They use context to make it
clear which definiton
applys.
Note: Free as it applies 2 software is best expressed in it's licence--the
licence gives all the
context you need. If you don't like what it means you can choose an other
program, or
deal /w the licence.
From: Keith M. Corbett
Subject: Re: For People who use Linguistic arguments here is a list
Date:
Message-ID: <bbs5bd$e6k$1@pcls4.std.com>
"Duane Rettig" <·····@franz.com> wrote in message
··················@beta.franz.com...
> "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
writes:
> > Try arguing that one word can only mean one thing with all the sentences
on
> > this list; if you are successful, pat your selves on the back--you have
just
> > made computation linguistics much much simpler. :-D
>
> You'd be just as famous if you successfully argued that putting better
> fuel in your automobile would make your airplane go faster.
I am using my auto to tow my airplane. QED. :)
/kmc
From: Duane Rettig
Subject: Re: For People who use Linguistic arguments here is a list
Date:
Message-ID: <465nhgy76.fsf@beta.franz.com>
"Keith M. Corbett" <···@world.std.com> writes:
> "Duane Rettig" <·····@franz.com> wrote in message
> ··················@beta.franz.com...
> > "Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
> writes:
>
> > > Try arguing that one word can only mean one thing with all the sentences
> on
> > > this list; if you are successful, pat your selves on the back--you have
> just
> > > made computation linguistics much much simpler. :-D
> >
> > You'd be just as famous if you successfully argued that putting better
> > fuel in your automobile would make your airplane go faster.
>
> I am using my auto to tow my airplane. QED. :)
Not a successful argument. I don't know too many autos that can tow
an airplane faster than the airplane can fly. Besides, how do you keep
it on the ground if its going that fast?
:-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182