From: Cyber Surfer
Subject: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <CnGq36.2zt@cix.compulink.co.uk>
In article <···················@liasg3.epfl.ch>,
·····@lia.di.epfl.ch (Simon Leinen) writes:
> Nice anecdote, but couldn't that C compiler have used the less
> expensive instruction as well? Maybe it wanted to maintain
> compatibility with some system libraries.
The following is from a Lisp user who has not been exposed to
the views and beliefs of the Lisp community for very long (just
the last two years), but has been familiar with Lisp since the
mid 80s. Because of this, I find some of the beliefs about Lisp
and expectations of Lisp systems a little odd. It could be that
I'm used to enviroments where I've seen more solutions to things
that get in the way - if a compiler vendor can't make something
work, they change it - and where people don't worry much if that
results in a deviation from a standard.
I'm rather puzzled by a few things, and hope that someone can help
me gain greater understanding of these problems.
That's the disclaimer over with. :-)
Surely the answer (or one answer, coz it won't suit everyone)
is to compile Lisp into C? This is the option I prefer, and
in fact I'll need it, as it's the only way I currently have
o produce stand-alone Lisp programs.
I would say that, as I'm the kind of compiler-writing-nut who
likes to write custom compilers for specific apps. One of these
days I'll write one that allows the same extensions I use in
a development enviroment.
Can you believe that my first "compiler" was a Basic program
that turned the screen (memory-mapped display) into a binary
that loaded into the screen memory, and could then be loaded
by program call from any language (on that machine, at least)?
I wrote coz a friend wanted the fastest method of flashing a
display onto the screen (the "flash" code used an XOR in m/c).
My compilers a only a "little" more complex than that today,
and lot more fun, mainly coz I write them in Lisp and Forth,
and only sometimes in C, when I have to. None of them are very
fast or elegant, but they all work, and the output is always
good enough for my purposes.
I'm sure the compilers out there are far better, esp the
commercial ones. Whenever I see a discussion like this one,
it makes me wonder what people would say about apps written
in C, if all the debugging options where left in, and the
symbolic info used by debuggers.
Of course, C developers switch these options off for the
production code. I used to think that the Lisp answer to
this was to use a 2nd compiler that took the same app code
in the devlopment, but compiled it without most of the late
binding.
The Actor development system uses this option, by allowing you
add early binding info (a bit like using type declarartins in
a pure OOPL). This isn't automatic, and so Whitewater advised
developers to only use that at a late stage in development, but
it assumes that the code won't change much after that point,
which I'm been told again and again just isn't the way real code
is used. The rate at which new versions of apps appear also
suggests that it isn't realistic.
So, what you really want is a way of turning off the early binding
when you don't need it. It seems to me that Lisp leaves binding
in a permanent late "setting" , if you think of it as a switch.
You have to change the compiler, and the language, in order to
get early binding in the sense that you mean. If you assume that
named functions will never be redefined, then a reference to a
function in CL could be recognised by the compiler as a call to
the function itself, and not an indirect reference thru a symbol.
I'm perfectly comfortable with that use of two compilers, and
two distinct dialects of a language. I've seen enough compilers
for other languages that do that same trick to accept that it
may be necessary, and I think it will be, for as long as we
insist on language features that add a cost at runtime. Those
costs are not always bad, and many of them have become accepted
practice, and even find support in CPU architectures.
Have I misunderstood something very basic about Lisp systems,
and Lisp languages and dialects in particular? Please forgive
me if I have, but I don't see Lisp as somehow special and free
from the constraints that apply to other languages.
That doesn't mean I don't prefer Lisp, or see it as more
significant. :-) What I also see is that programmers often
don't have a choice. When they do, some of them choose a
language such as Smalltalk, probably coz it has a higher
profile in the areas I know. It seems like it should suffer
from the same problems as Lisp. So, perhaps Lisp isn't so
unique as far as performce costs arr concerned?
Martin Rodgers
--- Cyber Surfing on CIX ---
From: Jeff Dalton
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <CnqyFw.DIC@cogsci.ed.ac.uk>
In article <··········@cix.compulink.co.uk> ············@cix.compulink.co.uk ("Cyber Surfer") writes:
>In article <···················@liasg3.epfl.ch>,
>·····@lia.di.epfl.ch (Simon Leinen) writes:
>
>> Nice anecdote, but couldn't that C compiler have used the less
>> expensive instruction as well? Maybe it wanted to maintain
>> compatibility with some system libraries.
I've missed some articles, but this sounds like a reference to my
story about Franz Lisp being faster than C on a VAX when the cost
of precedure calls was important because Franz used a faster calling
sequence for "local" functions.
Anyway, sure, the C compiler could have used a faster sequence.
But it didn't. The Lisp implementors felt procedure calls were
very important, so they made an affort to optimize them.
As I noted before, procedure calls in Lisp used to be more efficient
than in most other languages. Other languages typically do better
now, and in many cases have faster procedure calls that typical
Lisp implementations. But Lisp can get better too.
If you compare the performance of actual implementations, there
are significant cases where Lisp is (or was) just as fast as C
or faster. If you compare what's possible in principle, then
there are a few cases where Lisp has some disadvanatges, but they
are fewer, and more narrowly defined, than you might think.
There are also going to be in-principle cases where Lisp wins,
because Lisp storage management can be more efficient.
>Surely the answer (or one answer, coz it won't suit everyone)
>is to compile Lisp into C? This is the option I prefer, and
>in fact I'll need it, as it's the only way I currently have
>o produce stand-alone Lisp programs.
There are Lisp compilers that produce C (e.g. the KCL compiler
and my Franz Lisp compiler), but the C they emit can't always
do as well as code written directly in C.
>So, what you really want is a way of turning off the early binding
>when you don't need it. It seems to me that Lisp leaves binding
>in a permanent late "setting" , if you think of it as a switch.
>You have to change the compiler, and the language, in order to
>get early binding in the sense that you mean. If you assume that
>named functions will never be redefined, then a reference to a
>function in CL could be recognised by the compiler as a call to
>the function itself, and not an indirect reference thru a symbol.
*Lisp* doesn't make binding early or late, both are possible.
It's implementations, or in some cases certain kinds of Lisp,
that decide. In any case, I'm not sure what you have in mind
by "indirect through a symbol", but all it has to be is something
like one entra memory reference. For instance, there might be
a register pointing to a table of procedure addresses and a
call would be to the address in n plus the register value.
>Have I misunderstood something very basic about Lisp systems,
>and Lisp languages and dialects in particular? Please forgive
>me if I have, but I don't see Lisp as somehow special and free
>from the constraints that apply to other languages.
Has someone said something that made it sound like it was?
I'm not sure what you have in mind here.
-- jeff
From: Cyber Surfer
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <CnxDLM.6BG@cix.compulink.co.uk>
In article <··········@cogsci.ed.ac.uk>,
····@aiai.ed.ac.uk (Jeff Dalton) writes:
> I've missed some articles, but this sounds like a reference to my
> story about Franz Lisp being faster than C on a VAX when the cost
> of precedure calls was important because Franz used a faster calling
> sequence for "local" functions.
I don't recall that. My UseNet feed has been dead for a few days,
so I may have also missed some articles.
> There are Lisp compilers that produce C (e.g. the KCL compiler
> and my Franz Lisp compiler), but the C they emit can't always
> do as well as code written directly in C.
Maybe not, but if thet can do it most of the time, that'll be
good enough for me.
> *Lisp* doesn't make binding early or late, both are possible.
> It's implementations, or in some cases certain kinds of Lisp,
> that decide. In any case, I'm not sure what you have in mind
That's my point, too. I get tired of people criticising Lisp,
when they should really be criticising their Lisp implementations
IMHO. I've used C compilers I could complain about, but I don't
confuse them with the language.
> by "indirect through a symbol", but all it has to be is something
> like one entra memory reference. For instance, there might be
> a register pointing to a table of procedure addresses and a
> call would be to the address in n plus the register value.
Why use a table of procedure addresses? If I were to call the
LIST function and feed that expression into a Lisp to C compiler,
why couldn't it make that a hardcoded call (to a runtime function
for LIST, or a series of calls to a runtime function for CONS)
instead of getting the function currently defined for the LIST
symbol?
That's part of what I mean by "early binding". I'd like a compiler
that can assume that functions will never be redefined, as I don't
consider that to be so useful in a stand-alone program as eliminating
the runtime cost for fetching the function pointer from a symbol.
Late binding is great for when you're developing a program, but
it's not so common to redefine a function once the app has been
delivered to the user - not in the apps I know.
> >Have I misunderstood something very basic about Lisp systems,
> >and Lisp languages and dialects in particular? Please forgive
> >me if I have, but I don't see Lisp as somehow special and free
> >from the constraints that apply to other languages.
>
> Has someone said something that made it sound like it was?
Yes. Some people assume that it should always be possible to
redefine functions, while that would seem very strange to a C
programmer. I agree that it's useful while developing an app,
but I'm not so sure that all functions should be redefinable
when the code is running on the user's machine. There's are
many cases where that would be very undesirable, for a number
reasons. Performance is just one of them, but a crtital one,
judging by the criticisms of Lisp and similar languages (Smalltalk,
Actor, Prolog etc) by C and Pascal programmers.
Martin Rodgers
Cyber Surfing on CIX
--------------------
"First you see Pringle sweaters, then you wear Pringle sweaters,
then you eat Pringle sweaters, then you _be_ Pringle sweaters."
-- Pat Cardigan
From: Fernando Mato Mira
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <2o3ig9$gcl@disuns2.epfl.ch>
In article <··········@cix.compulink.co.uk>, ············@cix.compulink.co.uk ("Cyber Surfer") writes:
> but I'm not so sure that all functions should be redefinable
> when the code is running on the user's machine. There's are
> many cases where that would be very undesirable, for a number
> reasons. Performance is just one of them, but a crtital one,
> judging by the criticisms of Lisp and similar languages (Smalltalk,
> Actor, Prolog etc) by C and Pascal programmers.
What I do not understand is why the people that wrote the original
Common Lisp spec put INLINE but not a declaration (ignorable also)
to specify just this. If you redefine an inlined function the code
using it that was already compiled won't see the change, so what's
the problem to have this too? While some implementations might
translate INLINE in this way instead of doing a code expansion,
a "softer" declaration would be useful. Then, the behavior of a
particular compiler can be for example to ensure this freezing
(and maybe code expand, according to space and speed settings) when
this softer declaration is given, and really expand the code when
you declare something INLINE (for example, because the environment
lacks the dynamic analysis abilities to prove that (not)expanding
something is optimal or not).
In fact, the semantics of this softer declaration are probably
those of INLINE, and what is really needed is the delaration
for this really-inline thing. How about EXPAND for a name?
Again, this is an optional declaration, as usual.
As a last example, an implementation might specify about this
declarations:
INLINE:
At least no symbol-function indirection is performed. Additionally,
the compiler might open-code the called function if speed>space and
it can prove that expression will evaluate faster (?? always,
in general??) by doing so.
EXPAND:
At least no symbol-function indirection is performed. Additionally,
the compiler will open-code the called function unless it can prove
that the expression will ALWAYS evaluate faster by not doing so.
--
F.D. "Cyber Kid" Mato Mira
Computer Graphics Lab ········@epfl.ch
EPFL FAX: +41 (21) 693-5328
From: The Crossjammer
Subject: Late binding. was Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <XJAM.94Apr8133421@palm.CS.Berkeley.EDU>
>>>>> In article <··········@cix.compulink.co.uk>, ············@cix.compulink.co.uk ("Cyber Surfer") writes:
"Cyber> Yes. Some people assume that it should always be possible to
"Cyber> redefine functions, while that would seem very strange to a C
"Cyber> programmer. I agree that it's useful while developing an app,
"Cyber> but I'm not so sure that all functions should be redefinable
"Cyber> when the code is running on the user's machine. There's are
"Cyber> many cases where that would be very undesirable, for a number
"Cyber> reasons. Performance is just one of them, but a crtital one,
"Cyber> judging by the criticisms of Lisp and similar languages (Smalltalk,
"Cyber> Actor, Prolog etc) by C and Pascal programmers.
Thou doth protest too much.
This is just a design choice that these languages have made. If you're
going to insist on using Lisp then you need to decide if late binding is
paying for itself or that there's some other feature in Lisp which is
desirable enough to make you forget about the cost of late binding.
Lisp people assume that it should always be possible to redefine functions
and *that it is desirable to do so*.
The people that don't use different languages.
One "advantage" it does provide is the capability to apply bug fixes to
running programs.
--
····@cs.Berkeley.EDU "They can't come on and play me in prime time,
Cause I know the time, cause I'm gettin' mine
Gotta have house... I get on the mix late in the night..."
From: Cyber Surfer
Subject: Late binding. was Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE E
Date:
Message-ID: <Co1572.2FH@cix.compulink.co.uk>
In article <·················@palm.CS.Berkeley.EDU>,
····@palm.CS.Berkeley.EDU (The Crossjammer) writes:
> Thou doth protest too much.
I'm not protesting. I'm just saying that I'm a little tired of
people complaining (whinging?) about _implementations_, and
often not suggesting anything constructive. apart from that,
it's possible that I agree with you.
IMHO programmers usually get what they ask for, sooner or later.
:-)
> One "advantage" it does provide is the capability to apply bug fixes to
> running programs.
That doesn't make another other way of running programs (as a
stand-alone binary, for example) impossible. I've used both
forms of delivery/devlopment (fully incremental compiling and
then a seal-off, and the typical C/C++ edit/compile/link cycle),
so I know the advantages to both styles. Finger me for details.
Martin Rodgers
Cyber Surfing on CIX
--------------------
"First you see Pringle sweaters, then you wear Pringle sweaters,
then you eat Pringle sweaters, then you _be_ Pringle sweaters."
-- Pat Cardigan
From: Jeff Dalton
Subject: Re: Late binding. was Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <Co2445.K6n@cogsci.ed.ac.uk>
In article <·················@palm.CS.Berkeley.EDU> ····@palm.CS.Berkeley.EDU (The Crossjammer) writes:
>Lisp people assume that it should always be possible to redefine functions
>and *that it is desirable to do so*.
Sez who? I don't, and I'm a Lisp person.
>The people that don't use different languages.
>
>One "advantage" it does provide is the capability to apply bug fixes to
>running programs.
I'd say that's an advantage, not just an "advantage", which is not
to say other methods are necessarily worse.
-- jd
From: ·········@cc.helsinki.fi
Subject: Re: Late binding. was Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <1994Apr12.095010.1@cc.helsinki.fi>
In article <··········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
> In article <·················@palm.CS.Berkeley.EDU> ····@palm.CS.Berkeley.EDU (The Crossjammer) writes:
>
>>Lisp people assume that it should always be possible to redefine functions
>>and *that it is desirable to do so*.
>
> Sez who? I don't, and I'm a Lisp person.
>
>>The people that don't use different languages.
>>
>>One "advantage" it does provide is the capability to apply bug fixes to
>>running programs.
>
> I'd say that's an advantage, not just an "advantage", which is not
> to say other methods are necessarily worse.
>
> -- jd
From: Jeff Dalton
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <Co23uw.K2I@cogsci.ed.ac.uk>
In article <··········@cix.compulink.co.uk> ············@cix.compulink.co.uk ("Cyber Surfer") writes:
>In article <··········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>> There are Lisp compilers that produce C (e.g. the KCL compiler
>> and my Franz Lisp compiler), but the C they emit can't always
>> do as well as code written directly in C.
>
>Maybe not, but if thet can do it most of the time, that'll be
>good enough for me.
Generally they can't without help from declarations.
Lisp-in-C tends to use, in effect, a pointer to a union of
structs for all data. So everything is a pointer, which is
already going to be less efficient that C can be. But a
declaration can tell the Lisp compiler to use a more
direct representation.
So that's one problem. Another problem is that Lisp data are
supposed to be garbage collected. To a fair extent, this
problem has been solved by "conservative" garbage collectors.
But still Lisp systems often take steps to keep track of
active values that aren't necessary in C.
>> *Lisp* doesn't make binding early or late, both are possible.
>> It's implementations, or in some cases certain kinds of Lisp,
>> that decide. In any case, I'm not sure what you have in mind
>
>That's my point, too. I get tired of people criticising Lisp,
>when they should really be criticising their Lisp implementations
>IMHO. I've used C compilers I could complain about, but I don't
>confuse them with the language.
>
>> by "indirect through a symbol", but all it has to be is something
>> like one entra memory reference. For instance, there might be
>> a register pointing to a table of procedure addresses and a
>> call would be to the address in n plus the register value.
>
>Why use a table of procedure addresses? If I were to call the
>LIST function and feed that expression into a Lisp to C compiler,
>why couldn't it make that a hardcoded call (to a runtime function
>for LIST, or a series of calls to a runtime function for CONS)
>instead of getting the function currently defined for the LIST
>symbol?
It could, and some Lisp systems do. Simple built-in functions,
such as CONS, can also me compiled in-line rather than as function
calls. But then you lose the ability to redefine, trace, etc.
My point was that when you want indirection the cost still isn't
very highg.
>That's part of what I mean by "early binding". I'd like a compiler
>that can assume that functions will never be redefined, as I don't
>consider that to be so useful in a stand-alone program as eliminating
>the runtime cost for fetching the function pointer from a symbol.
It can be done so that nothing has to be fetched from a symbol at call
time. For instance, the Franz Lisp compiler and loader (and this is
not the most sophisticated technology available) set up a table of
call addresses for all the functions in a given compiled file to use.
The table is set up when the file is loaded, and a call is indirect
through a location that is offset from the table address, which is in
a register. (This is pretty much what I was describing before.)
(Franz experts will note that I'm leaving out the "translink"
mechanism.)
>Late binding is great for when you're developing a program, but
>it's not so common to redefine a function once the app has been
>delivered to the user - not in the apps I know.
That's true, although I sometimes implement some things by advising
functins rather than, say, setting a flag.
For example: I have a system that can display somethign that shows
what "components" are active. The display can be turned on and off.
I turn it on by "advising" (redefining) some functions to update the
display in addition to whatever they normally do.
>> >Have I misunderstood something very basic about Lisp systems,
>> >and Lisp languages and dialects in particular? Please forgive
>> >me if I have, but I don't see Lisp as somehow special and free
>> >from the constraints that apply to other languages.
>>
>> Has someone said something that made it sound like it was?
>
>Yes. Some people assume that it should always be possible to
>redefine functions, while that would seem very strange to a C
>programmer. I agree that it's useful while developing an app,
>but I'm not so sure that all functions should be redefinable
>when the code is running on the user's machine. There's are
>many cases where that would be very undesirable, for a number
>reasons.
Such as?
> Performance is just one of them, but a crtital one,
>judging by the criticisms of Lisp and similar languages (Smalltalk,
>Actor, Prolog etc) by C and Pascal programmers.
Some people think you should compile applications with -g in C,
so that you have more chance of debugging. So I think this is
something that will vary from person to person and application
to application.
One advantage that Lisp can get from redefinability in applications
is that you can distribute a "patch" that can fix problems in a
binary-only distribution without having to relink or something
like that.
Anyway, I think there should be Lisp implementations that let
you have non-redefinable functions. I'm all for Lisps that fit
better with C. For one thing, I'd like to be able to use Lisp
when writing parts of applications that are partly or mostly in C.
-- jd
From: Cyber Surfer
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <Co4sCz.536@cix.compulink.co.uk>
In article <··········@cogsci.ed.ac.uk>,
····@aiai.ed.ac.uk (Jeff Dalton) writes:
> >Yes. Some people assume that it should always be possible to
> >redefine functions, while that would seem very strange to a C
> >programmer. I agree that it's useful while developing an app,
> >but I'm not so sure that all functions should be redefinable
> >when the code is running on the user's machine. There's are
> >many cases where that would be very undesirable, for a number
> >reasons.
>
> Such as?
Are you asking for examples of undesirable cases or reasons
why they they would be undesirable? I was thinking of all the
for code for functions, as I don't see complaints about single
functions in apps that are 30 MBs or more.
It's hard to know which individual functions are contributing
to the size or performance problem when the user deoesn't have
access to the source code for the app.
Martin Rodgers
Cyber Surfing on CIX
--
"First you see Pringle sweaters, then you wear Pringle sweaters,
then you eat Pringle sweaters, then you _be_ Pringle sweaters."
-- Pat Cardigan
From: Jeff Dalton
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <Co5unp.97t@cogsci.ed.ac.uk>
In article <··········@cix.compulink.co.uk> ············@cix.compulink.co.uk ("Cyber Surfer") writes:
>In article <··········@cogsci.ed.ac.uk>,
>····@aiai.ed.ac.uk (Jeff Dalton) writes:
>
>> >Yes. Some people assume that it should always be possible to
>> >redefine functions, while that would seem very strange to a C
>> >programmer. I agree that it's useful while developing an app,
>> >but I'm not so sure that all functions should be redefinable
>> >when the code is running on the user's machine. There's are
>> >many cases where that would be very undesirable, for a number
>> >reasons.
>>
>> Such as?
>
>Are you asking for examples of undesirable cases or reasons
>why they they would be undesirable?
Both, I guess, but nostly the cases.
> I was thinking of all the
>for code for functions, as I don't see complaints about single
>functions in apps that are 30 MBs or more.
>
>It's hard to know which individual functions are contributing
>to the size or performance problem when the user deoesn't have
>access to the source code for the app.
I don't understand what you're saying here.
From: Cyber Surfer
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <CoHr08.8rK@cix.compulink.co.uk>
In article <··········@cogsci.ed.ac.uk>,
····@aiai.ed.ac.uk (Jeff Dalton) writes:
> > I was thinking of all the
> >for code for functions, as I don't see complaints about single
> >functions in apps that are 30 MBs or more.
> >
> >It's hard to know which individual functions are contributing
> >to the size or performance problem when the user deoesn't have
> >access to the source code for the app.
>
> I don't understand what you're saying here.
If you're comparing apps written in Lisp with apps written in
C++, you may find that with the latter, you can see which
functions are contributing to the size of performance of an
app unless you see the source code, and that isn't usually
available to a user.
That's why I think there a lot of users who won't care if the
app they use can't recompile its own components (functions).
That's for the developer to do.
It may be different for users of Lisp apps, but I don't know
that many, so I can't say. I _do_ know many users of apps written
in C and C++.
We're slowly drifting away from the original question, but it
was about a difference between Lisp/Smalltalk and C/C++.
Martin Rodgers
-- Cyber Surfing on CIX --
"First you see Pringle sweaters, then you wear Pringle sweaters,
then you eat Pringle sweaters, then you _be_ Pringle sweaters."
-- Pat Cardigan
From: Cyber Surfer
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <CoJLsC.Isu@cix.compulink.co.uk>
In article <··········@cogsci.ed.ac.uk>,
····@aiai.ed.ac.uk (Jeff Dalton) writes:
> > I was thinking of all the
> >for code for functions, as I don't see complaints about single
> >functions in apps that are 30 MBs or more.
> >
> >It's hard to know which individual functions are contributing
> >to the size or performance problem when the user deoesn't have
> >access to the source code for the app.
>
> I don't understand what you're saying here.
If you're comparing apps written in Lisp with apps written in
C++, you may find that with the latter, you can see which
functions are contributing to the size of performance of an
app unless you see the source code, and that isn't usually
available to a user.
That's why I think there a lot of users who won't care if the
app they use can't recompile its own components (functions).
That's for the developer to do.
It may be different for users of Lisp apps, but I don't know
that many, so I can't say. I _do_ know many users of apps written
in C and C++.
We're slowly drifting away from the original question, but it
was about a difference between Lisp/Smalltalk and C/C++.
Martin Rodgers
-- Cyber Surfing on CIX --
"First you see Pringle sweaters, then you wear Pringle sweaters,
then you eat Pringle sweaters, then you _be_ Pringle sweaters."
-- Pat Cardigan
From: Cyber Surfer
Subject: Re: Function call efficiency in Lisp (was: Re: Melting Ice in ISE Eiffel)
Date:
Message-ID: <Co4sD1.53s@cix.compulink.co.uk>
In article <··········@cogsci.ed.ac.uk>,
····@aiai.ed.ac.uk (Jeff Dalton) writes:
> Some people think you should compile applications with -g in C,
> so that you have more chance of debugging. So I think this is
> something that will vary from person to person and application
> to application.
And C compiler. The level of info added to the object code can
also vary from compiler to compiler. Of course, that could just
be pendantry. However, you could also just add debugging info
to a single module, and different levels of info.
This could depend a lot on the choice of compiler. I rare use
sdebuggin info lately, but that's just a personal quirk. There's
also overhead for assertion checking in my C/C++ code, and that's
another issue.
> One advantage that Lisp can get from redefinability in applications
> is that you can distribute a "patch" that can fix problems in a
> binary-only distribution without having to relink or something
> like that.
I've recently added a patch for the C++ compiler I use. Another
much larger patch has become available since then (approx 5 MB).
These are binary patches applied to a set of files. This could
also be done for user apps.
> Anyway, I think there should be Lisp implementations that let
> you have non-redefinable functions. I'm all for Lisps that fit
> better with C. For one thing, I'd like to be able to use Lisp
> when writing parts of applications that are partly or mostly in C.
I agree. That's very desirable.
I'm currently looking for a CL system that is MS Windows hosted,
and can dynamically link to functions in DLL libraries. Most
languages for this platform support this, and Allegro CL/PC looks
like the one I'd choose, but I'm not ready to spend that amount
of money this year.
A Lisp to C compiler is an option that interests me, and I have
a number to choose from. As you might guess, I like to keep my
options an open as possible. :-)
My Internet is shifting to a private host soon, so I'll appear as
·····@wildcard.demon.co.uk. I have email working there already.
Martin Rodgers
Cyber Surfing on CIX
--
"First you see Pringle sweaters, then you wear Pringle sweaters,
then you eat Pringle sweaters, then you _be_ Pringle sweaters."
-- Pat Cardigan