Is it correct to say that the basic difference between C type languages and
LISP is that in LISP we get runtime information about the type of an object
and in C we do not. And that we have to decide if the addtional power we get
is worth the price?
Janos Blazi
* Janos Blazi
| Is it correct to say that the basic difference between C type languages
| and LISP is that in LISP we get runtime information about the type of an
| object and in C we do not.
no. the basic difference is that a Lisp treats code as data (and has
stuff in it that makes this possible, such as type information), while in
C, never the twain shall meet (because all you need to know, the compiler
took with it when it left the scene).
| And that we have to decide if the addtional power we get is worth the
| price?
what price? it's C that costs extra. ever seen how expensive it is to
_know_ the type of an object in C code? they invented CORBA and IDL to
do this. seen SGML/HTML/XML? they tried to figure out this "how to
represent structured stuff in text" question that Lisp solved in 1960
with READ and PRINT that worked on lists. it amazes me that people can't
see beyond the fa�ade of the soi-disant "simple" languages and solutions,
but, hey, would advertising on television work if people actually did?
PLEASE, start to question your own assumptions so you can discuss them,
rather than just fling out one annoying generalization after another.
#:Erik
In article <····································@broadway.news.is-europe.net>,
Janos Blazi <······@netsurf.de> wrote:
>Is it correct to say that the basic difference between C type languages and
>LISP is that in LISP we get runtime information about the type of an object
>and in C we do not. And that we have to decide if the addtional power we get
>is worth the price?
This is one difference, but hardly "the basic difference". There are now a
number of OO languages that most would consider more "C type" than "Lisp
type", but which make runtime type information available. Even C++ has
RTTI now, although it's only available for classes with virtual members.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
I read about LISP programs' ability to modify themselves in several books
but I did not understand it.
In the seventies when I wrote assembly language code for the 6502 modifying
your code while running was necessary as we did not have enough memory in
those days and speed was an issue as well.
But virtually everybody agreed that it was terrible programming style.
But then Intel "improved" its segmenting model and calling a memory location
in a code segment even raised an exception. They regarded this as a
trtiumph.
So we probably do not mean the same thing. I surmise I would have to study
the LISP macro mechanism to understand that. Is this an AI matter? Why is it
important.
And if I do not intend to write code that modifies itself: does that mean
that LISP is nothing for me? I only want to use LISP for educational
purposes for thos "Rings of Hanoi" type problems.
Janos Blazi
Barry Margolin <······@bbnplanet.com> schrieb in im Newsbeitrag:
················@burlma1-snr2...
> In article
<····································@broadway.news.is-europe.net>,
> Janos Blazi <······@netsurf.de> wrote:
> >Is it correct to say that the basic difference between C type languages
and
> >LISP is that in LISP we get runtime information about the type of an
object
> >and in C we do not. And that we have to decide if the addtional power we
get
> >is worth the price?
>
> This is one difference, but hardly "the basic difference". There are now
a
> number of OO languages that most would consider more "C type" than "Lisp
> type", but which make runtime type information available. Even C++ has
> RTTI now, although it's only available for classes with virtual members.
>
> --
> Barry Margolin, ······@bbnplanet.com
> GTE Internetworking, Powered by BBN, Burlington, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to
newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the
group.
"Janos Blazi" <······@netsurf.de> writes:
> I read about LISP programs' ability to modify themselves in several books
> but I did not understand it.
Have you read the classic good Lisp books? My personal recommendation
would be to read Graham's books (ANSI Common Lisp, and On Lisp), and
Norvig's Paradigms of Artificial Intelligence Programming: Case
Studies in Common Lisp.
Lisp has a truly excellent literature. Spend $200 on a few good
books, get a decent Lisp implementation (there are many, both free and
commercial; see www.alu.org for a list), and use and study the
language for a little while.
-matt
Janos Blazi <······@netsurf.de> wrote in message
······································@broadway.news.is-europe.net...
> And if I do not intend to write code that modifies itself: does that mean
> that LISP is nothing for me? I only want to use LISP for educational
> purposes for thos "Rings of Hanoi" type problems.
>
I have used lisp for about a year, in school for AI projects and
assignments and now as a professional software developer. Have never
written any self modifying code. I think lisp is great! I liked C and Java
and lots of other stuff but i hope i can stick with lisp my entire career.
Just go with the flow and enjoy!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Coby Beck
Software Developer
__________________________
Mercury Scheduling Systems
400 - 601 West Cordova
Vancouver, BC
ph - (604) 683-8668 ext 370
fax- (604) 688-2375
http://www.mercury.bc.ca/
Email- ·····@mercury.bc.ca
In article <·································@broadway.news.is-europe.net>,
Janos Blazi <······@netsurf.de> wrote:
>I read about LISP programs' ability to modify themselves in several books
>but I did not understand it.
Don't worry about it, since it's never actually done. It's possible in
interpreted implementations, but most serious applications are compiled,
and this ability is severely limited. Some early AI theorists thought that
this would be an important feature, since natural learning presumably
operates by the brain modifying itself, but I don't think many serious AI
designs were based on this model.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
On Fri, 29 Oct 1999 21:51:15 GMT, Barry Margolin <······@bbnplanet.com> wrote:
>In article <·································@broadway.news.is-europe.net>,
>Janos Blazi <······@netsurf.de> wrote:
>>I read about LISP programs' ability to modify themselves in several books
>>but I did not understand it.
>
>Don't worry about it, since it's never actually done. It's possible in
>interpreted implementations, but most serious applications are compiled,
>and this ability is severely limited. Some early AI theorists thought that
>this would be an important feature, since natural learning presumably
>operates by the brain modifying itself, but I don't think many serious AI
>designs were based on this model.
It's highly common for Lisp code to contain code that *writes* code,
which is almost, but not *precisely* the same thing.
CL provides considerable control over when things get compiled, which
means that you can take code, rewrite it on the fly using macros into
a more useful form, and have *that* be what gets compiled, which means
you get both:
a) Considerable control over what got compiled, as well as
b) Optimization of what got compiled.
--
"The main reason for open-source gets developed is need. If the need
is there, then the software will get written. If it isn't really
needed, then the lack of software is hardly a problem, right?"
-- Almost Brian Hurt's Words <·····@visi.com>
········@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>
Barry Margolin <······@bbnplanet.com> writes:
> In article <·································@broadway.news.is-europe.net>,
> Janos Blazi <······@netsurf.de> wrote:
> >I read about LISP programs' ability to modify themselves in several books
> >but I did not understand it.
>
> Don't worry about it, since it's never actually done.
It is actually done. If not, then what's all this
UPDATE-INSTANCE-FOR-(REDEFINED|CHANGED)-CLASS stuff and its kin about?
> It's possible in interpreted implementations, but most serious
> applications are compiled,
You can call the compiler during runtime. The COMPILATION-SPEED
OPTIMIZE declaration is important in this context. (As if it made a
difference....)
> and this ability is severely limited. Some early AI theorists
> thought that this would be an important feature, since natural
> learning presumably operates by the brain modifying itself, but I
> don't think many serious AI designs were based on this model.
Genetic programming kinda is. But I don't think there are many
interesting results from it....
Christopher
* Christopher R Barry wrote:
> It is actually done. If not, then what's all this
> UPDATE-INSTANCE-FOR-(REDEFINED|CHANGED)-CLASS stuff and its kin about?
I think this is quite a `weak' form of self-modification in the sense
that most of what goes on is (presumably) simply loading / compiling
some new code into memory, and then clobbering a few function pointers
to point at this new stuff. I'd be surprised if many implementations
actually alter the executable code of functions in place, which is a
horrible nightmare on any modern CPU I should think (caching
issues...). And I think that latter thing -- in place hacking of
executable code -- is what people usually mean by `self-modification'.
I could easily be wrong though.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> * Christopher R Barry wrote:
>
> > It is actually done. If not, then what's all this
> > UPDATE-INSTANCE-FOR-(REDEFINED|CHANGED)-CLASS stuff and its kin about?
>
> I think this is quite a `weak' form of self-modification in the sense
> that most of what goes on is (presumably) simply loading / compiling
> some new code into memory, and then clobbering a few function pointers
> to point at this new stuff. I'd be surprised if many implementations
> actually alter the executable code of functions in place, which is a
> horrible nightmare on any modern CPU I should think (caching
> issues...). And I think that latter thing -- in place hacking of
> executable code -- is what people usually mean by `self-modification'.
Franz literature talks extensively about "Runtime Extensiblity" being
a key advantage of its "Dynamic Objects" technology for many types of
applications:
http://www.franz.com/tech/technotes/dofeatures.main.html
If you click the "technology" link on their home page you'll see many
papers that mention runtime modification being a very important
advantage. They are unfortunately rather vague on the details,
however.
Christopher
Tim Bradshaw <···@tfeb.org> writes:
> * Christopher R Barry wrote:
>
> > It is actually done. If not, then what's all this
> > UPDATE-INSTANCE-FOR-(REDEFINED|CHANGED)-CLASS stuff and its kin about?
>
> I think this is quite a `weak' form of self-modification in the sense
> that most of what goes on is (presumably) simply loading / compiling
> some new code into memory, and then clobbering a few function pointers
> to point at this new stuff. I'd be surprised if many implementations
> actually alter the executable code of functions in place, which is a
> horrible nightmare on any modern CPU I should think (caching
> issues...). And I think that latter thing -- in place hacking of
> executable code -- is what people usually mean by `self-modification'.
Franz literature talks extensively about "Runtime Extensiblity" being
a key advantage of its "Dynamic Objects" technology for many types of
applications:
http://www.franz.com/tech/technotes/dofeatures.main.html
If you click the "technology" link on their home page you'll see many
papers that mention runtime modification being a very important
advantage. They are unfortunately rather vague on the details,
however.
Christopher
In article <··············@2xtreme.net>,
······@2xtreme.net (Christopher R. Barry) wrote:
> Franz literature talks extensively about "Runtime Extensiblity" being
> a key advantage of its "Dynamic Objects" technology for many types of
> applications:
>
> http://www.franz.com/tech/technotes/dofeatures.main.html
>
> If you click the "technology" link on their home page you'll see many
> papers that mention runtime modification being a very important
> advantage. They are unfortunately rather vague on the details,
> however.
For us this means giving an application the ability to create new
classes, not just instantiations of programmer defined classes. Or to
add slots to an pre-existing class. This allows the user of an
application to program the application in some sense. Imagine an
application that collects and databases process signals from a
manufacturing plant's production line. As the production line is
modified or new sensors are installed there are new signals to be
collected. Rather than the Lisp programmer creating classes for them
the user (or maintainer) can create them with an GUI editor. The new
signal will be defined according to factors such as (integer, float,
boolean); (per-widget, per-batch), etc. A new class is defined,
dynamically, as the application continues to run and the new signal is
collected and databased accordingly.
--
John Watton
Alcoa Inc.
Sent via Deja.com http://www.deja.com/
Before you buy.
I do not quite understand how that would work out in real life.
But the factory is most likely having a software house maintain their
software and I can imagine (if the software house were SIEMENS for example)
that the quality assurance guys would not like the idea that programs are
being modified while they are running, as it may be very difficult to
monitor this process from QA's point of view.
But it sound interesting. If the software were written in C the software
house would recompile the software or (as I saw with my own eyes) the would
delivere a patch. And after two years there would be no valid source code
any more, only patches.
John Watton <···········@alcoa.com> schrieb in im Newsbeitrag:
············@nnrp1.deja.com...
> In article <··············@2xtreme.net>,
> ······@2xtreme.net (Christopher R. Barry) wrote:
> > Franz literature talks extensively about "Runtime Extensiblity" being
> > a key advantage of its "Dynamic Objects" technology for many types of
> > applications:
> >
> > http://www.franz.com/tech/technotes/dofeatures.main.html
> >
> > If you click the "technology" link on their home page you'll see many
> > papers that mention runtime modification being a very important
> > advantage. They are unfortunately rather vague on the details,
> > however.
>
> For us this means giving an application the ability to create new
> classes, not just instantiations of programmer defined classes. Or to
> add slots to an pre-existing class. This allows the user of an
> application to program the application in some sense. Imagine an
> application that collects and databases process signals from a
> manufacturing plant's production line. As the production line is
> modified or new sensors are installed there are new signals to be
> collected. Rather than the Lisp programmer creating classes for them
> the user (or maintainer) can create them with an GUI editor. The new
> signal will be defined according to factors such as (integer, float,
> boolean); (per-widget, per-batch), etc. A new class is defined,
> dynamically, as the application continues to run and the new signal is
> collected and databased accordingly.
> --
> John Watton
> Alcoa Inc.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
In article <·····························@broadway.news.is-europe.net>,
"Janos Blazi" <······@netsurf.de> wrote:
> I do not quite understand how that would work out in real life.
> But the factory is most likely having a software house maintain their
> software and I can imagine (if the software house were SIEMENS for
example)
> that the quality assurance guys would not like the idea that programs
are
> being modified while they are running, as it may be very difficult to
> monitor this process from QA's point of view.
I'm not sure you would recognize real life if it struck you on the
head. Rest assured that my example was not a fiction conjured up for
pedagogical purposes.
--
John Watton
Alcoa Inc.
Sent via Deja.com http://www.deja.com/
Before you buy.
Janos Blazi <······@netsurf.de> wrote:
> I do not quite understand how that would work out in real life.
> But the factory is most likely having a software house maintain their
> software and I can imagine (if the software house were SIEMENS for example)
> that the quality assurance guys would not like the idea that programs are
> being modified while they are running, as it may be very difficult to
> monitor this process from QA's point of view.
What is the difference between patching a running and a non-running
program from a QA point of view?
> But it sound interesting. If the software were written in C the software
> house would recompile the software or (as I saw with my own eyes) the would
> delivere a patch. And after two years there would be no valid source code
> any more, only patches.
Sure, but during this process you have to stop the program, patch it,
and then start it again. If you have a mission critical program and
your business depends on it, you may lose lots of time/money.
In CL you simply say (load "my-patch") and your program never stops.
Another advantage (it probably has already been mentioned) is that you
can debug it while running. When you are in the debugger you can find
out what's going wrong and fix it; the program never stops, quite
contrary to C(++).
--
Clemens Heitzinger
http://ag.or.at:8000/~clemens
In article <·······························@ag.or.at>,
········@ag.or.at (Clemens Heitzinger) wrote:
> Janos Blazi <······@netsurf.de> wrote:
>
> > I do not quite understand how that would work out in real life.
> > But the factory is most likely having a software house maintain
their
> > software and I can imagine (if the software house were SIEMENS for
example)
> > that the quality assurance guys would not like the idea that
programs are
> > being modified while they are running, as it may be very difficult
to
> > monitor this process from QA's point of view.
>
> What is the difference between patching a running and a non-running
> program from a QA point of view?
>
> > But it sound interesting. If the software were written in C the
software
> > house would recompile the software or (as I saw with my own eyes)
the would
> > delivere a patch. And after two years there would be no valid source
code
> > any more, only patches.
>
> Sure, but during this process you have to stop the program, patch it,
> and then start it again. If you have a mission critical program and
> your business depends on it, you may lose lots of time/money.
>
> In CL you simply say (load "my-patch") and your program never stops.
How in earth one could get this to work. Hmm... Sounds suspicous.
Because the time frame when one is updating the code/shared library,
there exists two version quite probably for couple of milliseconds, so
the program really stops, I think.
If the function calls goes by symbol value cell instead the linker
label, the problem is even worse.
PKY
PKY
>
> Another advantage (it probably has already been mentioned) is that you
> can debug it while running. When you are in the debugger you can find
> out what's going wrong and fix it; the program never stops, quite
> contrary to C(++).
>
> --
> Clemens Heitzinger
> http://ag.or.at:8000/~clemens
>
Sent via Deja.com http://www.deja.com/
Before you buy.
················@hybrid.fi writes:
> In article <·······························@ag.or.at>,
> ········@ag.or.at (Clemens Heitzinger) wrote:
> > Sure, but during this process you have to stop the program, patch it,
> > and then start it again. If you have a mission critical program and
> > your business depends on it, you may lose lots of time/money.
> >
> > In CL you simply say (load "my-patch") and your program never stops.
>
> How in earth one could get this to work. Hmm... Sounds suspicous.
> Because the time frame when one is updating the code/shared library,
> there exists two version quite probably for couple of milliseconds, so
> the program really stops, I think.
As in another posting, which I answered, you seem to be thinking in
terms of C linkers, which can't have two copies of the same function
present at the same time (because they are not then identifiable, and
the linker must be able to identify the copies). The compile/link/load
paradigm is precisely the reason why the concept of patching on the fly
is foreign to those who haven't seen it in action in lisp.
> If the function calls goes by symbol value cell instead the linker
> label, the problem is even worse.
I presume here that you meant the symbol's function cell (though in
Scheme it is the symbol's value cell that holds the function).
OK, I'll bite. The function call goes by the symbol function cell.
Why is the problem even worse?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
On Thu, 04 Nov 1999 05:51:40 GMT, ················@hybrid.fi wrote:
>
>How in earth one could get this to work. Hmm... Sounds suspicous.
>Because the time frame when one is updating the code/shared library,
>there exists two version quite probably for couple of milliseconds, so
>the program really stops, I think.
>If the function calls goes by symbol value cell instead the linker
>label, the problem is even worse.
>
Not only does it work, but the lisp system will probably be able to
free the memory used by the original functions. A reference to the
running function on the stack will keep the garbage collector from
freeing it when it is still being executed.
On the other hand, if you are updating functions whose signatures have
changed, and other functions which call those functions, you have to
be careful that they all get updated together. This might require some
effort on the part of the programmer to ensure.
Roger Corman
In article <··················@nntp.best.com>,
·····@xippix.com (Roger Corman) wrote:
> On Thu, 04 Nov 1999 05:51:40 GMT, ················@hybrid.fi wrote:
>
> >
> >How in earth one could get this to work. Hmm... Sounds suspicous.
> >Because the time frame when one is updating the code/shared library,
> >there exists two version quite probably for couple of milliseconds,
so
> >the program really stops, I think.
> >If the function calls goes by symbol value cell instead the linker
> >label, the problem is even worse.
> >
> Not only does it work, but the lisp system will probably be able to
> free the memory used by the original functions. A reference to the
> running function on the stack will keep the garbage collector from
> freeing it when it is still being executed.
>
> On the other hand, if you are updating functions whose signatures have
> changed, and other functions which call those functions, you have to
> be careful that they all get updated together. This might require some
> effort on the part of the programmer to ensure.
U see the point. Think about maybe 20 threads executing one at a time. Y
do a change to some of the functions in runtime, so that the behaviour
of the functions change a little bit, not too much, maybe. Some quite
weird things can happen, when u call function like(funcall 'foobar
(symbol-function 'foobar) #'foobar (symbol-function 'foobar)).
What happens if some of the threads change the value-cell for
symbol-function between the evaluation of function arguments.....
PKY
Don't remember any more if funcall 'foobar is legal, sigh has been
programming for my bad luck with C/C++ for last 6 years.
;-)
>
> Roger Corman
>
Sent via Deja.com http://www.deja.com/
Before you buy.
* ················@hybrid.fi
| What happens if some of the threads change the value-cell for
| symbol-function between the evaluation of function arguments.....
nothing out of the ordinary. accesses to the symbol-function slots are
atomic, and the function object itself is obviously not changed in
mid-flight. (disasters might ensue if you change a shared library or an
executable image on disk and it is paged in, but the Lisp world is not
doing stuff like that, even though the Unix world seems to be quite fond
of _not_ locking pages that are mapped into memory with the execute bit
set. sigh.)
| Don't remember any more if funcall 'foobar is legal, sigh has been
| programming for my bad luck with C/C++ for last 6 years.
calls to global functions always go through the symbol-function slot of
the symbol, anyway. only if you capture the functional value of a symbol
in a local binding (such as an argument to a function) will you avoid
this lookup at every call. (long-lived-thing #'function-that-may-change)
is thus not a good idea if it makes lots of calls to that function, and
it's better to make the call explicitly through the symbol, and that is
indeed with (funcall <symbol> ...).
#:Erik
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* ················@hybrid.fi
>| Don't remember any more if funcall 'foobar is legal, sigh has been
>| programming for my bad luck with C/C++ for last 6 years.
>
> calls to global functions always go through the symbol-function slot of
> the symbol, anyway. only if you capture the functional value of a symbol
> in a local binding (such as an argument to a function) will you avoid
> this lookup at every call. (long-lived-thing #'function-that-may-change)
> is thus not a good idea if it makes lots of calls to that function, and
> it's better to make the call explicitly through the symbol, and that is
> indeed with (funcall <symbol> ...).
This is precisely the reason I gave when I successfully lobbied X3J13 to
retain the ability to use symbols as arguments to FUNCALL and APPLY (I
think it was the FUNCTION-TYPE cleanup issue). Often a long-lived data
structure will contain references to functions (especially prior to CLOS,
when a way to get OO-like behavior was to create structures whose slots
referred to functions); if you need to be able to patch running systems on
the fly (e.g. on Lisp Machines, where the Lisp image is always running) and
have these references automatically pick up the changes, they should
contain the function name rather than the function object itself.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
················@hybrid.fi writes:
> > On the other hand, if you are updating functions whose signatures have
> > changed, and other functions which call those functions, you have to
> > be careful that they all get updated together. This might require some
> > effort on the part of the programmer to ensure.
>
> U see the point. Think about maybe 20 threads executing one at a time. Y
> do a change to some of the functions in runtime, so that the behaviour
> of the functions change a little bit, not too much, maybe. Some quite
> weird things can happen, when u call function like(funcall 'foobar
> (symbol-function 'foobar) #'foobar (symbol-function 'foobar)).
> What happens if some of the threads change the value-cell for
> symbol-function between the evaluation of function arguments.....
If the only problem you have is to make the change to the symbol-function
slot of a symbol atomic, then any seriously threaded Lisp implementation
will do this for you, already.
But of course Lisp can't solve all of your problems for you automatically:
If you have to change a number of functions (and/or data-structures) at
once (because they have are part of an interlocking change set), you will
have to take care that this happens in the correct order at the correct
time. While Lisp can help you deal with this, it cannot do it on it's
own (that would probably involve solving the halting-problem and/or be
AI-complete ;).
But on the whole this is often not that difficult to do. Depending on
your requirements, a simple (without-interrupts (do-all-updates ...))
(or the equivalent in your MP-implementation) might suffice. Or you
would implement natural synchronisation points in your threads, that
would give you the opportunity to make orderly changes. If OTOH you
require hard-real time responses from your system even during upgrade
operations, you might have to invest a bit more brain-power to do it
right. But this is language-independend.
What remains is that CL makes the underlying machinery much more
managable. And this is IMHO even more important when changing
data-structures dynamically, where C/C++ not only gives you no
support whatsoever, it actively makes this fairly impossible to do
without loosing lots of hair.
With CL, apart from synchronisation issues, I can simply define
update-for-*-class methods, then load the new class definitions, and
the datastructures will be updated transparently (either lazily or
eagerly, depending on circumstances). Finally you can remove the
update methods, and you are done (in reality this can get a bit more
involved, but it's still easily doable). With C++ this would involve
very ugly hacks with dynamic loading, structure hacking and much
duplicated code and data, while being heavily non-portable.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* ················@hybrid.fi
| How in earth one could get this to work. Hmm... Sounds suspicous.
this is what professional Common Lisp programmers leave to their vendors,
then we pay them to make sure that it works and that they continue to be
in business so we are, too, and then we never ever worry about it, again,
but rather think it's the greatest thing, and if we are in the mood and
not yet tired of it, snicker at C-based life forms who run around scared.
| If the function calls goes by symbol value cell instead the linker label,
| the problem is even worse.
really? could you elaborate on this for us? :)
#:Erik
On Sun, 31 Oct 1999 08:35:55 +0100, "Janos Blazi" <······@netsurf.de>
wrote:
> But the factory is most likely having a software house maintain their
> software and I can imagine (if the software house were SIEMENS for example)
> that the quality assurance guys would not like the idea that programs are
> being modified while they are running, as it may be very difficult to
> monitor this process from QA's point of view.
It seems that even C++ folks feel the need for dynamic class redefinition.
See for example:
"Dynamic C++ Classes - How do you upgrade parts of a running system
without shutting it down? Very carefully"
Rober S. Gray, Gi'sli Hja'lmty'sson
[i' : "i" with an acute accent, etc.]
C/C++ Users Journal - vol. 17, n. 10, October 1999
source code available at:
http://www.research.att.com/~gisli/dynamic
ftp://actcomm.dartmouth.edu/dynamic/
I guess they reinvent most of the built in CLOS redefinition machinery. By
the way, the applications for AT&T that motivate this need look like those
SIEMENS would develop.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Janos Blazi <······@netsurf.de> wrote in message
··································@broadway.news.is-europe.net...
> I do not quite understand how that would work out in real life.
> But the factory is most likely having a software house maintain their
> software and I can imagine (if the software house were SIEMENS for
example)
> that the quality assurance guys would not like the idea that programs are
> being modified while they are running, as it may be very difficult to
> monitor this process from QA's point of view.
>
Such thing as continious technological process (or whatever it called in
English) does exists. Basically it means that you *can't* stop the
production for upgrade, and ability to improve/correct software at run time
will definitely make life easier for such cases. Steel production, nuclear
plant control and some chemical processes are good examples. It could be
also applicable for some military/space applications, where you can't just
cut off the system to reinstall software.
--
Eugene.
Tim Bradshaw <···@tfeb.org> writes:
> * Christopher R Barry wrote:
>
> > It is actually done. If not, then what's all this
> > UPDATE-INSTANCE-FOR-(REDEFINED|CHANGED)-CLASS stuff and its kin about?
>
> I think this is quite a `weak' form of self-modification in the sense
> that most of what goes on is (presumably) simply loading / compiling
> some new code into memory, and then clobbering a few function pointers
> to point at this new stuff. I'd be surprised if many implementations
> actually alter the executable code of functions in place, which is a
> horrible nightmare on any modern CPU I should think (caching
> issues...). And I think that latter thing -- in place hacking of
> executable code -- is what people usually mean by `self-modification'.
Caching is not the issue at all. Every time a codevector is moved the
cache must be flushed. Some architectures allow this to be done on a
cache-line basis (not disturbing any of the cache except for the actual
memory being flushed). The uniqness of lisp comes from the very fact
that code can be constructed in data space and executed (it is possible
to do so in C, but fairly tedeous, and you don't get any help from the
compiler, so you are really doing the work in machine language, which
is even lower-level than assembler).
Other than code-vector movement, there were two examples in Allegro's
history of self-modification of the actual contents of code vectors.
One was on the Cray (X-MP, Y-MP, and Cray2), due to its instruction
set; it had no pc-relative jump instructions. So every time a code
vector moved, all jumps within it had to be relocated.
Pretty low-level stuff:
The second came also on the Cray, at the advice of those German
developers who had put PSL on the Cray earlier, and then I ported it
to the rs/6000 for a time. The advice was, in general: "If you want
speed out of the Cray, you stay away from two things: never jump,
and never read from memory". This was serious advice, due to the
extreme difference between the instruction cycle time and jumps or
reads from memory (normal instructions took one cycle, but jumps took
7 to 15 cycles, and reads took 20 to 50 cycles). So for lisp, which
does a lot of interlocked reads, the performance could get abysmal.
The answer was to force symbols, once they were tenured, to remain in
one place for the rest of their lives, and to change the calling sequence
for calls through those symbols so that the symbol addresses were
actually built by the code, rather than grabbed from a function constant
vector. The reason why this was faster was that it took one less read
from memory, and the symbol's function object could be accessed immediately.
This was pretty hairy underpinnings, but it worked for both the cray and
for the rs/6000. What finally killed it was the fact that once a code
vector is modified by this action, it cannot be shared with any other
functions, because it is referencing hard-coded memory addresses. For
other ports, which always used relative offsets to access data, we had
discovered that a huge number of codevectors could be shared. For example,
try disassembling (defun foo (x) (bar x)) and (defun bas (x) (bam x))
on any Allegro, and comparing the hex values in the left-hand side of
the disassembler output). So we had a code-vector explosion on the rs6000
and decided to go back to the non-self-modifying approach.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
* Duane Rettig wrote:
> Caching is not the issue at all. Every time a codevector is moved the
> cache must be flushed. Some architectures allow this to be done on a
> cache-line basis (not disturbing any of the cache except for the actual
> memory being flushed).
I think I was being confusing (as well as probably confused!). What I
meant was that in the Lisp case that is most common (I can't say the
common Lisp case here...), you execute some millions of instructions
to take a bit of source and construct some executable code, and then
you install it (and flush the cache). This is self-modification,
sure, but it doesn't really compare with doing some trick involving
altering a literal value in the code every time through a loop, which
is what I tend to think of as self-modifying code, and would either
not work or require cache flushes maybe hundreds of thousands of times
more frequent than the former case.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> * Duane Rettig wrote:
>
> > Caching is not the issue at all. Every time a codevector is moved the
> > cache must be flushed. Some architectures allow this to be done on a
> > cache-line basis (not disturbing any of the cache except for the actual
> > memory being flushed).
>
> I think I was being confusing (as well as probably confused!). What I
I don't think so; I understood it (perhaps I am confused with you?-)
> meant was that in the Lisp case that is most common (I can't say the
> common Lisp case here...), you execute some millions of instructions
> to take a bit of source and construct some executable code, and then
> you install it (and flush the cache). This is self-modification,
> sure, but it doesn't really compare with doing some trick involving
> altering a literal value in the code every time through a loop, which
> is what I tend to think of as self-modifying code, and would either
> not work or require cache flushes maybe hundreds of thousands of times
> more frequent than the former case.
It depends on what you consider "self-modifying". In most modern
operating systems, the late-binding of addresses for relocation
purposes can be considered a form of self-modification. How do
they "modify" constants in code at load-time without touching
text (read-only executable) space? They arrange the compilation
of the code to reference the constant indirectly, through data space.
[This is done more often with "PIC" (position-independent code)
than with "relocatable code", where the modifications are sometimes
done directly to the code at load/relocate time just before the
O/S makes the text space read-only; But here I'm describing PIC code.]
Thus, modification of this constant is simple, even for a renegade
"self-modifying" code sequence (though obviously unadvisable,
because of the assumptions made by the combination of the language,
calling sequence, and the operatiing system, which if touched might
make the program fall apart in some way).
The whole concept of self-modifying code is little understood
nowadays, because it is "taboo". And yet, it amounts to little
more than treating data and code interchangeably. Modern machine
architectures and operating systems have consistently provided as
much separation of text (code) space and data space as possible,
and most programming languages have completely ignored the concept
of treating code as data. Only assembler languages and some lisp-like
languages support the concept. Perhaps this is one of the reasons
why it is so hard to explain what is so great about lisp to non-lisp
programmers; we don't have a CS vocabulary for it, and when we
start explaining it in simpler terms, the listener suddenly says:
"That looks like self-modifying code" and turns us off, because
we are entering a taboo area of discussion.
An example: What is the real difference between expanding a macro
in C and in Common Lisp? Answer: In C, the compiler does all of
the work; the resulting expanded code is in the form of text, and
there is no run-time possibility of modification of the code.
In other words, the code is treated as code, and never data.
Even "parameters" in the macroexpansion are compile-time constants
and not data. In Common Lisp, the macro expands into a piece of
data, not at compile-time, but at macroexpand time (a separate
time segment that can be either part of a compilation process or
an evaluation process, or else completely alone) and the resulting
data that represents a program can either be treated as a program,
either by compiling it or evaluating it, or it can be treated as
data, because that is what it is.
Of course, this is all old news to lispers, and may even be boring,
but it is extremely relevant because it is a simple example of
self-modifying code.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> wrote:
+---------------
| ... most programming languages have completely ignored the concept
| of treating code as data. Only assembler languages and some lisp-like
| languages support the concept.
...
| An example: What is the real difference between expanding a macro
| in C and in Common Lisp? Answer: In C, the compiler does all of
| the work; the resulting expanded code is in the form of text, and
| there is no run-time possibility of modification of the code.
| In other words, the code is treated as code, and never data.
+---------------
Another similarity between Lisp & *older* assemblers such as MACRO-10
on the PDP-10 (not the brain-dead modern assemblers that are little more
than backends for C) is that they had extensive [I'd say "Turing-complete",
except for the expected flamage!] programmability during the expansion
process. MACRO-10 was especially nice, since you could store "state" in
assembly-time variables *and* mutate it later. You could do arithmetic,
do numerically-controlled loops, loops over arguments, loops over
*characters* of arguments, unfold nested structure in arguments,
convert numbers to string, contruct new assembly-time variables by
concatenation, and then store into and mutate *those*, etc.
I think I have written here before about some macros I used circa 1971
(in the FOCAL-10 interpreter, a port of PDP-8 FOCAL/F to the PDP-10)
to incrementally declare table-lookup "bit strips" for lexical parsing,
then drop the filled-in packed tables at the end of the program.
Yes, Lisp macros are nicer still (the "bit strip" stuff would be trivial),
but those older assemblers *were* something to write home about... ;-} ;-}
-Rob
-----
Rob Warnock, 8L-846 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Barry Margolin <······@bbnplanet.com> writes:
>
> In article <·································@broadway.news.is-europe.net>,
> Janos Blazi <······@netsurf.de> wrote:
> >I read about LISP programs' ability to modify themselves in several books
> >but I did not understand it.
>
> Don't worry about it, since it's never actually done. It's possible in
> interpreted implementations, but most serious applications are compiled,
> and this ability is severely limited.
I'm not sure if we have the same understanding of what "ability to
modify themselves" means. I can't see why the question about compiled
or interpreted evaluation has anything to do with this consept.
Here is an excample of what I consider selfmodifying:
(let ((greatest nil))
(defun greatest (number)
(setf (symbol-function 'greatest)
(lambda (new)
(when (> new greatest)
(setq greatest new))
greatest))
(setq greatest number)))
If you compile this, the symbol-function of greatest will be a
compiled function at all times.
Oluf
* Asle Olufsen wrote:
> Here is an excample of what I consider selfmodifying:
> (let ((greatest nil))
> (defun greatest (number)
> (setf (symbol-function 'greatest)
> (lambda (new)
> (when (> new greatest)
> (setq greatest new))
> greatest))
> (setq greatest number)))
I suppose this is legal CL (?), but it's certainly horrible! It can
also (probably?) go spectacularly wrong in cases like this:
(let ((g #'greatest))
(list (greatest 12)
(funcall g 0)
(greatest 0)))
This does the same trick in a much clearer way:
(let ((greatest nil))
(defun greatest (r)
(setf greatest
(if (null greatest)
r
(max greatest r)))
greatest))
--tim
* William Deakin wrote:
> Asle Olufsen wrote:
>> Ok. I could use a method instead:
> Why?
Because redefining the method doesn't make a new (generic) function
object, it just adds the method to it:
(defgeneric foo (x))
(defmethod foo (x)
x)
Then this:
(let ((foo #'foo))
(defmethod foo (x)
(cons x nil))
(eq #'foo foo))
is true.
This isn't the case (or, perhaps, may not be the case, I think it
might be true on Genera) for ordinary functions.
--tim
William Deakin <·····@pindar.com> writes:
>
> Asle Olufsen wrote:
>
> > Ok. I could use a method instead:
>
> Why?
Two reasons. One was to avoid the problem of the "self-modifying"
code if #' is used. But since the point of doing it in the first
place was to do an extremely marginal optimization by removing an if,
it then becomes silly to use defmethod.
The other reason was to show that a problem I have encountered with #'
can be solved by useing defmethod insted of defun. If i use #'foo in
my code and foo is defined with defun, and i decide to change the
definition of foo it doesn't help to load the new definition. I must
also load all files containing #'foo in them (and if it is in a macro
all files useing the macro). But if I had used defmethod instead and
just loaded the new definition all the #'foo's would automatically use
the new definition.
Oluf
In article <··············@opus.nextel.no>,
Asle Olufsen <···@opus.nextel.no> wrote:
>I'm not sure if we have the same understanding of what "ability to
>modify themselves" means. I can't see why the question about compiled
>or interpreted evaluation has anything to do with this consept.
>
>Here is an excample of what I consider selfmodifying:
>
>(let ((greatest nil))
> (defun greatest (number)
> (setf (symbol-function 'greatest)
> (lambda (new)
> (when (> new greatest)
> (setq greatest new))
> greatest))
> (setq greatest number)))
>
>If you compile this, the symbol-function of greatest will be a
>compiled function at all times.
I wouldn't call that selfmodifying _code_ because it
is just changing the binding of a variable, which any
imperative language allows. But push what you have
into the setup text inside a Lisp macro
body and you get code that truly changes itself. Here
is an example which I believe is due to D. P.
Friedman:
(defmacro once (e)
(let ((once-fn (let ((changeable '*))
(setq changeable
#'(lambda (thunk)
(let ((v (funcall thunk)))
(setq changeable #'(lambda (thunk) v))
v)))
#'(lambda (thunk) (funcall changeable thunk)))))
`(funcall ',once-fn #'(lambda () ,e))))
(defun niche (hopeful)
(once hopeful))
(niche 'kilroy) => kilroy
niche returns kilroy for every subsequent call:
(niche 'al) => kilroy
(niche 'bill) => kilroy
(niche 'george) => kilroy
(niche 'john) => kilroy
--d
····@roger.gte.com (Dorai Sitaram) writes:
> Here is an example which I believe is due to D. P.
> Friedman:
>
> (defmacro once (e)
> (let ((once-fn (let ((changeable '*))
> (setq changeable
> #'(lambda (thunk)
> (let ((v (funcall thunk)))
> (setq changeable #'(lambda (thunk) v))
> v)))
> #'(lambda (thunk) (funcall changeable thunk)))))
> `(funcall ',once-fn #'(lambda () ,e))))
>
> (defun niche (hopeful)
> (once hopeful))
>
> (niche 'kilroy) => kilroy
>
> niche returns kilroy for every subsequent call:
>
> (niche 'al) => kilroy
> (niche 'bill) => kilroy
> (niche 'george) => kilroy
> (niche 'john) => kilroy
Doesn't this depend on the "(once hopeful)" macro call being expanded
only once? In some CL interpreters, it would be expanded each time
niche was called.
Anyway ... does anyone have a once / once-only trick that works
despite the possibility of macro-call-re-expansion?
-- jeff
In article <··············@todday.aiai.ed.ac.uk>,
Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote:
>····@roger.gte.com (Dorai Sitaram) writes:
>
>> Here is an example which I believe is due to D. P.
>> Friedman:
>>
>> (defmacro once (e) [...]
>>
>> (defun niche (hopeful)
>> (once hopeful))
>>
>> (niche 'kilroy) => kilroy
>>
>> niche returns kilroy for every subsequent call:
>>
>> (niche 'al) => kilroy
>> (niche 'bill) => kilroy
>> (niche 'george) => kilroy
>> (niche 'john) => kilroy
>
>Doesn't this depend on the "(once hopeful)" macro call being expanded
>only once? In some CL interpreters, it would be expanded each time
>niche was called.
I can't quote chapter and verse, but I think the
CL spec doesn't allow this sort of ambiguity.
>Anyway ... does anyone have a once / once-only trick that works
>despite the possibility of macro-call-re-expansion?
If there is a different solution (I don't think there
is, but maybe you can do something with CL's
read-macros), I'd like to hear of it.
--d
····@bunny.gte.com (Dorai Sitaram) writes:
> >Doesn't this depend on the "(once hopeful)" macro call being expanded
> >only once? In some CL interpreters, it would be expanded each time
> >niche was called.
>
> I can't quote chapter and verse, but I think the
> CL spec doesn't allow this sort of ambiguity.
I'm pretty sure it does. At least, it used to be allowed; and I don't
recall it being changed by x3j13. Let me have a quick look ...
"Minimal compilation" ensures that macro calls are expanded "in such a
way that they will not be expanded again at run time". But that's
part of the compilation semantics (section 3.2.2), not the interpreter
semantics. So that already suggests that the rules for interpreters
are different, and I haven't found anything elsewhere that suggests
macros must be expanded only once.
Now, you could use *macroexpand-hook* to arrange for expansion caching
of some sort, and in the old days "displacing" (which modified the
macro call itself) was often used. But I'm not sure you can get the
right semantics using *macroexpand-hook*, and nowadays
The consequences are undefined if a macro function destructively
modifies any part of its form argument. [3.1.2.1.2.2 Macro Forms]
How about using compile to get the effects of "minimal compilation"?
Sorry, but
The consequences are undefined if the lexical environment
surrounding the function to be compiled contains any bindings other
than those for macros, symbol macros, or declarations.
[Function COMPILE]
And in any case, each time a call to your macro-that-calls-compile
is expanded, it will call compile again, unless you've already solved
the caching problem, in which case you can just use that solution
more directly.
So it looks like to have to work from the top level, by defining a
variant of defun that preprocesses its body so as to expand all macro
calls (or at least the eval-once forms).
> >Anyway ... does anyone have a once / once-only trick that works
> >despite the possibility of macro-call-re-expansion?
>
> If there is a different solution (I don't think there
> is, but maybe you can do something with CL's
> read-macros), I'd like to hear of it.
load-time-value seems a promising way to provide a basis for an
eval-once macro. This kind of thing was discussed in connection with
load-time-value during standardization, but I don't remember whether
or not load-time-value ended up being defined in the right way.
But I think the answer is "no".
So Algol 60 "own" still rules!
-- jd
From: Dorai Sitaram
Subject: Re: Macro to ensure a form is evaluated only once
Date:
Message-ID: <7vvj60$dv8$1@news.gte.com>
In article <·················@todday.aiai.ed.ac.uk>,
Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote:
>····@bunny.gte.com (Dorai Sitaram) writes:
>>Jeff wrote:
>> >Doesn't this depend on the "(once hopeful)" macro call being expanded
>> >only once? In some CL interpreters, it would be expanded each time
>> >niche was called.
>>
>> I can't quote chapter and verse, but I think the
>> CL spec doesn't allow this sort of ambiguity.
>
>I'm pretty sure it does. At least, it used to be allowed; and I don't
>recall it being changed by x3j13. Let me have a quick look ...
>
>"Minimal compilation" ensures that macro calls are expanded "in such a
>way that they will not be expanded again at run time". But that's
>part of the compilation semantics (section 3.2.2), not the interpreter
>semantics. So that already suggests that the rules for interpreters
>are different, and I haven't found anything elsewhere that suggests
>macros must be expanded only once.
You're right. I'm still very surprised that this
particular ambiguity may be allowed, but the
text I had in mind turns out not to be as strong as I
thought it was (sec. 26.1):
# evaluation n. a model whereby forms are executed,
# returning zero or more values. Such execution might be
# implemented directly in one step by an interpreter or
# in two steps by first compiling the form and then
# executing the compiled code; this choice is dependent
# both on context and the nature of the implementation,
# but in any case is not in general detectable by any
# program. The evaluation model is designed in such a
# way that a conforming implementation might legitimately
# have only a compiler and no interpreter, or vice versa.
>So Algol 60 "own" still rules!
Amen. Incidentally, the "once" I mentioned is
strictly weaker than "own". It is possible to define
"own" de-facto portably in the usual CLs (i.e., the
ones that expand their macro calls only once) in a
manner analogous to "once". However, it is not
possible to define "own" as a purely syntactic
rearrangement using "once". (The reason's got to do
with the fact that "once" associates a value with a
piece of text, whereas "own" associates a
(mutable) binding, which is more information.)
--d
In article <·················@burlma1-snr2>,
Barry Margolin <······@bbnplanet.com> wrote:
> In article
<·································@broadway.news.is-europe.net>,
> Janos Blazi <······@netsurf.de> wrote:
> >I read about LISP programs' ability to modify themselves in several
books
> >but I did not understand it.
>
> Don't worry about it, since it's never actually done. It's possible
in
> interpreted implementations, but most serious applications are
compiled,
> and this ability is severely limited.
Not necessarily, one could use dlclose dlopen dlsym kind of approach,
and it would probably even work..
(recompile the whole shlib containing the modified code & reload it)
Could be quite slow ...
PKY
> --
> Barry Margolin, ······@bbnplanet.com
> GTE Internetworking, Powered by BBN, Burlington, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to
newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to
the group.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
················@hybrid.fi writes:
> In article <·················@burlma1-snr2>,
> Barry Margolin <······@bbnplanet.com> wrote:
> > In article
> <·································@broadway.news.is-europe.net>,
> > Janos Blazi <······@netsurf.de> wrote:
> > >I read about LISP programs' ability to modify themselves in several
> books
> > >but I did not understand it.
> >
> > Don't worry about it, since it's never actually done. It's possible
> in
> > interpreted implementations, but most serious applications are
> compiled,
> > and this ability is severely limited.
>
> Not necessarily, one could use dlclose dlopen dlsym kind of approach,
> and it would probably even work..
> (recompile the whole shlib containing the modified code & reload it)
Yes, this is possible, but be sure to understand what you are
recommending. The dlopen() function (or shl_load(), on HP, or
LoadLibrary() on Windows) is primarily for dynamically loading
whole libraries at a time, with specific functional interfaces
that are considered "foreign" to lisp. Usually these interfaces
have a counterpart on the lisp side, called a foreign-function
interface.
In Allegro CL, if you create a C library called mylib1.so, with
C functions foo(), bar(), and bas(), you might on the lisp side
say
(ff:def-foreign-call foo ())
(ff:def-foreign-call bar ())
(ff:def-foreign-call bas ())
to define lisp counterparts to these functions that do "the right
thing". Of course, if you tried to call any of them before loading
mylib1.so, they would not be connected to any real functions and
would give you an error message, just like trying to call an
undefined lisp function from another lisp function. But as soon as
you load mylib.so, as in
(load "mylib1.so")
which incidentally uses dlopen on systems that define it, the lisp
foreign-calls are bound to the C entry points in the library, and
calling the lisp definition automatically calls the C function.
Furthermore, you could define a completely different set of foo(),
bar(), and bas() functions in a different library, say mylib2.so, and
when you load that file, the definitions are relinked to the newly
loaded library. In this way you can change "personalities" of
libraries for various purposes. One example of this might be a more
careful but slow version of a library that is loaded in during
development, and a production version (i.e. faster, less runtime
checking) is loaded in when the program is solid. None of
this requires that you stop the lisp program.
> Could be quite slow ...
Yes, it is slow. But then again, I usually recommend that dynamic
redefinition in lisp be done on lisp functions. When you dynamically
redefine non-lisp functions, you pay a price.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
This is probably not relevant but since the title is C++ and not C...
If you try to dynamically load functions defined from C++ into a library,
lib.c++.so.1 say, you can be on to a loser. To enable C++ to overload
functions by operator type the name of the function is munged. You can work
out what these names are (using some name dumping tool like nm or something)
but be careful out there.
My final caveat is, I have only tried this on AIX, Solariss (2.4+) and
Linux, but this may not be true of other OS's.
Best Regards,
:) will
In article <·················@pindar.com>,
········@pindar.com wrote:
> This is probably not relevant but since the title is C++ and not C...
>
> If you try to dynamically load functions defined from C++ into a
library,
> lib.c++.so.1 say, you can be on to a loser. To enable C++ to overload
> functions by operator type the name of the function is munged. You can
work
> out what these names are (using some name dumping tool like nm or
something)
> but be careful out there.
Sigh, this is really pain in the neck in C++, among other things.
I remember using first versions of java with externa function call
mechanism and C++ together, so java could call C++ and vica versa, took
a little bit time to debug...
PKY
>
> My final caveat is, I have only tried this on AIX, Solariss (2.4+) and
> Linux, but this may not be true of other OS's.
>
> Best Regards,
>
> :) will
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
················@hybrid.fi wrote:
> Sigh, this is really pain in the neck in C++, among other things. I
> remember using first versions of java with externa function call mechanism
> and C++ together, so java could call C++ and vica versa, took a little bit
> time to debug...
I'm sure it did. It's not like there is a naming convention or anything.
Each OS or compiler has its own trick to work out which function is which.
hmmm. The obvious answer is to program in Lisp!
Best Regards,
:) will
From: Russell Wallace
Subject: Re: LISP and C++
Date:
Message-ID: <38246165.3870@iol.ie>
William Deakin wrote:
>
> This is probably not relevant but since the title is C++ and not C...
>
> If you try to dynamically load functions defined from C++ into a library,
> lib.c++.so.1 say, you can be on to a loser. To enable C++ to overload
> functions by operator type the name of the function is munged. You can work
> out what these names are (using some name dumping tool like nm or something)
> but be careful out there.
Use extern "C" on the functions you want to export. That turns off the
name mangling for those particular functions.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
········@iol.ie
Russell wrote:
> Use extern "C" on the functions you want to export. That turns off
the name mangling for those particular functions.
(Will sighs audibly). Yes, that is perfectly correct. I just wonder if
it is in the spirit of C++? ;)
Best Regards,
:) will
Sent via Deja.com http://www.deja.com/
Before you buy.
In article <············@nnrp1.deja.com>,
Will Deakin <········@pindar.com> wrote:
> Russell wrote:
> > Use extern "C" on the functions you want to export. That turns off
> the name mangling for those particular functions.
>
> (Will sighs audibly). Yes, that is perfectly correct. I just wonder if
> it is in the spirit of C++? ;)
Very much incorrected indeed.
Thing about functions
void format(char *buf, const char* formatString, ...);
and
void format(const char* diskSpec);
Which one u will call after extern "C" decl ; ;-)
PKY
>
> Best Regards,
>
> :) will
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Russell Wallace
Subject: Re: LISP and C++
Date:
Message-ID: <382925B0.3E49@iol.ie>
················@hybrid.fi wrote:
>
> In article <············@nnrp1.deja.com>,
> Will Deakin <········@pindar.com> wrote:
> > Russell wrote:
> > > Use extern "C" on the functions you want to export. That turns off
> > the name mangling for those particular functions.
> >
> > (Will sighs audibly). Yes, that is perfectly correct. I just wonder if
> > it is in the spirit of C++? ;)
It's entirely in the spirit of C++. One of the primary design
objectives of the language was ease of interoperability with other
languages.
> void format(char *buf, const char* formatString, ...);
> and
> void format(const char* diskSpec);
>
> Which one u will call after extern "C" decl ; ;-)
Obviously, you can't use name overloading on extern "C" functions.
Since there should only be a few of these, this is not a significant
problem in practice.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
········@iol.ie
It is a bit difficult to add assembly langauge subroutines if you do not use
the extern "C" declaration. But name mangling can be done manually too, in
theory at least. And it is very much in the spirit of C++ as you take C++
FOR RAW SPEED and nothing else.
Janos Blazi
Russell Wallace <········@iol.ie> schrieb in im Newsbeitrag:
·············@iol.ie...
> ················@hybrid.fi wrote:
> >
> > In article <············@nnrp1.deja.com>,
> > Will Deakin <········@pindar.com> wrote:
> > > Russell wrote:
> > > > Use extern "C" on the functions you want to export. That turns off
> > > the name mangling for those particular functions.
> > >
> > > (Will sighs audibly). Yes, that is perfectly correct. I just wonder if
> > > it is in the spirit of C++? ;)
>
> It's entirely in the spirit of C++. One of the primary design
> objectives of the language was ease of interoperability with other
> languages.
>
> > void format(char *buf, const char* formatString, ...);
> > and
> > void format(const char* diskSpec);
> >
> > Which one u will call after extern "C" decl ; ;-)
>
> Obviously, you can't use name overloading on extern "C" functions.
> Since there should only be a few of these, this is not a significant
> problem in practice.
>
> --
> "To summarize the summary of the summary: people are a problem."
> Russell Wallace
> ········@iol.ie
Janos Blazi wrote:
> ...you take C++ FOR RAW SPEED and nothing else.
I thought for RAW SPEED you would dispense with this high-level language rubbish
and write in assember ;)
Best Regards,
:) will
C was a comfortable assembler when it was created. I remember in the
eighties we used hardware debuggers at Siemens and the debugger showed you
disassembled code and it was extremely easy to map this to your C code: it
was virtualy a very simple bijektive mapping.
Janos B.
William Deakin <·····@pindar.com> schrieb in im Newsbeitrag:
·················@pindar.com...
> Janos Blazi wrote:
>
> > ...you take C++ FOR RAW SPEED and nothing else.
>
> I thought for RAW SPEED you would dispense with this high-level language
rubbish
> and write in assember ;)
>
> Best Regards,
>
> :) will
>
>
Janos Blazi wrote:
> C was a comfortable assembler
Hmmm. Like leather chairs in a gentlemans club? or the taste of willow on
leather and the sound of cucumber sandwiches on a fine summers afternoon?
> I remember in the eighties we used hardware debuggers at Siemens and the
> debugger showed you disassembled code and it was extremely easy to map this
> to your C code: it was virtualy a very simple bijektive mapping.
But was it -->---vroooom-->-- and what has this to do with c++?
Best Regards,
:) will
Urban Reinhard <······@sbox.tu-graz.ac.at> writes:
> e.g. to support a dynamic c++ ffi. most popular desktop apps nowadays
> are c++ based
> (office, acad, ...) and it would be nice to call them even if they don't
> provide libs or offer com/corba support.
The BeOS operating system has a C++ API for most of the system. Only a
few of the kernel functions are in C. To create GUI Apps using Lisp
you'd need to be able to call C++ objects/methods or create wrapper C
functions for the API. I currently use the wrapper C method when using
Gwydion Dylan under BeOS and it's a pain creating all those wrappers.
Are there any Lisps that integrate nicely with foreign C++ code?
Chris.
Marius Vollmer <···@zagadka.ping.de> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Note that the way I worded my version of the question doesn't rule
> > out the possibly interesting specialization of that question: "Are
> > there any pairs of different C++ implementations which integrate
> > nicely with each other?"
>
> Hmm, what about Lisps? How well do different Lisp implementations
> play together? Is that even an issue, given Lisps fundamental
> different way of life?
I don't know of anyone who has tried it, but I don't see any reason
why two different Lisps, each with foreign calling and callback
capabilities, couldn't coexist in the same process and call each
other.
"But", you might say, "how is this different from two C++
implementations coexisting and calling each other through
`extern "C"' declarations?" That is _precisely_ my point: this
thread has been dealing with some people's dissatisfaction with
the idea that to communicate with C++ one must use a lower level
interface than C++ could otherwise handle. All I am saying is
that this is a normal concept and that C (not C++) is the nominal
basis for inter-language communication.
In fact, whenever you look at architecture manuals, they usually
contain or are accompanied by a "standard calling convention"
specification, which allows different lanugages to communicate
with each other. These calling conventions are sometimes referred
to by their more-appropriate title: "standard C calling convention".
Usually the higher-level languages add things to this convention
that precludes it from being standardly used (or at least which makes
it harder); for example, name mangling in C++ or &optional, &rest,
and &key arguments in Common Lisp.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
> "But", you might say, "how is this different from two C++ implementations
> coexisting and calling each other through `extern "C"' declarations?"
> That is _precisely_ my point: this thread has been dealing with some
> people's dissatisfaction with the idea that to communicate with C++ one
> must use a lower level interface than C++ could otherwise handle.
Thank you for saying this more clearly than I could. As one of those who is
(or hope was seen as being) dissatified when I posting earlier in this
thread. Yes. You either use C calling convention for C++, and lose 50% of
the reason why I program in C++ and not C or wrestle with some ugly
non-readable names, just beggers belief. Ugly, ugly and more ugly.
People have suggested ways round this, using trampoline code, for example,
some of which are moderately elegant. But I am of a mind so as not to be
persuaded other than that this a type of the lowest form of hackery and
kludge.
Best Regards,
:) will
* William Deakin <·····@pindar.com>
| Yes. You either use C calling convention for C++, and lose 50% of the
| reason why I program in C++ and not C or wrestle with some ugly
| non-readable names, just beggers belief. Ugly, ugly and more ugly.
but it's C++ that is being ugly in this situation -- we're just trying to
cope. had the proverbial They standardized their name mangling, nobody
would have needed to know about it, and just about anybody could use a
name that wasn't mangled, but instead some longer form that would contain
the same information. neither beauty nor elegance of design are part of
the reason people use C++, so this will never win an argument. and C++
people are forever mired in a conflation of representation and value. I
was predictably horrified to read that Bjarne suggests that people use
_different_ name mangling schemes. the shock, the pain. :)
| People have suggested ways round this, using trampoline code, for example,
| some of which are moderately elegant. But I am of a mind so as not to be
| persuaded other than that this a type of the lowest form of hackery and
| kludge.
but shirk not from necessity hoping that it would thereby resolve itself.
C++ compiler vendors should make an effort to interface with Common Lisp.
after all, they have the stuff people claim to want to talk to, and C++
is at fault for being badly standardized. so go talk to the guys who
made up this stupid problem in the first place.
#:Erik
--
Attention Microsoft Shoppers! MS Monopoly Money 6.0 are now worthless.
Duane Rettig <·····@franz.com> wrote in message
··················@beta.franz.com...
> Chris Double <·····@double.co.nz> writes:
>
> > Urban Reinhard <······@sbox.tu-graz.ac.at> writes:
> >
> > > e.g. to support a dynamic c++ ffi. most popular desktop apps nowadays
> > > are c++ based
> > > (office, acad, ...) and it would be nice to call them even if they
don't
> > > provide libs or offer com/corba support.
> >
> > The BeOS operating system has a C++ API for most of the system. Only a
> > few of the kernel functions are in C. To create GUI Apps using Lisp
> > you'd need to be able to call C++ objects/methods or create wrapper C
> > functions for the API. I currently use the wrapper C method when using
> > Gwydion Dylan under BeOS and it's a pain creating all those wrappers.
> >
> > Are there any Lisps that integrate nicely with foreign C++ code?
>
> C++ name mangling is a real problem because it is fundamental to
> the language but, as far as I know, not yet standardized. Perhaps
> a more general statement of this question might be "Are there any
> languages that integrate nicely with C++ code?"
Actually you don't need to know anything about C++ name mangling to do a
portable version of C++ integration. I've done it twice now with my
ex-colleagues from Ilog, once for Ilog Talk (a Lisp) and once for Java
(TwinPeaks).
What you do need, however, is a C++ header file parser. Assuming you have
such a beast that can give you a complete representation of a C++ library,
and assuming you know how C++ constructs are to map into the target
language, you can use the magic of extern "C" to avoid name mangling. Just
generate stubs with unique names (in other words, your own name mangling
scheme, if you like) and declare them extern "C". The stub bodies can call
any C++ code you like. For instance, take the following C++ code:
class Foo {
private:
int x;
public:
int getX();
};
You could generate the following stubs:
extern "C" int Foo_getX(Foo* f) {
return f->getX();
}
extern "C" Foo* Foo_new() {
return new Foo();
}
Then, in the target language that only supports a C FFI:
(defun-foreign Foo_getX (int) (pointer))
(defun-foreign Foo_new (pointer) ())
Also,
(define-c++-class Foo
(getX (int) ())
)
which expands into the appropriate stuff so you have nice Lisp names for the
C++ class API.
This all works, and the only real issue is that you're generating a few
extra intermediate functions between the original C++ code and the final
target language code. However, there are clever techniques for reducing the
number and size of these stubs that I don't care to go into right now.
There are also a number of interesting issues dealing with C++ language
construct mappings, such as GC integration, mapping callbacks (aka function
pointers) into the target language, handling inheritance (including multiple
and virtual inheritance), defining subclasses of C++ classes in the target
language, etc. etc. It's a fun project!
-- Harley
PS I've written a few articles about this whole subject, that I can refer
you too if you're interested in more detail.
"Harley Davis" <·············@nospam.museprime.com> writes:
>
> PS I've written a few articles about this whole subject, that I can refer
> you too if you're interested in more detail.
I'm interested. I was doing something similar for Gwydion Dylan on
BeOS and would be interested in your approach.
I wrote about the approach I took in a discussion on
comp.sys.be.programmer: http://www.deja.com/article/527799453
I would probably do something similar if using Lisp and would be
interested in other approaches.
For calling JNI (Java Native Interface) from Lisp (JNI uses a C++
vtable layout for dispatching) I used Corman Lisp. It has support for
calling through C++ vtables (via its COM wrappers). In this case I
didn't need any C wrappers, but I had to know the indexes into the
vtable, etc and put these index numbers explicitly in the Lisp code.
Chris.
--
http://www.double.co.nz/beos
Chris Double <·····@double.co.nz> wrote in message
···················@double.co.nz...
> "Harley Davis" <·············@nospam.museprime.com> writes:
>
> >
> > PS I've written a few articles about this whole subject, that I can
refer
> > you too if you're interested in more detail.
>
> I'm interested. I was doing something similar for Gwydion Dylan on
> BeOS and would be interested in your approach.
Here's a few references I could find easily:
http://info.acm.org/pubs/citations/proceedings/lfp/182409/p121-davis/
http://www.performance-computing.com/unixreview/backissu/9707/9707f1.htm
http://sunsite.doc.ic.ac.uk/public/packages/javarc/dev/misc/c++java/
-- Harley
On Wed, 17 Nov 1999 20:12:35 -0800, "Harley Davis"
<·············@nospam.museprime.com> wrote:
>PS I've written a few articles about this whole subject, that I can refer
>you too if you're interested in more detail.
Please do so. O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Duane Rettig <·····@franz.com> writes:
> C++ name mangling is a real problem because it is fundamental to
> the language but, as far as I know, not yet standardized. Perhaps
> a more general statement of this question might be "Are there any
> languages that integrate nicely with C++ code?"
This is indeed the right question. And the answer is "CORBA IDL". :)
...
> As an aside, at one time (before we concentrated our efforts on
> Corba) we looked into supporting Sun's JNI (Java Native Interface).
> This interface, ironically, uses a C++ convention
I don't quite agree with this. In what sense it follows a C++
convention?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti wrote:
> Duane Rettig <·····@franz.com> writes:
>
> > C++ name mangling is a real problem because it is fundamental to
> > the language but, as far as I know, not yet standardized. Perhaps
> > a more general statement of this question might be "Are there any
> > languages that integrate nicely with C++ code?"
>
> This is indeed the right question. And the answer is "CORBA IDL". :)
Please remark usage of _smiley_ in the above sentence.
--
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
"Fernando D. Mato Mira" <········@iname.com> writes:
> Marco Antoniotti wrote:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> > > C++ name mangling is a real problem because it is fundamental to
> > > the language but, as far as I know, not yet standardized. Perhaps
> > > a more general statement of this question might be "Are there any
> > > languages that integrate nicely with C++ code?"
> >
> > This is indeed the right question. And the answer is "CORBA IDL". :)
>
> Please remark usage of _smiley_ in the above sentence.
Well. It was intended :) But I also meant to be "serious". IMHO,
CORBA IDL is 'a' solution to the problem of C++ interoperability.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti wrote:
> "Fernando D. Mato Mira" <········@iname.com> writes:
>
> > Marco Antoniotti wrote:
> >
> > > Duane Rettig <·····@franz.com> writes:
> > >
> > > > C++ name mangling is a real problem because it is fundamental to
> > > > the language but, as far as I know, not yet standardized. Perhaps
> > > > a more general statement of this question might be "Are there any
> > > > languages that integrate nicely with C++ code?"
> > >
> > > This is indeed the right question. And the answer is "CORBA IDL". :)
> >
> > Please remark usage of _smiley_ in the above sentence.
>
> Well. It was intended :) But I also meant to be "serious". IMHO,
> CORBA IDL is 'a' solution to the problem of C++ interoperability.
Yeah. A solution for people for whom speed is not important.
Question: which tool does one use to automatically ORBify C++ libraries?
(with member templates and everything, of course).
Marco Antoniotti <·······@parades.rm.cnr.it> writes:
> Duane Rettig <·····@franz.com> writes:
> >
> > As an aside, at one time (before we concentrated our efforts on
> > Corba) we looked into supporting Sun's JNI (Java Native Interface).
> > This interface, ironically, uses a C++ convention
>
> I don't quite agree with this. In what sense it follows a C++
> convention?
It has C functions for creating initial pointers to the various JVM
objects (JNI_CreateJavaVM, etc). The pointers returned from this call
are really C++ objects in that they have a table of function pointers
(ie. vtable) to the actual functions to be called. The JNI
documentation mentions that this is for possible future COM
compatibility.
Chris.
Chris Double <·····@double.co.nz> writes:
> Marco Antoniotti <·······@parades.rm.cnr.it> writes:
>
> > > As an aside, at one time (before we concentrated our efforts on
> > > Corba) we looked into supporting Sun's JNI (Java Native Interface).
> > > This interface, ironically, uses a C++ convention
> >
> > I don't quite agree with this. In what sense it follows a C++
> > convention?
>
> It has C functions for creating initial pointers to the various JVM
> objects (JNI_CreateJavaVM, etc). The pointers returned from this call
> are really C++ objects in that they have a table of function pointers
> (ie. vtable) to the actual functions to be called. The JNI
> documentation mentions that this is for possible future COM
> compatibility.
We may have a problem of terminology. I do not agree that having the
big 'function dispatching table' (the 'vtable') is a C++ism. AFAIK,
in C++ the 'vtable' is really used to make 'virtual' functions work.
Name mangling would be sufficient for a C++ without virtual functions
(and, if I remember correctly) that was the case in the very first
AT&T C++ cfront.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <·······@parades.rm.cnr.it> writes:
>
> We may have a problem of terminology.
You are probably right. The names are all 'C' unmangled. I was
refering to having to look up the vtable to find the function call as
being C++ like.
Cheers,
Chris.
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Chris Double <·····@double.co.nz> writes:
>It has C functions for creating initial pointers to the various JVM
>objects (JNI_CreateJavaVM, etc). The pointers returned from this call
>are really C++ objects in that they have a table of function pointers
>(ie. vtable) to the actual functions to be called. The JNI
>documentation mentions that this is for possible future COM
>compatibility.
I'm not sure if that's a correct interpretation; the objects are
C objects with function pointers in them. Such C objects are
a pretty common form of doing poor-man's object oriented programming
in C.
There's some magic to make C++ usage of all this prettier.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
··········@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
> Chris Double <·····@double.co.nz> writes:
>
> >It has C functions for creating initial pointers to the various JVM
> >objects (JNI_CreateJavaVM, etc). The pointers returned from this call
> >are really C++ objects in that they have a table of function pointers
> >(ie. vtable) to the actual functions to be called. The JNI
> >documentation mentions that this is for possible future COM
> >compatibility.
>
>
> I'm not sure if that's a correct interpretation; the objects are
> C objects with function pointers in them. Such C objects are
> a pretty common form of doing poor-man's object oriented programming
> in C.
Q: And just what is the common form of doing poor-man's object oriented
programming in C?
A: C++!
[sorry, couldn't resist]
> There's some magic to make C++ usage of all this prettier.
Yes, but the syntax and preprocessing is not the concern here.
There is no terminology in C about vtables; that is a C++ concept.
And the C++ usage at the syntax level is not necessarily prettier;
Java's mangling is much more orderly and reproducible, and is thus
could be considered prettier. As I understand it, it comes much
closer to CLOS's technique of naming methods, which I consider
prettiest of all:
CLOS(14): (defmethod foo ((x integer) (y single-float)) (+ x y))
#<STANDARD-METHOD FOO (INTEGER SINGLE-FLOAT)>
CLOS(15): (method-function *)
#<Interpreted Function (METHOD FOO (INTEGER SINGLE-FLOAT))>
CLOS(16):
Note that the name of the method and its function contains the
classes on which it specializes. Now that's pretty.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Erik Naggum <····@naggum.no> writes:
> people are forever mired in a conflation of representation and value. I
> was predictably horrified to read that Bjarne suggests that people use
> _different_ name mangling schemes. the shock, the pain. :)
Alas, if it were so simple as this. Namemangling is only a tip
of the iceberg. Only if a C++ ABI was defined you could use
this; this ABI should not only cover name mangling but also structure/class
layout. template organisation, exception handling, etc.
The suggestion to use different mangling schemes is actually a good one;
it prevents code from linking and that's better than having code crash
and burn later on.
A standard C++ ABI would be better for everybody but with C++ in
a coninuous state of flux in the past couple of years there wasn't
much hope. And now that C++ has been standardized, everybody has arrived
at their own ABI and who will change?
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Russell Wallace wrote:
> It's entirely in the spirit of C++.
Ah. My mistake. There is a spirit of C++ ;)
> One of the primary design objectives of the language
Surely this is an oxymoron when use to describe C++?
Best Regards,
:) will
Janos Blazi wrote:
> I read about LISP programs' ability to modify themselves in several books
> but I did not understand it.
In genreal, you do not modify executing code per se. In lisp, you can use
macros to, at compile time, reqrite code you have entered. For example,
it is quite possible that in your lisp implementation, the only built-in
conditional is "if". The other conditionals can be written in terms of
if. For example, unless:
(defmacro unless( condition &rest forms )
"I just typeed this in off the top of my head. Not sure it will work"
`(if (not ,condition ) (progn ,@forms)))
This will rewrite the unless to an if at compile-time. You can
do much more complex things, in fact any lisp thing to lisp
code at compile time using macros.
Lisp has much more to offer. I think, in general, the most attractive
part to me is that you can write fully generic code. Look at functions
like MAP and REDUCE. Can you do these things in C? Nope.
dave
On Fri, 29 Oct 1999 21:31:44 +0200, Janos Blazi <······@netsurf.de> wrote:
>I read about LISP programs' ability to modify themselves in several books
>but I did not understand it.
>
>In the seventies when I wrote assembly language code for the 6502 modifying
>your code while running was necessary as we did not have enough memory in
>those days and speed was an issue as well.
>But virtually everybody agreed that it was terrible programming style.
It's bad style *if you don't have the language abstractions to manage
it well.
>But then Intel "improved" its segmenting model and calling a memory
>location in a code segment even raised an exception. They regarded
>this as a triumph.
There are Lisp implementations that run atop segmented models, indeed,
some early implementations ran on systems like MULTICS, of which the
Intel segmentation model is a (very, very) pale imitation.
>So we probably do not mean the same thing. I surmise I would have to
>study the LISP macro mechanism to understand that. Is this an AI
>matter? Why is it important.
The AI thing is generally not thought of properly.
The point is not that Lisp is "only good for AI;" the point is that AI
applications have required the ability to create malleable language
abstractions that require the abilities that Lisp provides.
The book "On Lisp" presents all sorts of examples of the use of macros
to build your own language atop Lisp.
When building an AI application, the degree of complexity tends to be
*extremely* high, which means that you need to be able to extend
whatever language you're using to provide abstractions to help you
cope with that complexity.
1) It's easy to add functions to Lisp that behave just the same as
built-in functions.
This pretty much parallels the idea in, say, C, that you can create
your own objects and functions that are about as usable as the
system functions in /usr/include/stdlib.h
2) You can create syntax using macros that is more like having the
ability to create your own control structures.
Suppose you have some sort of transaction processing scheme for a
TP monitor.
In C, you'd have to code things something like:
/* Start of transaction */
txn_thing = open_new_transaction (NO_LOCK_ON_INPUTS);
do_some_stuff;
if (error_condition)
abort_txn(txn_thing);
else
commit_txn(txn_thing);
clean_up_after_txn(txn_thing);
In Lisp, you'd create a new control structure for this so that
you'd never have to do that grotty code. Code that uses
transactions would look like:
(make-transaction (txn_thing 'NO-LOCK-ON-INPUTS)
(do_some_stuff)
(something-else txn_thing))
and the macros behind make-transaction would handle all the bookkeeping
for you.
3) You can create a language on top of Lisp *that still can use Lisp
code inside it.*
If you look back at the "UNIX experience," the folks at Bell Labs
tended to create various "little languages," and Jon Bentley has
nicely recounted how they created a whole host of these for
document processing like PIC, eqn, tbl, along with further "little
languages" that would generate code for other "little languages" in
order to provide convenient abstractions to represent different
sorts of diagrams that one might use in documents.
Lisp takes a sort of opposite tack; it says, "Sure, little
languages are nice. But add them in alongside Lisp so that you can
use the full power of Lisp within them when you need that power."
>And if I do not intend to write code that modifies itself: does that
>mean that LISP is nothing for me? I only want to use LISP for
>educational purposes for thos "Rings of Hanoi" type problems.
Even if you don't use the whole thing, it is useful to look at the set
of control structures and data structures that Common Lisp provides as
it provides a remarkably complete and powerful set of abstractions
useful for writing programs.
If you look at the scripting languages that have gotten popular of
late, the two *major* things they provide that weren't traditionally
available in "compiled" languges like C/Pascal/... are:
a) Associative arrays
(aka "dictionaries" aka "hash tables")
b) Efficient, convenient regular expression interpreters
CL provides the former; many Lisps don't provide the latter, having
more sophisticated (but arguably harder to apply, to the
unsophisticated user) "pattern recognition" schemes.
--
Would-be National Mottos:
USA: "We don't care where you come from. We can't find our *own*
country on a map..."
········@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>
········@news.hex.net (Christopher Browne) writes:
> In Lisp, you'd create a new control structure for this so that
> you'd never have to do that grotty code. Code that uses
> transactions would look like:
>
> (make-transaction (txn_thing 'NO-LOCK-ON-INPUTS)
> (do_some_stuff)
> (something-else txn_thing))
The usual style for this sort of thing is like:
(with-transaction (transaction :no-lock-on-inputs t)
(do-some-stuff)
(do-something-else transaction))
Christopher
* Janos Blazi wrote:
> I read about LISP programs' ability to modify themselves in several books
> but I did not understand it.
I don't think it's the programs' ability to modify themselves that
matters. What matters is that Lisp source code is represented as
structured Lisp data (and the structure is mostly trivial -- lists,
symbols with a sprinkling of literal objects). This lets you write
Lisp programs which manipulate the source code of other Lisp programs
with extraordinary ease. The classic example of this is the Lisp
macro system, which lets you define more-or-less arbitrary
source-to-source transformations, but you can easily cook your own
source-massaging programs (up to and including the macro system if you
wanted).
The outcome of all this is that Lisp people don't regard the language
they have as a given -- they tend to solve problems by building up the
language towards the problem, which is just enormously simpler in Lisp
than it is in almost any other language. It is also an enormously
powerful way of thinking about problems, which is really not available
to people who write in more conventional languages (where if you want
to extend the language even slightly you pretty much have to do the
whole yacc/lex thing).
You have only to look at things which have made their way into the
language, like WITH-OPEN-FILE to see what a win this kind of thing
is. Doing something like that, with the right guarantees, in most
languages is really just a pain.
--tim
In article
<····································@broadway.news.is-europe.net>, "Janos
Blazi" <······@netsurf.de> wrote:
> Is it correct to say that the basic difference between C type languages and
> LISP is that in LISP we get runtime information about the type of an object
> and in C we do not. And that we have to decide if the addtional power we get
> is worth the price?
No. That's only one difference. There is no "one true difference"
between C and Lisp. There isn't even agreement on a canonical list
of fundamental differences.
Here's what I see as the principal difference between C and Lisp:
In C there is a very strong division between compiling a program
and running it: you have to *completely finish* compiling (and
linking) your program before you *start* to run it. And when it
starts running, the compiler and all its associated data structures
(including type information) have vanished.
In Lisp, compiling and running are usually interleaved, and in
fact are often indistinguishable from one another. So in Lisp it's
easy to do things that are pretty much unthinkable in C, like make
changes to a running compiled program *while it's running*, or run a
partially completed program without stubbing out the incomplete parts.
This difference brings about many fundamental changes in a programmer's
mindset. For example, writing a compiler, even a bad one, in C is really
hard. It's something only an advanced C programmer would even attempt,
and you pretty much have to start from scratch. (This is why Perl, Tcl,
etc. are all interpreted.) On the other hand, writing a compiler in
Lisp is *really* easy. It's easy because you can use parts of the
existing Lisp compiler (or even the whole thing) in your compiler.
And the reason you can do that is that the Lisp compiler doesn't go
away when your program runs like it does in C.
Writing compilers is so easy in Lisp that beginning Lisp programmers
learn to do it as a matter of course. It's so easy that many people
who do it aren't even *aware* that what they are doing is writing
a compiler.
Because writing compilers is so easy in Lisp, Lisp programmers tend
to consider *designing a new language* or *making changes to Lisp* as
viable solutions to a much larger range of problems than C programmers
do. In C you only design a language as a last resort (and only if you're
a serious wizard and have a *lot* of time on your hands). Lisp
programmers spend their days extending Lisp, changing it, improving
it. C programmers spend their days working around the limitations
of C because they *can't* change it. They don't know how. This is why
the people who design and implement new languages in the C world become
famous. On those rare occasions when someone *does* extend or improve
C it's big news because it's a big job. In the Lisp world it's
business as usual, and has been for twenty years.
Erann Gat
···@jpl.nasa.gov