Recently I've been examining the internals of various open source
Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
course, are done in C. I presume for optimization reasons. Now, being
a bit of a new comer to Lisp I'm sure this idea has been thought of
before, but I'd like your input on it. I was considering writing a C++
implementation of Lisp. I doubt it will be comparable to any of the
existing implementations, but its sort of a project I'd like to do. I
feel that if designed correctly it will allow Lisp to leverage the
existing C++ libraries out there without worry about name-mangling or
the usage of SWIG (which seems to me to be somewhat lacking in the
Common Lisp department, though I suppose the support is stronger for
Allegro CL).
I'm in the process of discussing the proposal with a couple people,
some who've expressed interest in assisting with it but come primarily
from a C++ background with little to no Lisp experience. Now, all
flames and insults aside, I'd like to ask the Lisp community what
their opinion is of this. My primarily concern is by going with the
higher level C++ it would mean sacrificing some of the speed that is
present in the pure C implementations. Does anyone know of any C++
implementations of a Lisp interpreter? I've come across XLisp, but
would be happy to hear of others (at least I'm pretty sure X-Lisp is
done in C++).
Now, I'm far from an expert in Lisp so I don't want to make
presumptions. However, while a lot of existing functionality exists
for Lisp it is far from being as accessible for general development as
languages like Python and Ruby for example. Of course, ignoring the
fact that Python and Ruby are more scripting languages then anything.
I've been reading over the Lisp HyperSpec a bit and intend on making
the it ANSI compliant, of course.
Anyways, I'd like to hear from you. Recommendations, suggestions,
advice, and _constructive_ criticism are all appreciated.
On Aug 27, 4:32 pm, ·······@gmail.com wrote:
> Recently I've been examining the internals of various open source
> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> course, are done in C.
SBCL and CMUCL are mostly in Lisp. C is used for the GC and bits of
the runtime.
> I presume for optimization reasons. Now, being
> a bit of a new comer to Lisp I'm sure this idea has been thought of
> before, but I'd like your input on it. I was considering writing a C++
> implementation of Lisp. I doubt it will be comparable to any of the
> existing implementations, but its sort of a project I'd like to do.
What exactly are you thinking of writing? Will it be an interpreter,
byte-code compiler, or native-code compiler? What's the relative
importance of performance, features, conformance, etc?
My two cents: The last thing I'd want to do after learning Lisp is
turn around and write a bunch of code in C++. If you want the learning
experience of writing a Lisp implementation, write it in Lisp.
Depending on how much effort you want to put into it, you can write a
Lisp -> Lisp interpreter, or even a Lisp -> C/C++ or Lisp -> ASM
compiler.
As for binding to C++ libraries, I don't think writing the
implementation in C++ is a clear win unless you compile to reasonably
idiomatic C++. You can then write the compiler in whatever language
you want (Lisp!)
On Aug 27, 4:54 pm, Rayiner Hashem <·······@gmail.com> wrote:
> On Aug 27, 4:32 pm, ·······@gmail.com wrote:
>
> > Recently I've been examining the internals of various open source
> > Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> > course, are done in C.
>
> SBCL and CMUCL are mostly in Lisp. C is used for the GC and bits of
> the runtime.
>
> > I presume for optimization reasons. Now, being
> > a bit of a new comer to Lisp I'm sure this idea has been thought of
> > before, but I'd like your input on it. I was considering writing a C++
> > implementation of Lisp. I doubt it will be comparable to any of the
> > existing implementations, but its sort of a project I'd like to do.
>
> What exactly are you thinking of writing? Will it be an interpreter,
> byte-code compiler, or native-code compiler? What's the relative
> importance of performance, features, conformance, etc?
I haven't gotten to the point where I've decided what sort of
approach I would like to take in terms of that. Idealistically I would
say native-code compiler, but again I haven't gotten to a stage where
I can make that sort of decision. That is, of course, based on the
fact that I would place a higher emphasis on performance. Though,
idealistically, I'd find an equal balance of performance and features,
and as little deviation from conformance as possible.
>
> My two cents: The last thing I'd want to do after learning Lisp is
> turn around and write a bunch of code in C++. If you want the learning
> experience of writing a Lisp implementation, write it in Lisp.
> Depending on how much effort you want to put into it, you can write a
> Lisp -> Lisp interpreter, or even a Lisp -> C/C++ or Lisp -> ASM
> compiler.
>
> As for binding to C++ libraries, I don't think writing the
> implementation in C++ is a clear win unless you compile to reasonably
> idiomatic C++. You can then write the compiler in whatever language
> you want (Lisp!)
Would this constitute an implementation of Lisp in Lisp:
(loop (print (eval (read))))
In all seriousness, however, I do see your point. However, since I
work a lot with C++ there really isn't any escaping writing code in it
anyways. Though I do find your suggestion of Lisp -> C/C++ or ASM
interesting. As for the binding for C++ libraries, I think you raise a
good point. I haven't actually spent time yet considering the sort of
synergy that I'd hope to get by doing it in C++, it is purely an idea
right now. But before I committed to anything I wanted to get some
input from others. I'm going to take a look at that Rainer posted and
actually see if what is being done is what I sort of had in mind and
whether or not it would be advantageous to do it.
> Would this constitute an implementation of Lisp in Lisp:
> (loop (print (eval (read))))
Actually, yes it would. But there is a very large range of valid Lisp -
> Lisp implementations, with varying degrees of complexity. I strongly
suggest reading "Lisp in Small Pieces". The author basically goes from
something not much more complex than the above to a full Scheme -> C
compiler.
> interesting. As for the binding for C++ libraries, I think you raise a
> good point. I haven't actually spent time yet considering the sort of
> synergy that I'd hope to get by doing it in C++, it is purely an idea
> right now.
You're not going to get much if any synergy at all by writing the
implementation in C++. You could get some synergy by compiling the
Lisp to C++, but then again I'd rather deal with name mangling that
try to map all of Lisp to the kind of idiomatic C++ you'd need to
generate to achieve any sort of synergy.
Rayiner Hashem <·······@gmail.com> wrote:
+---------------
| On Aug 27, 4:32 pm, ·······@gmail.com wrote:
| > Recently I've been examining the internals of various open source
| > Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
| > course, are done in C.
|
| SBCL and CMUCL are mostly in Lisp. C is used for the GC and bits of
| the runtime.
+---------------
One could honestly say "almost entirely in Lisp":
$ cd ~/src/cmd
$ find cmucl-19c/src -name '*.lisp' | xargs wc -l -c | grep -i total
424719 14684717 total
$ find cmucl-19c/src -name '*.[ch]' | xargs wc -l -c | grep -i total
36550 924419 total
$ find cmucl-19c/src -name '*.[sS]' | xargs wc -l -c | grep -i total
5979 142160 total
$
That is, ~15 MB (425 KLOC) of Lisp, less than 1 MB (37 KLOC) of C,
and just a smidgen of assembler.
Disclaimer: The counts [both C & Lisp] include the sources for
*all* of the available architectures (~8) & operating systems (~11),
not just one combination, so the actual counts for any given
single ISA & O/S would be somewhat smaller.
Disclaimer#2: Not all of the historically-available architectures
and operating systems are still being actively developed.
<http://common-lisp.net/project/cmucl/downloads/release/19d/>
suggests that Linux/x86, FreeBSD/x86, Solaris/SPARC, and
Darwin/PPC are where the current activity is. [...and also
some not-yet-released work towards x86_64 for Linux/FreeBSd].
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Aug 27, 10:54 pm, Rayiner Hashem <·······@gmail.com> wrote:
> As for binding to C++ libraries, I don't think writing the
> implementation in C++ is a clear win unless you compile to reasonably
> idiomatic C++. You can then write the compiler in whatever language
> you want (Lisp!)
That sounds more like a frontend than a real compiler, we probably
need some middle end for optimization. Beside I really doubt how
(un)readable and (un)maintanable would the output from such compiler
be. c++ is damn hard to interact with
On Aug 28, 5:33 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Aug 27, 10:54 pm, Rayiner Hashem <·······@gmail.com> wrote:
>
> > As for binding to C++ libraries, I don't think writing the
> > implementation in C++ is a clear win unless you compile to reasonably
> > idiomatic C++. You can then write the compiler in whatever language
> > you want (Lisp!)
>
> That sounds more like a frontend than a real compiler, we probably
> need some middle end for optimization. Beside I really doubt how
> (un)readable and (un)maintanable would the output from such compiler
> be. c++ is damn hard to interact with
The distinction between "compiler" and "frontend" is somewhat
arbitrary. Most compilers that compile to C use it as a target
"assembler". I'd imagine a -> C++ compiler would be quite similar. See
d2c and opendylan for examples of compilers that do (or can) compile
to C, but have all the traditional compiler stages in front of the C
backend.
On Aug 27, 1:32 pm, ·······@gmail.com wrote:
> Recently I've been examining the internals of various open source
> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> course, are done in C. I presume for optimization reasons.
Not necessarily. Remember that just about every machine has a C
compiler, whereas not many machines come with a native Lisp compiler.
It's much easier to bootstrap Lisp from C than to bootstrap Lisp from
pure assembly, I imagine ;-) C is also "close to the machine," and
typical OS API's are in C, etc. It's harder to tell what C++ is doing
behind the scenes, when it comes to tricky things like memory
management, when certain functions are called, etc. I think Linus
Torvalds originally tried writing Linux in C++, and then switched to C
for that reason.
> I'm in the process of discussing the proposal with a couple people,
> some who've expressed interest in assisting with it but come primarily
> from a C++ background with little to no Lisp experience. Now, all
> flames and insults aside, I'd like to ask the Lisp community what
> their opinion is of this. My primarily concern is by going with the
> higher level C++ it would mean sacrificing some of the speed that is
> present in the pure C implementations.
I think your main concern at this point should be correctness, rather
than speed. After all, there are even Lisp systems built on the JVM
(AKCL?), which probably isn't faster than C++. If you really want to
invest time in this, don't think about performance for now; think
about getting the main feature that you want, which is
interoperability with C++.
> Anyways, I'd like to hear from you. Recommendations, suggestions,
> advice, and _constructive_ criticism are all appreciated.
I think a great project along these lines would be to start with a
solid Lisp->C compiler, like ECL. Take it and try to figure out how
to make it interoperable with C++ code. It seems like that's really
what you want -- interoperability with C++, rather than just
reimplementing a Lisp system -- so if you focus on that goal, I think
you've got a better chance of success.
Best wishes and happy lisping! :-)
mfh
Mark H. wrote:
> On Aug 27, 1:32 pm, ·······@gmail.com wrote:
>> Recently I've been examining the internals of various open source
>> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
>> course, are done in C. I presume for optimization reasons.
>
> Not necessarily. Remember that just about every machine has a C
> compiler, whereas not many machines come with a native Lisp compiler.
> It's much easier to bootstrap Lisp from C than to bootstrap Lisp from
> pure assembly, I imagine ;-) C is also "close to the machine," and
> typical OS API's are in C, etc. It's harder to tell what C++ is doing
> behind the scenes, when it comes to tricky things like memory
> management, when certain functions are called, etc. I think Linus
> Torvalds originally tried writing Linux in C++, and then switched to C
> for that reason.
In 2007, C++ is much better improved over the immature mess that
existed back in 1993... They even have a standard now! In fact, g++
is quite usable and stable these days.
- Daniel
In article <························@x40g2000prg.googlegroups.com>,
"Mark H." <············@gmail.com> wrote:
> On Aug 27, 1:32 pm, ·······@gmail.com wrote:
> > Recently I've been examining the internals of various open source
> > Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> > course, are done in C. I presume for optimization reasons.
>
> Not necessarily. Remember that just about every machine has a C
> compiler, whereas not many machines come with a native Lisp compiler.
> It's much easier to bootstrap Lisp from C than to bootstrap Lisp from
> pure assembly, I imagine ;-)
The other alternative would be to use a cross-compiler
on a different machine.
...
> I think your main concern at this point should be correctness, rather
> than speed. After all, there are even Lisp systems built on the JVM
> (AKCL?),
ABCL
AKCL was a Lisp to C compiler/implementation. KCL->AKCL->...->GCL and ECLS
> which probably isn't faster than C++. If you really want to
> invest time in this, don't think about performance for now; think
> about getting the main feature that you want, which is
> interoperability with C++.
>
> > Anyways, I'd like to hear from you. Recommendations, suggestions,
> > advice, and _constructive_ criticism are all appreciated.
>
> I think a great project along these lines would be to start with a
> solid Lisp->C compiler, like ECL. Take it and try to figure out how
> to make it interoperable with C++ code. It seems like that's really
> what you want -- interoperability with C++, rather than just
> reimplementing a Lisp system -- so if you focus on that goal, I think
> you've got a better chance of success.
>
> Best wishes and happy lisping! :-)
> mfh
On Aug 28, 1:25 am, "Mark H." <············@gmail.com> wrote:
> I think a great project along these lines would be to start with a
> solid Lisp->C compiler, likeECL. Take it and try to figure out how
> to make it interoperable with C++ code.
ECL already _builds_ using a C++ compiler and you can in principle
embed C++ code in it. A more complicated issue is to redesign the
foreign function interface for handling C++ objects. That requires a
lot of thinkin, I guess.
Juanjo
Juanjo wrote:
> On Aug 28, 1:25 am, "Mark H." <············@gmail.com> wrote:
>
>>I think a great project along these lines would be to start with a
>>solid Lisp->C compiler, likeECL. Take it and try to figure out how
>>to make it interoperable with C++ code.
>
>
> ECL already _builds_ using a C++ compiler and you can in principle
> embed C++ code in it. A more complicated issue is to redesign the
> foreign function interface for handling C++ objects. That requires a
> lot of thinkin, I guess.
Try Googling "Tacoma"
hth,kzo
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
P� Tue, 28 Aug 2007 22:21:33 +0200, skrev Juanjo
<·····················@googlemail.com>:
> On Aug 28, 1:25 am, "Mark H." <············@gmail.com> wrote:
>> I think a great project along these lines would be to start with a
>> solid Lisp->C compiler, likeECL. Take it and try to figure out how
>> to make it interoperable with C++ code.
>
> ECL already _builds_ using a C++ compiler and you can in principle
> embed C++ code in it. A more complicated issue is to redesign the
> foreign function interface for handling C++ objects. That requires a
> lot of thinkin, I guess.
>
> Juanjo
>
>
I used to interface to C++ from assembly code. I even wrote C++ classes in
assembly code.
It is not as difficult as you seem to think. It all boils down to
understanding the link format.
C++ needs to encode the parameter information in the link code and there
is no standard for how.
If you restrict yourself to a few compilers (gcc, VC++ and CodeWarrior
would be a good start)
then the job should be doable. The real trick is just to write C++ stubs
and then compile to assembly
(usually a -S option). You can then derive the link extensions.
I have never attempted to interface template code so this might be more
troublesome.
Then there is the question of RTTI. I would suggest to forget this in the
start.
John Thingstad wrote:
> P� Tue, 28 Aug 2007 22:21:33 +0200, skrev Juanjo
> <·····················@googlemail.com>:
>
>> On Aug 28, 1:25 am, "Mark H." <············@gmail.com> wrote:
>>> I think a great project along these lines would be to start with a
>>> solid Lisp->C compiler, likeECL. Take it and try to figure out how
>>> to make it interoperable with C++ code.
>>
>> ECL already _builds_ using a C++ compiler and you can in principle
>> embed C++ code in it. A more complicated issue is to redesign the
>> foreign function interface for handling C++ objects. That requires a
>> lot of thinkin, I guess.
>
> I used to interface to C++ from assembly code. I even wrote C++ classes
> in assembly code.
> It is not as difficult as you seem to think. It all boils down to
> understanding the link format.
> C++ needs to encode the parameter information in the link code and there
> is no standard for how.
> If you restrict yourself to a few compilers (gcc, VC++ and CodeWarrior
> would be a good start)
> then the job should be doable. The real trick is just to write C++ stubs
> and then compile to assembly
> (usually a -S option). You can then derive the link extensions.
> I have never attempted to interface template code so this might be more
> troublesome.
C++ templates are simply compiler macros with a funny pattern matching
system that decides which ones to instantiate. Once instantiated,
templates are no different than normal code, modulo the name mangling.
- Daniel
> C++ templates are simply compiler macros with a funny pattern matching
> system that decides which ones to instantiate. Once instantiated,
> templates are no different than normal code, modulo the name mangling.
>
> - Daniel
While binding to any particular instantiation is the same as binding
to any other C++ code (modulo name mangling), getting the code
instantiated in the first place is the trick. Consider a graph class
like:
template <typename NodeType, typename EdgeType>
class Graph {
std::vector<NodeType> nodeVec;
std::vector<EdgeType> edgeVec;
};
How do you usefully expose this template to Lisp code? How do you then
generalize that mechanism to do something useful for all such C++
templates?
·······@gmail.com wrote:
> Recently I've been examining the internals of various open source
> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> course, are done in C. I presume for optimization reasons. Now, being
> a bit of a new comer to Lisp I'm sure this idea has been thought of
> before, but I'd like your input on it. I was considering writing a C++
> implementation of Lisp. I doubt it will be comparable to any of the
> existing implementations, but its sort of a project I'd like to do.
Go for it. I had the same feeling when reading the SBCL C sources.
Reworking this code in C++ should make it more readable and
maintainable, but I haven't given it enough thought to be sure. One
reason to do this would be to loosen the coupling between the GC and
the rest of the core... maybe then people would implement better Lisp
GC's....
> I feel that if designed correctly it will allow Lisp to leverage the
> existing C++ libraries out there without worry about name-mangling or
> the usage of SWIG (which seems to me to be somewhat lacking in the
> Common Lisp department, though I suppose the support is stronger for
> Allegro CL).
This is another issue -- that the C++ compiler does non-standard
destructive operations on a complex grammar (even the preprocessor
language rarely implemented correctly[1]). Coding the Lisp core in
C++ won't make this interaction any easier -- unless you wish to
recompile the core to add new libraries -- but even then, getting
idiomatic Lisp is the hard part.
An even more interesting project -- one that would have C++ users
drooling with envy -- would be to write something like a debugger for
C/C++ in Lisp. Instead of compiling header files into a simple C/CFFI
wrapper (SWIG/Verrazano), the Lisp user could simply load a shared
library (with debug symbols), and use the debugger to interactively
explore what functions are available, set breakpoints, write interface
code, store interfaces, ... Such a debugger would probably consist of
a lot of Lisp built on a thin layer to libelf[2] and libdwarf[3].
Bonus points for rewriting the autotools as a Lisp system:
- replace m4 with a real language
- replace make's syntax with a real language
- don't rely on shell scripts[4]
- use Lisp to interactively instantiate new C++ templates and load
them into the currently process
> I'm in the process of discussing the proposal with a couple people,
> some who've expressed interest in assisting with it but come primarily
> from a C++ background with little to no Lisp experience. Now, all
> flames and insults aside, I'd like to ask the Lisp community what
> their opinion is of this. My primarily concern is by going with the
> higher level C++ it would mean sacrificing some of the speed that is
> present in the pure C implementations.
C++ is merely an object system built on top of C; if you don't use
objects, the code compiles exactly the same (except for name mangling
(which happens at compile time) and RTTI (which is poorly implemented
and almost never used)). As for speed, exposing/integrating vector
ops[5] into Lisp might also be useful (e.g. Lisp matrix ops would be
fast).
If anybody else needs some project ideas... ;)
Later,
Daniel
[1] http://boost.org/libs/wave/doc/preface.html
[2] http://www.mr511.de/software/
[3] http://reality.sgiweb.org/davea/dwarf.html
[2-3.x] http://t-a-w.blogspot.com/2007/03/how-to-code-debuggers.html
[4] Why isn't there a LispUser'sSHell (lush; the superior version is
slush) like http://www.scsh.net/ ?
[5] http://common-lisp.net/project/sb-simd/
(I hacked/updated the start page a bit -- it needs more work.)
> An even more interesting project -- one that would have C++ users
> drooling with envy -- would be to write something like a debugger for
> C/C++ in Lisp. Instead of compiling header files into a simple C/CFFI
> wrapper (SWIG/Verrazano), the Lisp user could simply load a shared
> library (with debug symbols), and use the debugger to interactively
> explore what functions are available, set breakpoints, write interface
> code, store interfaces, ... Such a debugger would probably consist of a
> lot of Lisp built on a thin layer to libelf[2] and libdwarf[3].
Not exactly the same, but the ROOT/CINT projects are C/C++
interpretter+compiler in one - e.g. you can select what files to be
interpretted, and what compiled, and mix them together. The interpretter
also comes with built-in reflection (introspection) and other cool features:
http://root.cern.ch/
Similiar to the project above are: UnderC, and the Ch interpretter.
I'd rather stick only to Common Lisp for now.
In article <······················@r29g2000hsg.googlegroups.com>,
·······@gmail.com wrote:
> Recently I've been examining the internals of various open source
> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> course, are done in C.
Often Common Lisp is implemented in a mix of C, Assembler
and (lots of) Lisp.
> I presume for optimization reasons.
'portability' can be another reason.
> Now, being
> a bit of a new comer to Lisp I'm sure this idea has been thought of
> before, but I'd like your input on it. I was considering writing a C++
> implementation of Lisp. I doubt it will be comparable to any of the
> existing implementations, but its sort of a project I'd like to do. I
> feel that if designed correctly it will allow Lisp to leverage the
> existing C++ libraries out there without worry about name-mangling or
> the usage of SWIG (which seems to me to be somewhat lacking in the
> Common Lisp department, though I suppose the support is stronger for
> Allegro CL).
>
> I'm in the process of discussing the proposal with a couple people,
> some who've expressed interest in assisting with it but come primarily
> from a C++ background with little to no Lisp experience. Now, all
> flames and insults aside, I'd like to ask the Lisp community what
> their opinion is of this. My primarily concern is by going with the
> higher level C++ it would mean sacrificing some of the speed that is
> present in the pure C implementations. Does anyone know of any C++
> implementations of a Lisp interpreter? I've come across XLisp, but
> would be happy to hear of others (at least I'm pretty sure X-Lisp is
> done in C++).
Most implementations of Lisp are based on compilers and/or interpreters.
XCL is a new attempt at a Common Lisp implementation
written (partly) in C++.
http://www.cliki.net/XCL
> Now, I'm far from an expert in Lisp so I don't want to make
> presumptions. However, while a lot of existing functionality exists
> for Lisp it is far from being as accessible for general development as
> languages like Python and Ruby for example.
What do you mean by 'accessible'?
Make sure you see the difference between a language 'Common Lisp'
and its implementations.
> Of course, ignoring the
> fact that Python and Ruby are more scripting languages then anything.
> I've been reading over the Lisp HyperSpec a bit and intend on making
> the it ANSI compliant, of course.
>
> Anyways, I'd like to hear from you. Recommendations, suggestions,
> advice, and _constructive_ criticism are all appreciated.
On Aug 27, 4:46 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <······················@r29g2000hsg.googlegroups.com>,
>
> ·······@gmail.com wrote:
> > Recently I've been examining the internals of various open source
> > Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> > course, are done in C.
>
> Often Common Lisp is implemented in a mix of C, Assembler
> and (lots of) Lisp.
>
> > I presume for optimization reasons.
>
> 'portability' can be another reason.
Yes, I neglected to mention Assembler. Of course, with regards to
the Lisp I apologize. I was referring to the runtime environment.
Though I imagine portability becomes more difficult in C and
Assembler, no?
>
>
> > Now, being
> > a bit of a new comer to Lisp I'm sure this idea has been thought of
> > before, but I'd like your input on it. I was considering writing a C++
> > implementation of Lisp. I doubt it will be comparable to any of the
> > existing implementations, but its sort of a project I'd like to do. I
> > feel that if designed correctly it will allow Lisp to leverage the
> > existing C++ libraries out there without worry about name-mangling or
> > the usage of SWIG (which seems to me to be somewhat lacking in the
> > Common Lisp department, though I suppose the support is stronger for
> > Allegro CL).
>
> > I'm in the process of discussing the proposal with a couple people,
> > some who've expressed interest in assisting with it but come primarily
> > from a C++ background with little to no Lisp experience. Now, all
> > flames and insults aside, I'd like to ask the Lisp community what
> > their opinion is of this. My primarily concern is by going with the
> > higher level C++ it would mean sacrificing some of the speed that is
> > present in the pure C implementations. Does anyone know of any C++
> > implementations of a Lisp interpreter? I've come across XLisp, but
> > would be happy to hear of others (at least I'm pretty sure X-Lisp is
> > done in C++).
>
> Most implementations of Lisp are based on compilers and/or interpreters.
>
> XCL is a new attempt at a Common Lisp implementation
> written (partly) in C++.
Thank you, I will have to check it out.
>
> http://www.cliki.net/XCL
>
> > Now, I'm far from an expert in Lisp so I don't want to make
> > presumptions. However, while a lot of existing functionality exists
> > for Lisp it is far from being as accessible for general development as
> > languages like Python and Ruby for example.
>
> What do you mean by 'accessible'?
Its far more easier for someone to come and start using Python and/
or Ruby for a project and find the sort of functionality they need in
terms of external libraries then it is in Lisp, though I could be
mistaken.
>
> Make sure you see the difference between a language 'Common Lisp'
> and its implementations.
>
> > Of course, ignoring the
> > fact that Python and Ruby are more scripting languages then anything.
> > I've been reading over the Lisp HyperSpec a bit and intend on making
> > the it ANSI compliant, of course.
>
> > Anyways, I'd like to hear from you. Recommendations, suggestions,
> > advice, and _constructive_ criticism are all appreciated.
In article <························@r34g2000hsd.googlegroups.com>,
·······@gmail.com wrote:
> Yes, I neglected to mention Assembler. Of course, with regards to
> the Lisp I apologize. I was referring to the runtime environment.
Often parts of the runtime environment are written in Lisp itself.
> Though I imagine portability becomes more difficult in C and
> Assembler, no?
Probably.
> > What do you mean by 'accessible'?
>
> Its far more easier for someone to come and start using Python and/
> or Ruby for a project and find the sort of functionality they need in
> terms of external libraries then it is in Lisp, though I could be
> mistaken.
Depends on what you want to do. For everything web scripting,
Python/Ruby should have an advantage. If you are interested
in Computer Algebra and Symbolic Mathematics systems, Lisp should have an
advantage (since there are a few written in Lisp).
Also there are commercial implementations that might offer
an alternative that you can't get with Ruby.
If you are an experienced programmer, you can get quite far with
Lisp.
For me an important difference is:
* with Common Lisp I have a stable standard core language
with lots of very different implementation (-> Choice!)
which can share code.
* with Ruby, Python, Rebol, ... you get very similar languages
with very similar implementations which share no code.
For some this is not much of a problem. They just reimplement
everything when switching languages.
> >
> > Make sure you see the difference between a language 'Common Lisp'
> > and its implementations.
> >
> > > Of course, ignoring the
> > > fact that Python and Ruby are more scripting languages then anything.
> > > I've been reading over the Lisp HyperSpec a bit and intend on making
> > > the it ANSI compliant, of course.
> >
> > > Anyways, I'd like to hear from you. Recommendations, suggestions,
> > > advice, and _constructive_ criticism are all appreciated.
In article <························@r34g2000hsd.googlegroups.com>,
·······@gmail.com wrote:
> > XCL is a new attempt at a Common Lisp implementation
> > written (partly) in C++.
>
> Thank you, I will have to check it out.
Some related stuff...
http://www.isi.edu/isd/LOOM/Stella/index.html
http://www.interhack.net/projects/lpp/
http://per.bothner.com/software/Q/Q.README
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/kamin/budd/0.html
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/lily/0.html
http://www.intelib.org/
·······@gmail.com wrote:
> Recently I've been examining the internals of various open source
> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> course, are done in C. I presume for optimization reasons. Now, being
> a bit of a new comer to Lisp I'm sure this idea has been thought of
> before, but I'd like your input on it. I was considering writing a C++
> implementation of Lisp.
Maybe this is a good idea, because with C++ it could be easier and more
safe to implement things like the garbage collector. But if you are a new
comer to Lisp, I would suggest that you write some Lisp programs, first. If
you like to use C++ libraries, why not trying to start with a better
solution than SWIG, but in pure Common Lisp, maybe mapping to CFFI? C++
name mangling is nothing compared to writing a new Common Lisp
implementation :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Aug 27, 5:06 pm, Frank Buss <····@frank-buss.de> wrote:
> ·······@gmail.com wrote:
> > Recently I've been examining the internals of various open source
> > Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> > course, are done in C. I presume for optimization reasons. Now, being
> > a bit of a new comer to Lisp I'm sure this idea has been thought of
> > before, but I'd like your input on it. I was considering writing a C++
> > implementation of Lisp.
>
> Maybe this is a good idea, because with C++ it could be easier and more
> safe to implement things like the garbage collector. But if you are a new
> comer to Lisp, I would suggest that you write some Lisp programs, first. If
> you like to use C++ libraries, why not trying to start with a better
> solution than SWIG, but in pure Common Lisp, maybe mapping to CFFI? C++
> name mangling is nothing compared to writing a new Common Lisp
> implementation :-)
>
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
Quite true. What I was thinking in terms of that, which I've been
meaning to examine a bit more, is writing something in Lisp that would
be able to map a C++ object/function to its mangled named, that way it
would be compiler independent. So you'd take a C++ library, for
example, run the Lisp program, and in turn would have CFFI bindings
using the mangled names but without actually hard coding it in, if
that makes any sense. I think the problem with that, however, is you'd
still have to know how a compiler mangles the C++ code and would have
to implement it for each individual compiler. I could wrong though, as
I've only briefly looked at anything relating to how the compilers
mangle the names. But, I was under the assumption that each compiler
has some sort of convention?
On Aug 27, 2:26 pm, ·······@gmail.com wrote:
> Quite true. What I was thinking in terms of that, which I've been
> meaning to examine a bit more, is writing something in Lisp that would
> be able to map a C++ object/function to its mangled named, that way it
> would be compiler independent.
In general, this is impossible without invoking a specific C++
compiler to figure out how it mangles names. C++ name mangling isn't
portable. For that matter, Fortran 77 name mangling isn't even
portable. (This has proven annoying for me and many of my colleagues
many times.) Different compilers have different conventions, and I
can't even say for sure if the same name in different object files
always maps to the same mangling. Mangling conventions may even
change when the compiler version changes.
About the only thing you could do is write a Lisp -> C++ compiler, and
then use the system's C++ compiler to do all the work. That way you
could mix and match C++ and Lisp. However, this seems risky, because C
++ calls functions like constructors and destructors without telling
you. So you'll have to write the Lisp->C++ compiler so that it fakes
out the C++ compiler, if you want to return some C++ object from a
Lisp function. The semantics (C++ objects which aren't allocated
using the "new" operator are copied on return -- this means the copy
constructor is called) seem too different for you to be able to mix
and match the two languages effectively.
One thing you could do for inspiration is to look at OpenMCL's
Objective C bridge. Objective C is an object-oriented version of C
that works more like SmallTalk than like C++. I imagine you could use
that as a model for a C++ bridge, though you should note that C++ is a
more static language, so you won't get much help from the runtime.
mfh
"Mark H." <············@gmail.com> writes:
> About the only thing you could do is write a Lisp -> C++ compiler, and
> then use the system's C++ compiler to do all the work. That way you
> could mix and match C++ and Lisp.
A good example of this approach would be gcl I believe (only gcl targets C
instead of C++).
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
On Aug 28, 7:20 am, Pascal Bourguignon <····@informatimago.com> wrote:
> "Mark H." <············@gmail.com> writes:
> > About the only thing you could do is write a Lisp -> C++ compiler, and
> > then use the system's C++ compiler to do all the work. That way you
> > could mix and match C++ and Lisp.
>
> A good example of this approach would be gcl I believe (only gcl targets C
> instead of C++).
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
> protons, etc.) comprising this product are exactly the same in every
> measurable respect as those used in the products of other
> manufacturers, and no claim to the contrary may legitimately be
> expressed or implied.
Thank you for all the input and advice. I guess I greatly
underestimated how much of the current Lisp implementations were
implemented in Lisp itself and how little was actually in C. I've
focused so much on the C internals that I completely neglected the
most important part. And I really liked Herring's ideas as well,
especially the debugger. I'm going to spend a bit of time reading over
the various resources that were pointed out and getting better
acquainted with Lisp itself. I'll definitely keep in touch with the
community, however, since a large part of my motivation is to support
it and help it grow.
·······@gmail.com wrote:
> On Aug 27, 5:06 pm, Frank Buss <····@frank-buss.de> wrote:
>> ·······@gmail.com wrote:
>>> Recently I've been examining the internals of various open source
>>> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
>>> course, are done in C. I presume for optimization reasons. Now, being
>>> a bit of a new comer to Lisp I'm sure this idea has been thought of
>>> before, but I'd like your input on it. I was considering writing a C++
>>> implementation of Lisp.
>> Maybe this is a good idea, because with C++ it could be easier and more
>> safe to implement things like the garbage collector. But if you are a new
>> comer to Lisp, I would suggest that you write some Lisp programs, first. If
>> you like to use C++ libraries, why not trying to start with a better
>> solution than SWIG, but in pure Common Lisp, maybe mapping to CFFI? C++
>> name mangling is nothing compared to writing a new Common Lisp
>> implementation :-)
>>
>> --
>> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
>
> Quite true. What I was thinking in terms of that, which I've been
> meaning to examine a bit more, is writing something in Lisp that would
> be able to map a C++ object/function to its mangled named, that way it
> would be compiler independent. So you'd take a C++ library, for
> example, run the Lisp program, and in turn would have CFFI bindings
> using the mangled names but without actually hard coding it in, if
> that makes any sense. I think the problem with that, however, is you'd
> still have to know how a compiler mangles the C++ code and would have
> to implement it for each individual compiler. I could wrong though, as
> I've only briefly looked at anything relating to how the compilers
> mangle the names. But, I was under the assumption that each compiler
> has some sort of convention?
Verrazano[1] made a good stab at that. And yes, especially on 64-bit
machines, there is a standard ABI[2] (describes how functions call
each other, etc.).
Later,
Daniel
[1] http://common-lisp.net/project/fetter/
[2] http://www.codesourcery.com/cxx-abi/
GCC and others are trying to standardize on this for all x86 code --
good/bad techniques are becoming well-known and they're tired of
struggling with pointless interop problems.
Frank Buss <··@frank-buss.de> writes:
> ·······@gmail.com wrote:
>
>> Recently I've been examining the internals of various open source
>> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
>> course, are done in C. I presume for optimization reasons. Now, being
>> a bit of a new comer to Lisp I'm sure this idea has been thought of
>> before, but I'd like your input on it. I was considering writing a C++
>> implementation of Lisp.
>
> Maybe this is a good idea, because with C++ it could be easier and more
> safe to implement things like the garbage collector. But if you are a new
> comer to Lisp, I would suggest that you write some Lisp programs, first. If
> you like to use C++ libraries, why not trying to start with a better
> solution than SWIG, but in pure Common Lisp, maybe mapping to CFFI? C++
> name mangling is nothing compared to writing a new Common Lisp
> implementation :-)
Wow, actually I'm in the same situation as the OP, I'm new to common
lisp from a C/C++ background, and lately I've been thinking about the
possibility of interfacing C++ and clisp in a more native way than CFFI
or such can do, but I've been too much of a coward to expose my dreams
(nightmares? :) to you lispers.
However, I think that being able to choose to implement any function
or class in a program either in pure clisp or in C++, without having to
do some tricky interfacing would be incredibly powerful. This way, one
could write his application totally in common lisp and then profile it
and rewrite the most critic parts (performance or memory
consumption-wise) in C++, or interface with it any C or C++ library
without problem. (I'm not saying here that common lisp is slow or
anything, but I trust C++ for being *potentially* faster).
Once again I don't know common lisp well enough to judge how foolish
this idea is, but if some day such thing was possible, it would be
really powerful IMO, since you could use the strengths of both languages
in a complementary manner.
I hope my English is not too despicable...
Cheers,
--
Simias, junior lisper
rot13 for email
Frank Buss wrote:
> ·······@gmail.com wrote:
>
>
>> Recently I've been examining the internals of various open source
>>Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
>>course, are done in C. I presume for optimization reasons. Now, being
>>a bit of a new comer to Lisp I'm sure this idea has been thought of
>>before, but I'd like your input on it. I was considering writing a C++
>>implementation of Lisp.
>
>
> Maybe this is a good idea, because with C++ it could be easier and more
> safe to implement things like the garbage collector. But if you are a new
> comer to Lisp, I would suggest that you write some Lisp programs, first. If
> you like to use C++ libraries, why not trying to start with a better
> solution than SWIG, but in pure Common Lisp, maybe mapping to CFFI?
But make sure you name it after a suspension bridge.
hth, kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
Ken Tilton <·········@gmail.com> wrote:
+---------------
| Frank Buss wrote:
...
| > If you like to use C++ libraries, why not trying to start with a better
| > solution than SWIG, but in pure Common Lisp, maybe mapping to CFFI?
|
| But make sure you name it after a suspension bridge.
+---------------
Oh, that's too general. We need to narrow it down some.
Hmmm... *I* know! How about suspension bridges with "Narrows"
in the name? We already have a "V", so how about a "T"?
Yeah, "Tacoma"! Just don't use it for real-time control of
periodic input. (*bouncy*) (*bouncy*) (*bouncy*)... (*CRASH!*)
-Rob
p.s. Yes, yes, I do know that the driving function
on the original was a mild *steady* wind...
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
·······@gmail.com wrote:
> Anyways, I'd like to hear from you. Recommendations, suggestions,
> advice, and _constructive_ criticism are all appreciated.
Buy LiSP aka "Lisp In Small Pieces".
--
Jens Axel S�gaard
·······@gmail.com writes:
> My primarily concern is by going with the
> higher level C++ it would mean sacrificing some of the speed that is
> present in the pure C implementations.
Sounds like a fun project.
This should be the thing to be least worried about. C++ is as fast as
C. I also think that making use of the STL and Boost can speed up
programs because they contain highly optimized versions of basic
algorithms and data structures. If you don't have to worry about those
kinds of things then you can spend your time on the real core of your
project: lisp :-)
I wish more projects would take that approach. There are countless
projects that insist on reinventing the wheel (and most other parts of
the car) in C. If those would only use standard libraries then their
size, complexity and elegance would improve bigtime.
S.
Stefan Arentz wrote:
> This should be the thing to be least worried about. C++ is as fast as
> C. I also think that making use of the STL and Boost can speed up
> programs because they contain highly optimized versions of basic
> algorithms and data structures. If you don't have to worry about those
> kinds of things then you can spend your time on the real core of your
> project: lisp :-)
Exactly what data structures in a runtime system would you want to use
such high-level C++ template libraries for?
A non-Lisp-runtime for Lisp needs to do exactly two things: Implement a
virtual machine, if necessary, and interface to the OS. Not really many
complex algorithms going on there that need being tackled with highly
specialized C++ data structures (you would rather want to do that in
Lisp as early as possible, wouldn't you?)
·······@gmail.com writes:
> Recently I've been examining the internals of various open source
> Lisp implementations (SBCL, CMUCL, and CLisp). All of these, of
> course, are done in C. I presume for optimization reasons. Now, being
> a bit of a new comer to Lisp I'm sure this idea has been thought of
> before, but I'd like your input on it. I was considering writing a C++
> implementation of Lisp. I doubt it will be comparable to any of the
> existing implementations, but its sort of a project I'd like to do. I
> feel that if designed correctly it will allow Lisp to leverage the
> existing C++ libraries out there without worry about name-mangling or
> the usage of SWIG (which seems to me to be somewhat lacking in the
> Common Lisp department, though I suppose the support is stronger for
> Allegro CL).
>
> I'm in the process of discussing the proposal with a couple people,
> some who've expressed interest in assisting with it but come primarily
> from a C++ background with little to no Lisp experience. Now, all
> flames and insults aside, I'd like to ask the Lisp community what
> their opinion is of this. My primarily concern is by going with the
> higher level C++ it would mean sacrificing some of the speed that is
> present in the pure C implementations. Does anyone know of any C++
> implementations of a Lisp interpreter? I've come across XLisp, but
> would be happy to hear of others (at least I'm pretty sure X-Lisp is
> done in C++).
>
> Now, I'm far from an expert in Lisp so I don't want to make
> presumptions. However, while a lot of existing functionality exists
> for Lisp it is far from being as accessible for general development as
> languages like Python and Ruby for example. Of course, ignoring the
> fact that Python and Ruby are more scripting languages then anything.
> I've been reading over the Lisp HyperSpec a bit and intend on making
> the it ANSI compliant, of course.
>
> Anyways, I'd like to hear from you. Recommendations, suggestions,
> advice, and _constructive_ criticism are all appreciated.
I am not an expert on Lisp, just learning. The answers depend on your
purpose.
If you are looking for a fun project, go for it, but I can imagine
projects that would have superior fun/time spent ratio, for example,
programming in Lisp. You might not be please with the C code in CL
implementations, but the point with those is to get some C to
bootstrap Lisp and write everything else in Lisp, getting out of C (or
C++ in your case as quickly as possible).
But if your purpose is to write something that is better than existing
implementations (free or commercial ones), I wouldn't try. A lot of
man-hours went into those projects, and C++ is not _that_ much better
than C to be able to save you so much programming, especially when it
comes to stuff you find at the bottom of Lisp implementations.
Tamas
I have been making a little Lisp interpreter in C++ myself,
and I have a lot of fun from writing and improving it, and trying
new ideas.
So if you are interesting in writing your own and have time, just do
it,
it will be fun, and will improve your understanding of the language.
Some random thoughts from my experience and ideas:
(1) GC - I don't use GC myself, I use Boost.SmartPtr to wrap every
Lisp object, it works great, but I saw gc module in Tamarin (Adobe's
JavaScript VM) is very slick, maybe I will give it a try.
(2) Runtime mode - I made an ordinary interpreter, but (again)
after I saw IronPython, I am very interested, it build a AST,
(the source code can be discarded), then it runs the tree directly.
Of course, this is not a new idea, someone use it to interpreter Lisp
already (search "Kamin lisp").
My 2 cents
Happy making your own Lisp!
cg wrote:
> I have been making a little Lisp interpreter in C++ myself,
We see that so rarely around here. Listen people, just STFU. Thers is a
list of things you need not say, because we already know it (the "..."
is where His Kennyness stops reading):
"WTF? All I did was (delete x '(..."
"Hi, I love lisp, just started last week, I have an idea for the paren..."
"LISP..."
"Lisp rocks! I am working on a COBOL imp..."
And my favorite, of course:
"Kenny, Cells is so cool, what do you think of my..."
> and I have a lot of fun from writing and improving it, and trying
> new ideas.
Oh, I am sure there is a lot we have not thought of in the past fifty years.
>
> So if you are interesting in writing your own and have time, just do
> it,
> it will be fun, and will improve your understanding of the language.
Beats the crap out of actually writing an application, right? Well, I
must say you found the right NG, nothing but a bunch of wannabes and
publish or perish academics around here.
>
> Some random thoughts from my experience and ideas:
>
> (1) GC - I don't use GC myself, I use Boost.SmartPtr to wrap every
> Lisp object, it works great, but I saw gc module in Tamarin (Adobe's
> JavaScript VM) is very slick, maybe I will give it a try.
Nah, f*ck it, I'll get more RAM.
>
> (2) Runtime mode - I made an ordinary interpreter, but (again)
> after I saw IronPython, I am very interested, it build a AST,
> (the source code can be discarded), then it runs the tree directly.
> Of course, this is not a new idea, someone use it to interpreter Lisp
> already (search "Kamin lisp").
>
> My 2 cents
> Happy making your own Lisp!
Go. A. Way.
hth,kzo
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Tue, 28 Aug 2007 23:37:36 -0400, <···········@optonline.net> wrote:
> cg wrote:
>> and I have a lot of fun from writing and improving it, and trying
>> new ideas.
>
> Oh, I am sure there is a lot we have not thought of in the past fifty years.
I'd lay good money that we can make a C++ in lisp faster than any
supertroll could roll a C++ lisp. Just think, the dark winter ahead
holds many posts!
--
Lisp: Powering `Impossible Thoughts since 1958
--
Posted via a free Usenet account from http://www.teranews.com
On Aug 29, 7:11 am, GP lisper <········@CloudDancer.com> wrote:
> On Tue, 28 Aug 2007 23:37:36 -0400, <···········@optonline.net> wrote:
> > cg wrote:
> >> and I have a lot of fun from writing and improving it, and trying
> >> new ideas.
>
> > Oh, I am sure there is a lot we have not thought of in the past fifty years.
>
> I'd lay good money that we can make a C++ in lisp faster than any
> supertroll could roll a C++ lisp. Just think, the dark winter ahead
> holds many posts!
>
> --
> Lisp: Powering `Impossible Thoughts since 1958
>
> --
> Posted via a free Usenet account fromhttp://www.teranews.com
Now there's a pretty good idea. What did you have in mind exactly
when you say a C++ in Lisp, if you don't mind elaborating?
P� Wed, 29 Aug 2007 05:37:36 +0200, skrev Ken Tilton
<···········@optonline.net>:
>> (2) Runtime mode - I made an ordinary interpreter, but (again)
>> after I saw IronPython, I am very interested, it build a AST,
>> (the source code can be discarded), then it runs the tree directly.
>> Of course, this is not a new idea, someone use it to interpreter Lisp
>> already (search "Kamin lisp").
Unless we want Lisp to die when the 50 years + developers retire for good
perhaps it would not be a bad idea to let some new people have a go at it.
You learn by doing. Ok so the first try might not be mind blowing. It's
the guy that comes around for a third try you watch out for. Noone starts
out a expert and implementing vs. using brings out different aspects of
the language.
(Imagine all math teachers were equally dismissive each time a student had
a new idea. Ah it's been done before.. Do you really think you can do
something original? What do you think would happen to interest in the
field?)
>> My 2 cents
>> Happy making your own Lisp!
>
John Thingstad wrote:
> P� Wed, 29 Aug 2007 05:37:36 +0200, skrev Ken Tilton
> <···········@optonline.net>:
>
>>> (2) Runtime mode - I made an ordinary interpreter, but (again)
>>> after I saw IronPython, I am very interested, it build a AST,
>>> (the source code can be discarded), then it runs the tree directly.
>
>
>>> Of course, this is not a new idea, someone use it to interpreter Lisp
>>> already (search "Kamin lisp").
It wasn't me.
John Thingstad wrote:
> for. Noone starts out a expert and implementing vs. using brings out
> different aspects of the language.
Mr. Tilton obviously has chosen to fill in the place left vacant by the
dearly departed Mr. Naggum, although from what I dimly remember from
that individual, Tilton is just a cheap copy. As always.
Meanwhile, I would advise prospective Lisp students to seek out other
venues of information rather than c.l.l. if they're really out for
factual information instead of a bemusing visit to the freak zoo and an
exercise in self-flagellation.
Matthias Buelow <···@incubus.de> writes:
> Meanwhile, I would advise prospective Lisp students to seek out other
> venues of information rather than c.l.l. if they're really out for
> factual information instead of a bemusing visit to the freak zoo and an
> exercise in self-flagellation.
I am getting quality help from c.l.l, which I highly appreciate. The
fact that you aren't might prompt some introspection.
Tamas
On Aug 29, 8:43 am, Tamas Papp <······@gmail.com> wrote:
> Matthias Buelow <····@incubus.de> writes:
> > Meanwhile, I would advise prospective Lisp students to seek out other
> > venues of information rather than c.l.l. if they're really out for
> > factual information instead of a bemusing visit to the freak zoo and an
> > exercise in self-flagellation.
>
> I am getting quality help from c.l.l, which I highly appreciate. The
> fact that you aren't might prompt some introspection.
>
> Tamas
I second that. I was fried once, and upon introspection, realized my
post was (a bit) of nonsense. Ok, just maybe, more than a bit of
nonsense.
As for the post(er) that started this threat-within-a-thread, it does
remind me a bit of Ann Coulter, although I appreciate the poster's
humor much more than the lady's.
(Shields up full force, warp 9 as far away from the poster as
possible ... panic in voice)
Mirko
Tamas Papp wrote:
> I am getting quality help from c.l.l, which I highly appreciate. The
> fact that you aren't might prompt some introspection.
I'm not reading this newsgroup for gratuitous help. I just want to talk
about Lisp every now and then and read what other people are up to.
However, what I observe is that a few posters regularly flame Lisp
newbies who are posting questions or suggestions that are not 100% in
line with a perceived doctrine. It's just an observation, not a complaint.
Matthias Buelow <···@incubus.de> writes:
> Tamas Papp wrote:
>
>> I am getting quality help from c.l.l, which I highly appreciate. The
>> fact that you aren't might prompt some introspection.
>
> I'm not reading this newsgroup for gratuitous help. I just want to talk
> about Lisp every now and then and read what other people are up to.
> However, what I observe is that a few posters regularly flame Lisp
> newbies who are posting questions or suggestions that are not 100% in
> line with a perceived doctrine. It's just an observation, not a complaint.
OMG, I didn't know that there was a "perceived doctrine". Maybe I
miraculously escaped being flamed in the past, but pray tell me about
this perceived doctrine, I may not be so lucky in the future.
Tamas
Tamas Papp <······@gmail.com> writes:
> Matthias Buelow <···@incubus.de> writes:
>
>> Tamas Papp wrote:
>>
>>> I am getting quality help from c.l.l, which I highly appreciate. The
>>> fact that you aren't might prompt some introspection.
>>
>> I'm not reading this newsgroup for gratuitous help. I just want to talk
>> about Lisp every now and then and read what other people are up to.
>> However, what I observe is that a few posters regularly flame Lisp
>> newbies who are posting questions or suggestions that are not 100% in
>> line with a perceived doctrine. It's just an observation, not a complaint.
>
> OMG, I didn't know that there was a "perceived doctrine". Maybe I
> miraculously escaped being flamed in the past, but pray tell me about
> this perceived doctrine, I may not be so lucky in the future.
Well, Mathias perceptions do not match yours, which is exactly
why they are perceptions...
In article <·············@mid.dfncis.de>,
Matthias Buelow <···@incubus.de> wrote:
> John Thingstad wrote:
>
> > for. Noone starts out a expert and implementing vs. using brings out
> > different aspects of the language.
>
> Mr. Tilton obviously has chosen to fill in the place left vacant by the
> dearly departed Mr. Naggum, although from what I dimly remember from
> that individual, Tilton is just a cheap copy. As always.
> Meanwhile, I would advise prospective Lisp students to seek out other
> venues of information rather than c.l.l. if they're really out for
> factual information instead of a bemusing visit to the freak zoo and an
> exercise in self-flagellation.
It's not always the others that are only freaks.
You can also learn to use a filter to get a very nice
newsgroup. Though, if the only posts you then see are your
own, then you better look for help elsewhere. ;-)
--
http://lispm.dyndns.org
On 29 Aug, 03:02, cg <··········@gmail.com> wrote:
> (1) GC - I don't use GC myself, I use Boost.SmartPtr to wrap every
> Lisp object, it works great,
Isn't this based on reference counting? Is there some black magic
going on under the hood or does it just fail to collect circular
references?
On Aug 29, 5:16 am, Chris Russell <·····················@gmail.com>
wrote:
> On 29 Aug, 03:02, cg <··········@gmail.com> wrote:
>
> > (1) GC - I don't use GC myself, I use Boost.SmartPtr to wrap every
> > Lisp object, it works great,
>
> Isn't this based on reference counting? Is there some black magic
> going on under the hood or does it just fail to collect circular
> references?
Yes, they're based on smart pointers, and pay an enormous performance
price for that. The underlying irony of modern C++ is that if you
actually write idiomatic "modern C++", with smart pointers and the STL
everywhere, you'll cut your performance in half, and at that point you
might as well use Lisp anyway.
On Aug 29, 2:05 pm, Rayiner Hashem <·······@gmail.com> wrote:
> On Aug 29, 5:16 am, Chris Russell <·····················@gmail.com>
> wrote:
>
> > On 29 Aug, 03:02, cg <··········@gmail.com> wrote:
>
> > > (1) GC - I don't use GC myself, I use Boost.SmartPtr to wrap every
> > > Lisp object, it works great,
>
> > Isn't this based on reference counting? Is there some black magic
> > going on under the hood or does it just fail to collect circular
> > references?
>
> Yes, they're based on smart pointers, and pay an enormous performance
> price for that. The underlying irony of modern C++ is that if you
> actually write idiomatic "modern C++", with smart pointers and the STL
> everywhere, you'll cut your performance in half, and at that point you
> might as well use Lisp anyway.
Obviously I mean they're based on "reference counting".
Rayiner Hashem <·······@gmail.com> writes:
> you'll cut your performance in half
That's a lot of hyperbole. Are you imagining programs that do little but
create and destroy reference-counted smart pointers?
--
Steven E. Harris
On Aug 29, 2:09 pm, "Steven E. Harris" <····@panix.com> wrote:
> Rayiner Hashem <·······@gmail.com> writes:
> > you'll cut your performance in half
>
> That's a lot of hyperbole. Are you imagining programs that do little but
> create and destroy reference-counted smart pointers?
I'm talking about idiomatic "modern C++" code that makes heavy use of
smart pointers, STL collections, functional style, etc. These things
all have major performance costs relative to the alternative
techniques that would be used in idiomatic C code (intrusive
collections, etc).
Consider something very simple like an object that contains two smart
pointer fields. When I insert this object into an STL list, I have to:
1) Allocate a list node (much bigger than a cons cell, since it
contains the object by value)
2) Call the copy constructor for the object type, and copy the whole
object
3) Call the copy constructor for the smart pointer, twice
4) Frob the reference counts with CAS instructions, twice
5) Perform the actual list manipulation
This is not a cheap sequence of operations. It touches more memory,
uses more memory, and uses slower operations (CAS instructions are
expensive!) than the Lisp equivalent. On top of that, this sequence
(and functional STL style code in general, really) uses C++ memory
allocators in pessimistic ways (I've observed OS X's malloc() to be
several times slower than SBCL's GC for high allocation rate, high-
mortality cases).
You can, of course, mitigate most of the loss by rewriting performance-
critical bits in a lower-level style. This has its own share of
problems, because in my experience, different styles of C++ do not
mesh well at the boundaries, and the rewrite itself is rarely a
straightforward improvement of the original code.
Rayiner Hashem wrote:
> On Aug 29, 2:09 pm, "Steven E. Harris" <····@panix.com> wrote:
>> Rayiner Hashem <·······@gmail.com> writes:
>>> you'll cut your performance in half
>> That's a lot of hyperbole. Are you imagining programs that do little but
>> create and destroy reference-counted smart pointers?
>
> I'm talking about idiomatic "modern C++" code that makes heavy use of
> smart pointers, STL collections, functional style, etc. These things
> all have major performance costs relative to the alternative
> techniques that would be used in idiomatic C code (intrusive
> collections, etc).
I don't know how relevant this is anymore.
This was way back around 2000 and I haven't done C++ in a while,
so the class names that I mention are probably spelled wrong.
But FWIW -
I had written some C++ code that used the STL String class and worked in
a muulti threaded environment
But all of the uses of the String objects were within the thread they
were create in and when passed across threads they were used in a
immutable fashion.
After profiling I found the sting class to be the major cause. That
class assumes mutability under threaded conditions and performed
horribly. Even what one would consider const methods such as getting a c
string pointer (I think the method is named c_str) caused allocation
and mutex operations within that class. This was the STL from SGI.
I wrote a signature compatible (for the methods I was using) class of my
own that was not thread safe for mutability.
Replaced all occurrences with my class and got substantial performance
boost.
I am someone who values maintainability, extensibility, readability etc
much more highly than performance. So this was a real bad one for me to
have done what I did.
-Antony Sequeira
Rayiner Hashem <·······@gmail.com> writes:
> Consider something very simple like an object that contains two smart
> pointer fields. When I insert this object into an STL list, I have to:
If you're already in your version of idiomatic smart-pointer-heavy mode,
why are you storing this type in a std::list by value? Why not store it
by reference using the very same smart pointer (that is,
std::list<std::shared_ptr<T>>), eliminating much of the overhead you're
complaining about here?
Items 1 and 5 on your complaint list are still necessary ever for an
intrusive list. Storing the objects by reference as I suggested above
adds only the shared_ptr copy constructor -- assuming you can't just
/move/ it in place. Well, soon enough you will be able to.
I see a straw man argument here: You're talking about passing around
heavyweight objects by value as a means to complain about smart
pointers, but the cost of passing these objects around is itself one of
the motivating reasons for using smart pointers -- to handle objects by
reference rather than by value. You're complaining that the solution to
the problem is part of the problem, but you're not actually considering
/using/ the solution to fix the problem.
--
Steven E. Harris
> If you're already in your version of idiomatic smart-pointer-heavy mode,
> why are you storing this type in a std::list by value? Why not store it
> by reference using the very same smart pointer (that is,
> std::list<std::shared_ptr<T>>), eliminating much of the overhead you're
> complaining about here?
You wouldn't store a shared_ptr in the list if the items you were
storing in the list did not need to be shared. This is just good
modern C++ style --- you use a value-oriented approach unless you
absolutely need reference/shared semantics.
There are also numerous practical reasons not to do this. shared_ptr's
are not transparent abstractions. A shared_ptr<T> tries to replicate
the behavior of T*, but in good C++ code, where T is a value-like
type, replicating the behavior of T* is not what you want. Eg: given a
list of T objects, I want find_if compare T objects using T's
operator=, not T* objects using a test for pointer equality. None of
this is anything that can't be fixed by some extra typing and dealing
with annoying cases (eg: inserting the result a function that returns
a T into a list of type std::list<shared_ptr<T> > requires some extra
jiggering), but the natural and easy and clean thing to do is just
avoid all of this and store the value type in the container. Again,
the STL is a value-oriented container library, BY DESIGN.
> Items 1 and 5 on your complaint list are still necessary ever for an
> intrusive list.
(1) is not necessary in an intrusive list (that's the whole point of
an intrusive list). The avoidance of memory allocation is why
intrusive data structures are use in, for example, OS kernels.
Rayiner Hashem <·······@gmail.com> writes:
> You wouldn't store a shared_ptr in the list if the items you were
> storing in the list did not need to be shared.
I understand that. I was just pointing out that where people used to
use, say, std::list<T*> to deal with heavyweight objects, today they
might use std::list<shared_ptr<T>> instead, or maybe
std::list<unique_ptr<T>> soon.
> This is just good modern C++ style --- you use a value-oriented
> approach unless you absolutely need reference/shared semantics.
But you're complaining that storing your type by value is onerous, so I
pointed out a way around it. Don't attack the solution because it
betrays the style you'd like to use. Your heavyweight object is the
problem, not std::list.
> There are also numerous practical reasons not to do this.
[...]
I know all this and agree with you.
> the natural and easy and clean thing to do is just avoid all of this
> and store the value type in the container. Again, the STL is a
> value-oriented container library, BY DESIGN.
Right. But you started out by complaining about this design and the
costs it imposes in concert with your heavyweight objects, relating the
problem to smart pointers. Aren't you really just making a plea for
intrusive "containers"?
> (1) is not necessary in an intrusive list (that's the whole point of
> an intrusive list).
You wrote:
> 1) Allocate a list node (much bigger than a cons cell, since it
> contains the object by value)
With an intrusive list, you're doing much the same, as the value is
/also/ a list node, needing at minimum one pointer to the next node, if
not two in a doubly-linked list.
And why the pejorative comparison to a cons cell, which is mostly
analogous to SGI's slist<shared_ptr<T>>�? If I understand you correctly,
you like the by-reference storage efficiency of a cons cell, but you
don't like the impedance mismatch with a C++ Standard Library container
storing T* or shared_ptr<T> because of the unnatural extra level of
indirection. Is that correct?
Footnotes:
� http://www.sgi.com/tech/stl/Slist.html
--
Steven E. Harris
> But you're complaining that storing your type by value is onerous, so I
> pointed out a way around it. Don't attack the solution because it
> betrays the style you'd like to use. Your heavyweight object is the
> problem, not std::list.
I'm trying to present the style the STL encourages you to use, and the
performance ramifications thereof. Yes, you can write things in other
ways to avoid the problems, but that's besides the point. When writing
C++ code naturally and idiomatically, this is what you end up with.
Incidentally, this is a recognized weakness of the STL. Things like
move semantics are an attempt to improve the performance of this sort
of idiomatic STL-style code.
> Right. But you started out by complaining about this design and the
> costs it imposes in concert with your heavyweight objects, relating the
> problem to smart pointers. Aren't you really just making a plea for
> intrusive "containers"?
I'm suggesting that if you need every last bit of performance, as in a
language runtime, just write the dang thing in C.
> With an intrusive list, you're doing much the same, as the value is
> /also/ a list node, needing at minimum one pointer to the next node, if
> not two in a doubly-linked list.
The difference is that in an intrusive list, you only allocate the
cons cell once, along with the object. In an unintrusive list, you
have to allocate the cons cell on each list insertion.
> And why the pejorative comparison to a cons cell, which is mostly
> analogous to SGI's slist<shared_ptr<T>>¹?
It's not really analagous at all. Say I have an
slist<shared_ptr<Foo>>, and I want to grab the first element. In Lisp,
a CAR is basically a memory load, plus maybe a tag-check if type-
inference failed. With a shared pointer, we're talking a memory load
for the data, plus a ref-count update. In a thread-safe
implementation, this involves an atomic increment, which can be an
order of magnitude slower than anything else in the sequence.
Rayiner Hashem <·······@gmail.com> writes:
> Incidentally, this is a recognized weakness of the STL. Things like
> move semantics are an attempt to improve the performance of this sort
> of idiomatic STL-style code.
Yes, immediately after writing last night, I was thinking about how I
should have mentioned move semantics in my post. I fought the urge to
write again.
> I'm suggesting that if you need every last bit of performance, as in a
> language runtime, just write the dang thing in C.
I see. But it's worth noting that the "zero overhead principle" still
governs C++: the idea that any "extra" cost to using C++ would turn out
to be equivalent to the cost in C code one would have to write to do the
same thing. Apparently C++ has disappointed you in this regard and left
you suspicious.
> With a shared pointer, we're talking a memory load for the data, plus
> a ref-count update.
Why would the shared_ptr be copied?
sl.front()
would return a shared_ptr<T> const&, which could in turn be
dereferenced to reach T or its member foo:
T const& t = *sl.front();
Foo const& f = sl.front()->foo;
> In a thread-safe implementation, this involves an atomic increment,
> which can be an order of magnitude slower than anything else in the
> sequence.
True. One would hope the thread-safe implementation selection could be
disabled at least at the program level, if not the type instantiation
level. That's QoI.
--
Steven E. Harris
> I see. But it's worth noting that the "zero overhead principle" still
> governs C++: the idea that any "extra" cost to using C++ would turn out
> to be equivalent to the cost in C code one would have to write to do the
> same thing. Apparently C++ has disappointed you in this regard and left
> you suspicious.
In C-style code, you wouldn't, as a matter of style, use a value-based
approach like the STL. As far as I can see, the only reason to use a
value-based approach is that it allows you to get away without GC in a
lot of cases. I don't think it's worth it overall --- I'd rather just
pay the GC cost and get on with life, instead of getting nickle'ed and
dime'ed everywhere.
> sl.front()
>
> would return a shared_ptr<T> const&, which could in turn be
> dereferenced to reach T or its member foo:
It'd be copied the minute you did something like:
shared_ptr<T> head = sl.front();
Yes, you could do shared_ptr<T>& head = sl.front() and use that
everywhere, but then you pay a double-indirection on each access. And
anyway it's a PITA to micro-manage like that.
> True. One would hope the thread-safe implementation selection could be
> disabled at least at the program level, if not the type instantiation
> level. That's QoI.
The STL is completely FUBAR'ed with regard to thread safety. It has
all this custom allocator crap to make up for the fact that it conses
like a functional language, without a fast generational GC to back it
up, and the whole mess is incredibly complicated to make thread-safe.
P� Wed, 29 Aug 2007 20:09:44 +0200, skrev Steven E. Harris <···@panix.com>:
> Rayiner Hashem <·······@gmail.com> writes:
>
>> you'll cut your performance in half
>
> That's a lot of hyperbole. Are you imagining programs that do little but
> create and destroy reference-counted smart pointers?
>
I remember at Opera versions up to version 6 were based on reference
counting. It was one of the worst performing (and most buggy) JavaScipt
(ECMA script actually if you are picky) out there. Then we got a new guy
in to work on JavaScript. He took his PhD on the performance of garbage
collectors. Anyhow now Operas JavaScript is one of the fastest and most
complete implementations. A real garbage collector made is a significant
factor. On thing you may not have considered is that the new operator in
C++ is typically just a thin layer over malloc. malloc works on a first
fit principle, not best fit. With the large memories in use today this can
lead to significant heap fragmentation and slow performance with long
runs. Contrary to common belief a good garbage collector can outperform
C++ explicit allocation/deallocation scheme in many cases.
"John Thingstad" <··············@chello.no> writes:
> On thing you may not have
> considered is that the new operator in C++ is typically just a thin
> layer over malloc. malloc works on a first fit principle, not best
> fit.
Not so - this is a quality of implementation issue. The last
time I came across a first-fit implementation of malloc was around
1991... back then, I wrote my own code to maintain multiple lists of
free areas (of fixed size) for a simulator (NMT900 cellphones and base
stations).
> With the large memories in use today this can lead to
> significant heap fragmentation and slow performance with long
> runs. Contrary to common belief a good garbage collector can
> outperform C++ explicit allocation/deallocation scheme in many cases.
Can (probably) even outperform "good" implementations of
malloc :-)
On Aug 29, 11:09 am, "Steven E. Harris" <····@panix.com> wrote:
> Rayiner Hashem <·······@gmail.com> writes:
> > you'll cut your performance in half
>
> That's a lot of hyperbole. Are you imagining programs that do little but
> create and destroy reference-counted smart pointers?
There's some data on this, and it doesn't have so much to do with
smart pointers. See e.g., the uBLAS (in Boost) or MTL documentation,
which discusses some of the problems of trying to use template
metaprogramming for optimization. A lot of clever work succeeds in
getting rid of overhead (as compared with a straightforward C-like
implementation) much, but not all, of the time.
mfh