Hi everyone...
first of all i want to thank you all for your answers, i have make disappear the "." from my
procedure (our-reverse) and will check other thinks, but know i have a question, in one mail i'm told
why i don't use if instead of cond, this is basically because in the book i'm studing lisp at least till chapter
four they don't use it; is it that cond is know like deprecated or something ?? i mean because i think if you
have something like:
(cond (.....) (.....) ...
(......) (....)....
(.....).... .....)
that is better that something like:
(if (...) ...)
(if (......) .....)
.......
(I don't write the if's sintactically right because as i said i still have not use it :) )
We could use else's too (if there's else in lisp... i suppose there is)
But of course i think that if you have just one condition it's better write:
(if (....) ......)
that just put (cond (....) ....)....i mean it looks better the if but i suppose you get the same with any
them...... What do you think ????
Thanks.....
--
-------------------------------------------------------------------------------
| Rodolfo Conde Mtz Universidad Nacional Autonoma de Mexico |
| ICQ 14757500 Facultad de Ciencias |
| e-mails: Ciencias de la Computacion |
| ······@ada.fciencias.unam.mx |
| ············@usa.net |
-------------------------------------------------------------------------------
RCM <············@usa.net> writes:
> Hi everyone...
> first of all i want to thank you all for your answers, i have
> make disappear the "." from my procedure (our-reverse) and will
> check other thinks, but know i have a question, in one mail i'm told
> why i don't use if instead of cond, this is basically because in the
> book i'm studing lisp at least till chapter four they don't use it;
i really like paul grahams ansi common lisp. this book may be a good
supplement. it's modern, up-to-date and easy to read. it has no
cryptic zen koans (which are fun, but don't help you to learn).
i found lisp to be very weird (since i am very used to c, fortran,
assembly &c). i basically had to read the whole of grahams book, let
it sink in, and read it again. *then* i started to program in lisp.
i am still limping along. the standard language pathways in my brain
need a long time to be overridden (maybe this is what the zen koans
are supposed to help with).
so given that i am a newbie like yourself (i didn't do much lisp
before december), this may not be the authoritative word on the
subject.
> is it that cond is know like deprecated or something ?? i mean
> because i think if you have something like:
> (cond (.....) (.....) ...
> (......) (....)....
> (.....).... .....)
it's not that cond is depreciated per se. cond is still actively
used. but i would use when, unless, if and cond for things which you
have 1, 1, 2, and more options respectively.
if you have a simple if (only a then clause), use when
(when (it-is-time)
(do-some-thing))
(when (it-is-time)
(do-first-thing)
(do-another-thing))
when has an implicit progn, i.e., you can simply list all the stuff
you want to do.
use unless when you want to reverse the sense of condition (an if with
only an else part).
(unless (you-have-it-covered)
(cover-it))
(unless (x ... is the same as (if (not (x ....
unless also has an implicit progn.
for decisions with two options, i use if.
(if (decision)
(then-part)
(else-part))
notice that you can't just make a list of things or the then-part
would bleed over into the else.
(if (decision)
(progn ; the then part
(do-1)
(do-2))
(else-form))
you would need a progn for a list in the else form.
use cond when you would have a bunch of nested ifs.
(defun my-sign-1 (x)
(if (zerop x)
(princ "zero")
(if (> x 0)
(princ "positive")
(princ "negative"))))
(defun my-sign-2 (x)
(cond
((zerop x) (princ "zero"))
((> x 0) (princ "positive"))
(t (princ "negative"))))
here, i prefer the cond format, but sometimes the if can be good too
(if it doesn't get too deep).
to sum up, it's not that cond is bad. it's just wordy (or paren-happy
if you like) and therefore not very clear in the common simple cases.
when, if and unless are often (always?) macros and get made into cond
expressions for you.
(if x
(then-form)
(else-form))
gets made into
(cond
(x (then-form))
(t (else-form)))
by an expansion.
> that is better that something like:
> (if (...) ...)
> (if (......) .....)
> .......
> (I don't write the if's sintactically right because as i said
> i still have not use it :) ) We could use else's too (if
> there's else in lisp... i suppose there is) But of course i
> think that if you have just one condition it's better write:
> (if (....) ......)
> that just put (cond (....) ....)....i mean it looks better the
> if but i suppose you get the same with any them...... What do you
> think ????
it's all about looks.
i didn't mean to flame you about the if. i just think that lisp gives
a bad impression when you are exposed to cond first and do not see the
simpler when, unless and if formats.
similarly, some problems are nicely solved by recursion, but some you
will find easier to do using dolist or dotimes or perhaps loop.
forcing recursion down your throat when it doesn't fit isn't a good
way to sell lisp. (although i do understand that if you're familiar
with do loops, you may keep applying the dotimes hammer even in the
face of a screw.)
i think common lisp is a nice language. the 1970s vintage lisp
presented in a lot of classrooms leaves a bad impression and only
serves to make people think lisp is awkward, slow and useless. this
is not the case.
hope this helps.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
Johan Kullstam <········@ne.mediaone.net> writes:
let me correct a couple of details.
> (unless (x ... is the same as (if (not (x ....
i meant to say (unless (x is the same as (when (not (x....
also when and unless are nice in that you know that they only take one
clause.
these two work identically
(when x (then-form))
(if x (then-form))
however, in the first case you know immediately that there's no
else-form lurking about (easy to see here, but you can immagine if the
then-form is complicated...).
this removes the need for checking indentation, hoping indentation is
right and resorting to counting parentheses just to see if the `if'
has an else-part or not.
therefore, as a matter of style, i use `when' whenever possible and
`if' when i need both `then' and `else' clauses.
--
johan kullstam
This is a multi-part message in MIME format.
--------------669A685400BCAE5AAE06E824
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Johan Kullstam wrote:
> (when x (then-form))
>
> (if x (then-form))
>
BTW, if strongly recommend (Open Source) people explicitly writing
cl:if, cl:when, cl:unless. etc. for portability to Scheme. In some cases
you need not do
so, for example:
(if (listp x) ...)
as (define listp list?) will get this right.
--------------669A685400BCAE5AAE06E824
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fernando Mato Mira
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Fernando Mato Mira
n: Mato Mira;Fernando
email;internet: ········@iname.com
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------669A685400BCAE5AAE06E824--
* "Fernando D. Mato Mira" <········@iname.com>
| BTW, if strongly recommend (Open Source) people explicitly writing
| cl:if, cl:when, cl:unless. etc. for portability to Scheme.
*laugh* even I don't think Scheme is _that_ braindamaged a language.
#:Erik
Erik Naggum wrote:
> * "Fernando D. Mato Mira" <········@iname.com>
> | BTW, if strongly recommend (Open Source) people explicitly writing
> | cl:if, cl:when, cl:unless. etc. for portability to Scheme.
>
> *laugh* even I don't think Scheme is _that_ braindamaged a language.
Someone sent me email questioning the practical utility of such guideline,
as in his opinion only trivial programs would be portable anyway.
Given that other people might think the same, I'm posting my answer below:
>When I had to move from ILOG Talk (which has quite a few
>CommonLispy things) to MzScheme, I ripped of a couple dozen
>files from CMUCL, implementing notably things like DEFMACRO
>and SETF, and practically all (if not all indeed) the modifications (not
many)
>I had to make in those sources consisted in replacing things like IF by
CL:IF in
>the places where you can get a NIL in the `empty list' sense.
>
>I also tweaked the MzScheme reader so that it would just skip #',
>and not only loaded tiny-clos, but also implemented some native
>support for it, so that it would run faster and reified the whole MzScheme
>type system, integrating even their own object system (which of course
>I don't use) thanks to a new metaclass. I think it was pretty cool
>but mflatt did not integrate the CLOS-oriented changes.
>
>If you want the big CLOS, I think it can be pretty much done. Some things
>will break w/o CL packages, but you could implement those (unless your
Scheme
>implementation is closed). You want the STREAM package? Well, I guess that
>won't be evident, but you can start by implementing MACROLET.
>
>I only see 2 fundamental problems (please tell me if I'm wrong):
>1. The #f, (), NIL issue
>2. The `function name' issue
>
>Appropriate discipline take care of 1), so you can load
>both Scheme and CL oriented code.
>I don't think one gets bitten very often by 2). I'd be interested
>to know about the hard cases (nothing comes to my mind right now,
>but that doesn't mean they do not exist).
I even go a bit further, writing the safe conditionals as boolean-if, etc.
(maybe `bif', `bunless', `bwhen' would be better), so that if the
implementation
allows, I can redefine `if' to be the CL style one, w/o affecting the
semantics
of Scheme code as well as losing in efficiency.
Oh yes. And w/o #+, #-supported by your Scheme implementation, forget it.
I also had to add that (to Gambit too). Which reminds me that Matt Flatt
oposed
with reason to *features*, suggesting the thing be based on a `parameter'
instead.
So I guess that writing *features* directly in your program is equally bad.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira acm "You know the rest"
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Erik Naggum <····@naggum.no> writes:
> * "Fernando D. Mato Mira" <········@iname.com>
> | BTW, if strongly recommend (Open Source) people explicitly writing
> | cl:if, cl:when, cl:unless. etc. for portability to Scheme.
>
> *laugh* even I don't think Scheme is _that_ braindamaged a language.
moreover, it would take about 5 minutes to switch "(if" to "(cl:if" in
the event such a port took place. typing many extra characters and
perturbing all of one's code to indent 3 characters more to the right
just in case of porting seems a little extreme.
as a rule, i think an explicit package reference to a package you are
programming *in* is almost always a style-o. IMO, explicit package
references should be made only to others' packages that you haven't
imported or else to an interface you are bootstrapping/implementing
but not yet using as a form of emphasis. i could elaborate on my
reasons for this, but i'm a little pressed for time. perhaps another
time.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
(...)
> as a rule, i think an explicit package reference to a package you are
> programming *in* is almost always a style-o. IMO, explicit package
> references should be made only to others' packages that you haven't
> imported or else to an interface you are bootstrapping/implementing
> but not yet using as a form of emphasis.
(...)
To me, if the current package uses the COMMON-LISP package, CL:IF would
indicate that IF has been shadowed by the current package, and the time
has come to use the original IF. (Of course, this might be more likely
to happen with other symbols from COMMON-LISP than IF.)
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Kent M Pitman
Subject: Re: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <sfwsob9acid.fsf@world.std.com>
Vassil Nikolov <········@poboxes.com> writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
> (...)
> > as a rule, i think an explicit package reference to a package you are
> > programming *in* is almost always a style-o. IMO, explicit package
> > references should be made only to others' packages that you haven't
> > imported or else to an interface you are bootstrapping/implementing
> > but not yet using as a form of emphasis.
> (...)
>
> To me, if the current package uses the COMMON-LISP package, CL:IF would
> indicate that IF has been shadowed by the current package, and the time
> has come to use the original IF. (Of course, this might be more likely
> to happen with other symbols from COMMON-LISP than IF.)
This restates what I just said. If a symbol is shadowed, it isn't
imported. What I was getting at was that if the recommendation is to
use cl:if when if would suffice, I think it's not the right way to go.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> Vassil Nikolov <········@poboxes.com> writes:
>
> > In article <···············@world.std.com>,
> > Kent M Pitman <······@world.std.com> wrote:
> > (...)
> > > as a rule, i think an explicit package reference to a package you are
> > > programming *in* is almost always a style-o. IMO, explicit package
> > > references should be made only to others' packages that you haven't
> > > imported or else to an interface you are bootstrapping/implementing
> > > but not yet using as a form of emphasis.
> > (...)
> >
> > To me, if the current package uses the COMMON-LISP package, CL:IF would
> > indicate that IF has been shadowed by the current package, and the time
> > has come to use the original IF. (Of course, this might be more likely
> > to happen with other symbols from COMMON-LISP than IF.)
>
> This restates what I just said. If a symbol is shadowed, it isn't
> imported. What I was getting at was that if the recommendation is to
> use cl:if when if would suffice, I think it's not the right way to go.
Sorry for missing your point. (I read `packages that you haven't imported'
as `packages that you don't use.')
Anyway, I was not objecting but adding another case which seemed to me to
be left unmentioned.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
From: Fernando D. Mato Mira
Subject: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <36ECC7B7.8F846480@iname.com>
Kent M Pitman wrote:
> This restates what I just said. If a symbol is shadowed, it isn't
> imported. What I was getting at was that if the recommendation is to
> use cl:if when if would suffice, I think it's not the right way to go.
Of course it __SUCKS__ writing CL:IF. The right way to go would
be for Scheme to forget about that #f =/= NIL silliness, and start
doing things the real lisp way.
It's not just CL:IF et al. but also CL:DO.
And CL:CAR, CL:CDR, CL:CADR etc. when
you might be accessing NIL.
Maybe the real issue here is that, in general, both communities
just go their own way and they don't care about each other.
Maybe it's time to specify a `Core Lisp' that contains only the barebones
to implement both Scheme and CL (the F#, Lisp-1, continuation issue is
left unspecified to you can choose which way to go).
Perhaps that way we would start seeing new CL compilers, instead of just
one Scheme variant after the other. CL is perceived as `too big', but in
fact, you can just take all the high-level stuff from CMUCL (BTW, factorizing
CMUCL so that such a thing becomes pretty plug-and-play would be a good too).
And in an ideal world, CL vendors would just maintain the common CMUCL
library
(calling functions like %DONT-USE-THIS-IT-MIGHT-GO-AWAY would be OK),
to avoid duplication of effort so they have more time/money to spend on their
proprietary compilers. If a certain CL can just use the open implementation
for
something, instead of having to provide another primitive for performance,
that
means the compiler should be also better at your own code
(no benchmark-style tricks, please).
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
On Mon, 15 Mar 1999 09:41:27 +0100, "Fernando D. Mato Mira"
<········@iname.com> wrote:
>
>
>Kent M Pitman wrote:
>
>> This restates what I just said. If a symbol is shadowed, it isn't
>> imported. What I was getting at was that if the recommendation is to
>> use cl:if when if would suffice, I think it's not the right way to go.
>
> Of course it __SUCKS__ writing CL:IF. The right way to go would
>be for Scheme to forget about that #f =/= NIL silliness, and start
>doing things the real lisp way.
>
>It's not just CL:IF et al. but also CL:DO.
>And CL:CAR, CL:CDR, CL:CADR etc. when
>you might be accessing NIL.
>
>Maybe the real issue here is that, in general, both communities
>just go their own way and they don't care about each other.
>
>Maybe it's time to specify a `Core Lisp' that contains only the barebones
>to implement both Scheme and CL (the F#, Lisp-1, continuation issue is
>left unspecified to you can choose which way to go).
>Perhaps that way we would start seeing new CL compilers, instead of just
>one Scheme variant after the other. CL is perceived as `too big', but in
>fact, you can just take all the high-level stuff from CMUCL (BTW, factorizing
>
>CMUCL so that such a thing becomes pretty plug-and-play would be a good too).
>
>And in an ideal world, CL vendors would just maintain the common CMUCL
>library
>(calling functions like %DONT-USE-THIS-IT-MIGHT-GO-AWAY would be OK),
>to avoid duplication of effort so they have more time/money to spend on their
>
>proprietary compilers. If a certain CL can just use the open implementation
>for
>something, instead of having to provide another primitive for performance,
>that
>means the compiler should be also better at your own code
>(no benchmark-style tricks, please).
>
As Dick Gabriel pointed out years ago (for details see
(http://www.ai.mit.edu/docs/articles//good-news/good-news.html), what
is really needed is for the LISP community to reconsider how they use
the language in the first place. There is too much of an attitude in
the LISP community (and the Smalltalk and ML communities as well) that
they have to stand apart from the rest of the world. In a universe
that is divided between two hostile empires (Windoze and Eunux) which
want nothing out of you, this can be a deadly mistake.
When will I be able to write an NT DLL (ugh) in Scheme? When will a
Haskell program be free to use the clipboard (double ugh)? When will I
be able to use Smalltalk to write an X based mail reader? When will I
be able to cleanly mix-n-match code from code in CLOS, C++ and CAML in
one app? Not today, that's for sure.
True, most compilers and environments have some capacity for importing
libraries, but this is far too limited. We need to have tools that can
be treated the same as others, that are as integrated with the
platform they run on as possible. One of the reasons that these
languages are seen as inefficient is because they try to exist so much
in a vaccuum; even though it is possible to write optimizing LISP
compilers that far exceed any for C++, C++ runs better on, say, Linux,
because it fits the system better. The only real innovation in Java is
that it is an interpreted language that still behaves (for the most
part) like a native one, while even compiled LISP usually needs
additional support that makes such transparency impossible.
There is a world outside of the top-level eval prompt. Perhaps we
ought to join it.
From: Kelly Murray
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <36EDA351.3AA7D58A@IntelliMarket.Com>
Schol-R-LEA wrote:
> As Dick Gabriel pointed out years ago (for details see
> (http://www.ai.mit.edu/docs/articles//good-news/good-news.html), what
> is really needed is for the LISP community to reconsider how they use
> the language in the first place. There is too much of an attitude in
> the LISP community (and the Smalltalk and ML communities as well) that
> they have to stand apart from the rest of the world. In a universe
> that is divided between two hostile empires (Windoze and Eunux) which
> want nothing out of you, this can be a deadly mistake.
>
> When will I be able to write an NT DLL (ugh) in Scheme? When will a
> Haskell program be free to use the clipboard (double ugh)? When will I
> be able to use Smalltalk to write an X based mail reader? When will I
> be able to cleanly mix-n-match code from code in CLOS, C++ and CAML in
> one app? Not today, that's for sure.
And not tomorrow either. A reasonable man adapts to his environment.
So use the language best supported by the environment (C/C++/VB/Java)
An unreasonable man tries to change his environment.
Therefore only unreasonable men will produce changes.
In my view, that change is to have another operating system where
reasonable men can use Lisp.
>
> True, most compilers and environments have some capacity for importing
> libraries, but this is far too limited. We need to have tools that can
> be treated the same as others, that are as integrated with the
> platform they run on as possible. One of the reasons that these
> languages are seen as inefficient is because they try to exist so much
> in a vaccuum; even though it is possible to write optimizing LISP
> compilers that far exceed any for C++, C++ runs better on, say, Linux,
> because it fits the system better. The only real innovation in Java is
> that it is an interpreted language that still behaves (for the most
> part) like a native one, while even compiled LISP usually needs
> additional support that makes such transparency impossible.
>
> There is a world outside of the top-level eval prompt. Perhaps we
> ought to join it.
>
Or compete against it. If Lisp is as great as we all seem to think
it is, then we can win, at least on the web, because nobody knows
nor cares if your running Lisp or not.
If its not that great and/or we have already "lost", then perhaps we
should face up to it, and adapt to the other languages.
Java ain't that bad.
On topic, a Core Lisp doesn't address the real needs in my view,
which is to generate better applications faster and get more
people writing those applications.
Even a $300 palmtop computer has 8mb today. What great advantage
is there in fitting a lisp implementation in 1mb?
The big issue is getting more people to program in Lisp,
and that means making it easier for them to learn and use Lisp,
and to give them some advantage for doing so.
-Kelly Murray ···@niclos.com
From: Erik Naggum
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <3131092057449863@naggum.no>
* Kelly Murray <···@IntelliMarket.Com>
| The big issue is getting more people to program in Lisp, and that means
| making it easier for them to learn and use Lisp, and to give them some
| advantage for doing so.
no, it doesn't. Lisp is already easy to learn, and anyone who learns it
and uses it derives great advantages from doing so. the issue is how to
make people aware of this. the way to do that is manifestly _not_ to
give in to the people who use something else today and pretend it's like
it. such moves try to take the results of one heritage and graft them
onto another. that's not how grafting works. at best, you'll completely
cannibalize Lisp and some other language will get all its features, and
_Lisp_ no longer has the advantages.
what you're proposing, Kelly, is like going into prostitution because sex
is good and you want to get laid more often. while the goal is reached,
it has obvious drawbacks and costs. I'm rather curious why you don't see
the costs of your own proposals.
(comp.lang.scheme excised.)
#:Erik
From: David B. Lamkins
Subject: More Whining Trolls (was Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....))
Date:
Message-ID: <C4lH2.5244$A6.3182371@news1.teleport.com>
In article <·················@news.slip.net> , ·@s.net (Schol-R-LEA) wrote:
(Note: follow-ups trimmed to c.l.l. I don't know why you think you have to
bother the Schemers, too.)
[snip]
> As Dick Gabriel pointed out years ago (for details see
> (http://www.ai.mit.edu/docs/articles//good-news/good-news.html), what
> is really needed is for the LISP community to reconsider how they use
> the language in the first place. There is too much of an attitude in
> the LISP community (and the Smalltalk and ML communities as well) that
> they have to stand apart from the rest of the world. In a universe
> that is divided between two hostile empires (Windoze and Eunux) which
> want nothing out of you, this can be a deadly mistake.
>
Eh? I'm familiar with the "Worse is Better" paper, have read it more than
once, and never _ever_ came away with the impression that this was even a
secondary point of the paper. The closest thing I can find is where Gabriel
wrote (about Lisp _implementations_, not users):
<quote>
Integration is God
In the worse-is-better world, integration is linking your .o files together,
freely intercalling functions, and using the same basic data
representations. You don't have a foreign loader, you don't coerce types
across function-call boundaries, you don't make one language dominant, and
you don't make the woes of your implementation technology impact the entire
system.
The very best Lisp foreign functionality is simply a joke when faced with
the above reality. Every item on the list can be addressed in a Lisp
implementation. This is just not the way Lisp implementations have been done
in the right thing world.
The virus lives while the complex organism is stillborn. Lisp must adapt,
not the other way around. The right thing and 2 shillings will get you a cup
of tea.
</quote>
If you want to use something else, please do so. Lisp is an excellent tool
for solving certain kinds of problems. If the tool doesn't match your
problem, choose one that does.
> When will I be able to write an NT DLL (ugh) in Scheme? When will a
> Haskell program be free to use the clipboard (double ugh)? When will I
> be able to use Smalltalk to write an X based mail reader? When will I
> be able to cleanly mix-n-match code from code in CLOS, C++ and CAML in
> one app? Not today, that's for sure.
>
Grumble. My, how time flies when I'm reading news... It's hard to believe
that it has been twenty-one months since we last beat this dead horse.
(Actually, there _have_ been a few minor transgressions since then.)
Anyway, the grandmother of all threads on this particular subject is still
available for your reading pleasure. Please take advantage of it:
<http://www.dejanews.com/[ST_rn=ps]/dnquery.xp?search=thread&recnum=%3cMPG.e
····················@news.demon.co.uk%3e%231/1&svcclass=dnserver>
> True, most compilers and environments have some capacity for importing
> libraries, but this is far too limited. We need to have tools that can
> be treated the same as others, that are as integrated with the
> platform they run on as possible.
Nice marketing statement. Now all you need is a business plan.
As Erik pointed out in several postings to the recent "Barriers to Lisp
Acceptance" thread, you can influence the behavior of your Lisp vendor by
committing your own resources (time and money) to get the things you really
want. Or you can take whatever you get for "free", go wherever that
particular ride takes you (where _did_ you want to go today? :\ ), and whine
about the destination.
> One of the reasons that these
> languages are seen as inefficient is because they try to exist so much
> in a vaccuum; even though it is possible to write optimizing LISP
> compilers that far exceed any for C++, C++ runs better on, say, Linux,
> because it fits the system better. The only real innovation in Java is
> that it is an interpreted language that still behaves (for the most
> part) like a native one, while even compiled LISP usually needs
> additional support that makes such transparency impossible.
Please, get your facts straight.
>
> There is a world outside of the top-level eval prompt. Perhaps we
> ought to join it.
Some of us already have.
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
((lambda (x) (list x (list 'quote x)))
'(lambda (x) (list x (list 'quote x))))
From: Martin Rodgers
Subject: Re: More Whining Trolls (was Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....))
Date:
Message-ID: <MPG.1158359b772abdca989e52@news.demon.co.uk>
In article <·····················@news1.teleport.com>,
········@teleport.com says...
> Grumble. My, how time flies when I'm reading news... It's hard to believe
> that it has been twenty-one months since we last beat this dead horse.
Twenty-one months later, I'm still looking for someone to pay me to use
Lisp. Or anything. This isn't whining, as I got used to people giving me
odd looks years ago, and I know there are worse things. There are even
worse things than long term umemployment. 10 years ago I was happily
living on welfare and writing Lisp code. I was _ecstatic_.
I also got used to flames, as people have been telling for years that I
can't be doing this stuff. The second line of my sigfile is flamebait, if
you've never used Lisp. I've wasted too many years trying to communicate
with closed minds, or searching for open minds with a job to offer.
This isn't meant to be a troll, just a small point. It sound like the
ultimate whine, and I won't be suprised if it does. It can get a little
lonely out here in the wilderness. It helps to find a newsgroup like
this, full of people who understand Lisp. I can't describe how wonderful
it was to discover this oasis in the desert, back in 1992. I found that I
wasn't not as mad as most people think. After all, they think the same
thing about _anyone_ who uses Lisp.
So, now I don't care anymore. After more than 15 years, I've given up
trying to be a professional programmer. I'll accept being an unemployed
Lisp programmer, as it beats the hell out of the alternatives. No amount
of money can compensate for that kind of agony. Instead, I'll write the
code I know how to write, and take all the ecstasy I can handle.
No more compromises.
--
Remove insect from address to email me | You can never browse enough
will write code that writes code that writes code for food
http://www.wildcard.demon.co.uk/dev/meta.html
From: Steven Perryman
Subject: Re: More Whining Trolls (was Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....))
Date:
Message-ID: <7d5qap$q4k$1@crchh14.us.nortel.com>
In article <··························@news.demon.co.uk>,
Martin Rodgers <···@wildcard.butterfly.demon.co.uk> wrote:
>In article <·····················@news1.teleport.com>,
>········@teleport.com says...
>> Grumble. My, how time flies when I'm reading news... It's hard to believe
>> that it has been twenty-one months since we last beat this dead horse.
>Twenty-one months later, I'm still looking for someone to pay me to use
>Lisp. Or anything. This isn't whining, as I got used to people giving me
>odd looks years ago, and I know there are worse things. There are even
>worse things than long term umemployment. 10 years ago I was happily
>living on welfare and writing Lisp code. I was _ecstatic_.
>I also got used to flames, as people have been telling for years that I
>can't be doing this stuff. The second line of my sigfile is flamebait, if
>you've never used Lisp. I've wasted too many years trying to communicate
>with closed minds, or searching for open minds with a job to offer.
>[...]
>So, now I don't care anymore. After more than 15 years, I've given up
>trying to be a professional programmer. I'll accept being an unemployed
>Lisp programmer, as it beats the hell out of the alternatives. No amount
>of money can compensate for that kind of agony. Instead, I'll write the
>code I know how to write, and take all the ecstasy I can handle.
I think the moral is not to get too "attached" to a particular prog lang.
Or method. Doing CLOS under LispWorks 9 years ago (and never since :-( ) was
much more fun than the x years of C++ I've had, but IMHO the fun comes from
being involved in building systems. Use of nice prog langs, methods, IDEs etc
are more often than not bonuses (sometimes more productive bonuses of
course) .
Which makes me laugh a lot when people get on the zealotry trip on their
one and only prog lang. Of the 6 OOPLs I've used in industry, I've tried to
harness their strengths when using them, but also be aware of their
weaknesses. I have a much more balanced, rational and honest view of them all
now.
If miraculously a CLOS job was offered to me, I'd be all ears.
But if it was for a boring accounting system etc, I'd say no, CLOS or not.
Regards,
Steven Perryman
·······@nortel.co.uk
Steven Perryman wrote:
> I think the moral is not to get too "attached" to a particular prog lang.
> [...]
>
> If miraculously a CLOS job was offered to me, I'd be all ears.
> But if it was for a boring accounting system etc, I'd say no, CLOS or not.
That's funny. For me, it's exactly the other way round.
I'd rather write a 'boring accounting system' in Common Lisp than
a <name something exciting> in <name almost any other programming
language>.
Transport may be the right analogy here.
Programming in Common Lisp makes me feel like I'm driving a beautiful
and elegant sportscar. The car is so nice that I don't really
care anymore where we're heading; the fun is in the trip itself.
Writing programs in (say) C++ makes me feel more like a pilgrim
from the Middle Ages who has vowed to go to Santiago de Compostela
on his knees; the destination may be beautiful, but the going is too
painful and the goal is too far away to soothe the pain.
Arthur Lemmens
From: Bernhard Pfahringer
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <7clcam$3co6$1@www.univie.ac.at>
In article <·················@news.slip.net>, Schol-R-LEA <·@s.net> wrote:
>
>When will I be able to write an NT DLL (ugh) in Scheme? When will a
If Common Lisp is ok, the answer is RIGHT NOW. From
http://www.harlequin.co.uk/products/ads/lisp/faq0.htm#S1Q17
Q. Does LWW support DLLs?
A. Yes. LWW can now generate standalone DLLs, as well as loading and executing
DLLs via the FLI.
This Harlequin's Lispworks for Windows.
cheers, Bernhard
PS: Should also answer your Q about mixing C++ and CLOS, eh?
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
From: Fernando D. Mato Mira
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <36EE54A5.5A846ABC@iname.com>
Bernhard Pfahringer wrote:
> PS: Should also answer your Q about mixing C++ and CLOS, eh?
I assume the typing problems that made me abandon Lispworks 4 years ago
have long since been fixed. What about templates?
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Erik Naggum
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <3131092328807306@naggum.no>
* ·@s.net (Schol-R-LEA)
| There is a world outside of the top-level eval prompt. Perhaps we ought
| to join it.
perhaps you need to understand that looking out from under your own rock
at a real world you haven't joined doesn't mean others live under rocks.
#:Erik
"Fernando D. Mato Mira" <········@iname.com> writes:
> Maybe the real issue here is that, in general, both communities
> just go their own way and they don't care about each other.
>
Maybe the real issue is that Scheme and Common Lisp are really two
*different* languages and that is is not useful to try to force them
to be the same? If you take a subset of the names on the R^nRS and on
the ANSI CL spec you will find a lot of overlap. The specifiers of
both languages were generally quite aware of the choices of the
other. But when you start with different goals, it's fairly logical
that you end up with different languages.
> Maybe it's time to specify a `Core Lisp' that contains only the barebones
> to implement both Scheme and CL (the F#, Lisp-1, continuation issue is
> left unspecified to you can choose which way to go).
Been there, done that. It sucks. Look at the subset they wrote the
computer algebra system REDUCE in. (Portable Lisp or something like
that? You can still get it commercially I believe.) You end up
building a new set of higher level abstractions based on your 'Core
Lisp' that everybody who wants to work with your stuff has to learn
and since it's implemented without using much of the available
facilities in your base languages compilers have a very hard time to
do optimisations.
--
Lieven Marchand
···@bewoner.dma.be
From: Kent M Pitman
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <sfwaexcez0m.fsf@world.std.com>
"Howard R. Stearns" <······@elwood.com> writes:
> I have (not recently) been daydreaming about the possibility of a CL
> implementation that could run Scheme. There would be a :scheme package
> which did all the right things.
You should check out Jonathan Rees's pseudoscheme. It runs in CL and
works just fine.
From: His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <w4osob4q6hn.fsf@nemesis.irtnog.org>
>>>>> "HRS" == Howard R Stearns <······@elwood.com> writes:
HRS> I have (not recently) been daydreaming about the possibility
HRS> of a CL implementation that could run Scheme. There would be
HRS> a :scheme package which did all the right things.
[snip]
HRS> Any comments? Big holes (other than typically having to add
HRS> declarations in Scheme code to do anything useful)? Would
HRS> this really be of value to anyone?
I'd have use for such a package. It'd be nice if Scheme and Lisp code
could co-exist, especially in the GNU world. I myself am a pretty
hard-core CL fanatic, but most others working on GNU stuff gravitate
towards Scheme (er, GUILE), and I can see people wanting to mix code
in a non-painful fashion.
--
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
Pope, Patron Saint of All Things Plastic fnord, and Salted Litter of r.g.s.b
In a lecture, Werner von Braun once said "Ve haf alvays been aiming for zer
stars" and a little voice at the back replied "But ve keep hittink London".
From: Kent M Pitman
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <sfwvhfx5wvi.fsf@world.std.com>
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" <········@irtnog.org> writes:
> >>>>> "HRS" == Howard R Stearns <······@elwood.com> writes:
>
> HRS> I have (not recently) been daydreaming about the possibility
> HRS> of a CL implementation that could run Scheme. There would be
> HRS> a :scheme package which did all the right things.
> [snip]
> HRS> Any comments? Big holes (other than typically having to add
> HRS> declarations in Scheme code to do anything useful)? Would
> HRS> this really be of value to anyone?
>
> I'd have use for such a package. It'd be nice if Scheme and Lisp code
> could co-exist, especially in the GNU world. I myself am a pretty
> hard-core CL fanatic, but most others working on GNU stuff gravitate
> towards Scheme (er, GUILE), and I can see people wanting to mix code
> in a non-painful fashion.
PseudoScheme (Scheme in CL):
ftp://ftp-swiss.ai.mit.edu/pub/pseudo/
From: Jussi Piitulainen
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <qotbthusx4j.fsf@tuuri.ling.helsinki.fi>
"Fernando D. Mato Mira" <········@iname.com> writes:
> The right way to go would be for Scheme to forget about that #f =/=
> NIL silliness, and start doing things the real lisp way.
Would it suffice if the name of Scheme were changed so that you would
not confuse it with Common Lisp? I don't have any better name in mind.
> Maybe the real issue here is that, in general, both communities just
> go their own way and they don't care about each other.
This is unlikely to change as long as you crosspost messages declaring
that one of the two languages is wrong and must start doing things the
other way. (I prefer to follow up in that other group only.)
You are free to design and document and implement and sell your new
massively underspecified core language that does not commit itself in
anything that either of the two present communities does not buy. And
why not generalize further, to include other interesting languages?
Good luck.
--
Jussi
From: Fernando D. Mato Mira
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <36EE18C8.1E687CB5@iname.com>
Jussi Piitulainen wrote:
> "Fernando D. Mato Mira" <········@iname.com> writes:
>
> > The right way to go would be for Scheme to forget about that #f =/=
> > NIL silliness, and start doing things the real lisp way.
>
> Would it suffice if the name of Scheme were changed so that you would
> not confuse it with Common Lisp? I don't have any better name in mind.
>
> > Maybe the real issue here is that, in general, both communities just
> > go their own way and they don't care about each other.
>
> This is unlikely to change as long as you crosspost messages declaring
> that one of the two languages is wrong and must start doing things the
> other way. (I prefer to follow up in that other group only.)
Don't get me wrong. GJS and GLS are two of my heros. I love Scheme
but there are good things in CL too (the most important being probably
the availability of interesting nontrivial software for it), otherwise, I
would
not care.
Scheme took the `single namespace way'. That breaks CL code but I don't
care.
It doesn't happen too often, and I don't mind occasional fix, because
Scheme is right
here, and, above all, Scheme is supposed to be _clean_.
The #f,NIL thing is probably the most religious Lisp issue ever. It just
broke
with lisp tradition, a certain style. How would you like a lisp that
replaces
'(" with "["? Doesn't seem very important. You can automatically translate
that,
and you could even keep a repository in `norma form'. But it's just a
pain. And
does not fix anything.
What does #f fix? I don't think traditional lisp is wrong. It is
consistent with lambda calculus,
i.e., `null is a subtype of all types'. So NIL is a boolean, different
from #t. But there are 2 boolean
values, so NIL == #f (alternatively, NIL could be #t and everything else,
false).
In the same sense that lisp syntax generates a nice and simple coding
style (which everyone here likes),
NIL == #f, (CAR NIL) == NIL, (CDR NIL) == NIL also do. Following the
above, NIL
is a strange thing, and its little peculiarities make it interesting and
probably useful.
> You are free to design and document and implement and sell your new
> massively underspecified core language that does not commit itself in
> anything that either of the two present communities does not buy. And
> why not generalize further, to include other interesting languages?
The `underspecified' language is a template that you can instantiate
L<falsity,names,continuations>
L<NIL=/=#t, 1, #t> -> Scheme
L<NIL=#t, 2, #f> -> CL
L<NIL=#t, 2, #t> -> CL with continuations
L<NIL=#t, 1, #f> -> `forward friendly CL' (not needed, just don't write
code assuming `2')
But I think future standards should be based on
L<NIL=#t, 1, x>
Scheme gives up on #f. CL gives up on the `f property'.
It is not supposed to be practical to program in. `user-level' forms
take care of that. Of course, nothing prevents a language implementor
to optimize the compiler by adding a CLOS kernel to it, or whatever
else he sees fit (futures, OCCAM-style channels, etc.).
As an example, the template would definitely not specify DO (Scheme's
and CL's are incompatible) but TAGBODY.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
...
Or just use a single construct
(if {condition}
then {then-form}*
[ elseif {condition} {then-form}* ]*
[ else {else-form}* ]
)
i.e.
(if test
then (print "the test was true")
elseif (not test)
then (print "the test was false")
else (print "the test was using fuzzy logic")
(sqrt -3) ;; return sqrt of -3
)
and most programmers would understand how it works...
;)
-kelly
>>>>> "Kelly" == Kelly Murray <···@IntelliMarket.Com> writes:
Kelly> ...
Kelly> Or just use a single construct
Kelly> (if {condition}
Kelly> then {then-form}*
Kelly> [ elseif {condition} {then-form}* ]*
Kelly> [ else {else-form}* ]
Kelly> )
Kelly> i.e.
Kelly> (if test
Kelly> then (print "the test was true")
Kelly> elseif (not test)
Kelly> then (print "the test was false")
Kelly> else (print "the test was using fuzzy logic")
Kelly> (sqrt -3) ;; return sqrt of -3
Kelly> )
Kelly> and most programmers would understand how it works...
Kelly> ;)
While I understand what Kelly is trying to do, this reminds of the
days when (Turbo) Pascal was the "in" language and C was the new kid
on the block. I've seen code for C like
#define BEGIN {
#define END }
and so on. Those familiar with C couldn't read it because it broke
their expectations, and those familiar with Pascal couldn't read it
either because it wasn't really Pascal.
If you're going to learn a language, *learn* the language![1][2]
Ray
Footnotes:
[1] With apologies to the funny Hardy's "Go all out" commercials,
which aren't being made anymore.
[2] If you're learning or using Kelly's NiCLOS (?), then, of course,
this is the right way to do it.
In article <·················@elwood.com>,
Howard R. Stearns <······@elwood.com> wrote:
>I have (not recently) been daydreaming about the possibility of a CL
>implementation that could run Scheme. There would be a :scheme package
>which did all the right things. In addition: [...]
>
>Any comments? Big holes (other than typically having to add
>declarations in Scheme code to do anything useful)? Would this really
>be of value to anyone?
Jonathan Rees's Pseudoscheme
(www-swiss.ai.mit.edu/ftpdir/pseudo) does something in
this vein. I think it implements everything but
"upward" continuations, which is the most an embedding
can hope for.
In any case, the tougher nut to crack is the reverse
directon: the ability to run CL code in Scheme (either
via an embedding or through a filter program). I don't
think it is technically undoable, but it will require a
good bit of clever but tedious and thankless coding,
and it does not look like enough people will find use
for it to justify the pain.
--d
From: Fernando D. Mato Mira
Subject: Re: Core Lisp (was: explicit package markers (Ex: Re: cond and if....)
Date:
Message-ID: <36F0CB76.9C0C733C@iname.com>
Dorai Sitaram wrote:
> In any case, the tougher nut to crack is the reverse
> directon: the ability to run CL code in Scheme (either
> via an embedding or through a filter program). I don't
> think it is technically undoable, but it will require a
> good bit of clever but tedious and thankless coding,
> and it does not look like enough people will find use
> for it to justify the pain.
Hm. What about the classic issues:
"Emacs will be based on Guile. RMS doesn't like CL. `RMS is evil'"
"Should the LispOS be based on Scheme or CL?"
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html