Hello, folks.
Since I've grown frustrated with the abstration capabilities of C, but
am yet at the mercy of many C libraries which I use, I have started to
work on a straightforward s-exp representation of C.
I intend to use this as a target for automatic code generation. I do
numerics mostly, and often want clever loop merging, unrolling, etc.
I've not found the FFI's in the lisps I have access to (CMUCL and
CLISP, I'm a grad student with no budget) to be sufficient for what I
want. I'd like to write libraries which can be called from other
tools, such as Python or IDL or other C code, and I find that hard to
do with most FFI's.
So, before I work too hard on this, am I insane? Am I re-inventing
the wheel? Or am I wise beyond my years? :-)
Thanks for any comments,
--Johann
--
Johann Hibschman ······@physics.berkeley.edu
Johann Hibschman <······@physics.berkeley.edu> writes:
> Hello, folks.
>
> Since I've grown frustrated with the abstration capabilities of C, but
> am yet at the mercy of many C libraries which I use, I have started to
> work on a straightforward s-exp representation of C.
>
> I intend to use this as a target for automatic code generation. I do
> numerics mostly, and often want clever loop merging, unrolling, etc.
>
> I've not found the FFI's in the lisps I have access to (CMUCL and
> CLISP, I'm a grad student with no budget) to be sufficient for what I
> want. I'd like to write libraries which can be called from other
> tools, such as Python or IDL or other C code, and I find that hard to
> do with most FFI's.
I believe the only real solution to these problems will come in the
form of a nice and *portable* CORBA interface.
> So, before I work too hard on this, am I insane? Am I re-inventing
> the wheel? Or am I wise beyond my years? :-)
>
> Thanks for any comments,
I don't think you are insane. But the solution to your problems is
not simple. The main obstacle lies in the fact that most CL
environments are not mere "scripting engines" (to use another common
locution). Therefore the usual simple trick of "using the system a a
C library" will not quite work. Hence the more complex and costly
solution is the only one that saves the goat and the cabbage. The end
result will be to have an integrated environment were things "do the
right thing" (I don't live on the West Coast anymore, so I can
subscribe to the "Right Thing" mantra :) ).
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Johann Hibschman <······@physics.berkeley.edu> writes:
> Hello, folks.
>
> Since I've grown frustrated with the abstration capabilities of C, but
> am yet at the mercy of many C libraries which I use, I have started to
> work on a straightforward s-exp representation of C.
>
> I intend to use this as a target for automatic code generation. I do
> numerics mostly, and often want clever loop merging, unrolling, etc.
Sounds like an interesting project. If there is one single feature of
Lisp that I most often pine for when writing in C (or Java!) it's the
macro system -- and by extension the inherent code generation
capabilities.
> I've not found the FFI's in the lisps I have access to (CMUCL and
> CLISP, I'm a grad student with no budget) to be sufficient for what I
> want. I'd like to write libraries which can be called from other
> tools, such as Python or IDL or other C code, and I find that hard to
> do with most FFI's.
>
> So, before I work too hard on this, am I insane? Am I re-inventing
> the wheel? Or am I wise beyond my years? :-)
It certainly strikes me as a reasonable idea. I have come across some
projects in my travels that you might want to dig up -- but I'm afraid
I'll have to rely on someone else here to provide concrete, up-to-date
references.
First, there was a Scheme project that bootstrapped its implementation
by defining a machine-operation-oriented subset of Scheme -- something
like a portable assembler (e.g. C) with S-expression syntax. It
*might* have been Scheme48. ISTR this was translated to portable C
code for compiling on the target architecture. Obviously it was
specialized to a particular task, but there might be some useful
tidbits in the design of this Scheme-assembler. I don't know if it
supported a macro system, but with S-expressions for syntax it could
of course defer macroexpansion to a host Lisp.
And predating this was a compiler for Scheme called Scheme->C. Again,
not focused exactly on what you're (I think) proposing, but a useful
body of work to examine and learn from. The author was (I think) from
DEC, and of course DEC has since been bought by Compaq. I suspect some
kind soul from comp.lang.scheme can readily provide a current URL for
either or both of these projects.
Hmmm, wasn't there also someone working on a compiler (to C) for SCM?
The name Hobbit comes to mind.
Naturally there have been Common Lisp to C compilers. AKCL, I believe
now known as GCL, does this. And there is a commercial product called
Ecolisp. But I would hesitate to recommend spending a lot of time
mining there -- the goal of these projects is very different from what
you're contemplating.
Likewise, at least one researcher (from Microsoft) explored building a
"real" macro system atop C's infix syntax. With all due respect to the
Dylan community, I hope everyone here can agree that S-expressions
make a much better substrate for code generation in general and
sophisticated macrology in particular.
> Thanks for any comments,
I hope you decide to pursue this project, and keep us posted on your
results.
-- Kaelin
Kaelin Colclasure wrote:
> First, there was a Scheme project that bootstrapped its implementation
> by defining a machine-operation-oriented subset of Scheme -- something
> like a portable assembler (e.g. C) with S-expression syntax. It
> *might* have been Scheme48.
That is correct. The subset is called Pre-Scheme.
> And predating this was a compiler for Scheme called Scheme->C. Again,
> not focused exactly on what you're (I think) proposing, but a useful
> body of work to examine and learn from. The author was (I think) from
> DEC, and of course DEC has since been bought by Compaq. I suspect some
> kind soul from comp.lang.scheme can readily provide a current URL for
> either or both of these projects.
http://www-swiss.ai.mit.edu/~jar/s48.html
http://gatekeeper.dec.com/pub/DEC/Scheme-to-C/
> Hmmm, wasn't there also someone working on a compiler (to C) for SCM?
> The name Hobbit comes to mind.
Yes.
http://www-swiss.ai.mit.edu/~jaffer/Hobbit.html
Kaelin Colclasure wrote in message ...
>Johann Hibschman <······@physics.berkeley.edu> writes:
>
>> Hello, folks.
>>
>> Since I've grown frustrated with the abstration capabilities of C, but
>> am yet at the mercy of many C libraries which I use, I have started to
>> work on a straightforward s-exp representation of C.
>>
>> I intend to use this as a target for automatic code generation. I do
>> numerics mostly, and often want clever loop merging, unrolling, etc.
>
>Sounds like an interesting project. If there is one single feature of
>Lisp that I most often pine for when writing in C (or Java!) it's the
>macro system -- and by extension the inherent code generation
>capabilities.
(Sorry, I lost the original posting, so I reply to this one instead)
Since you (Johann Hibschmann) seem to look for high-performance
code (numerics, etc.): There was a system called TScheme, which
is practically C with Scheme syntax (statically typed, etc.)
Unfortunately I can't find it on the 'net (google turned up
a link to NWU, but it's dead). the Author is Mark DePristo.
Perhaps someone else knows something about it.
cheers,
felix
Kaelin Colclasure <······@everest.com> writes:
> Johann Hibschman <······@physics.berkeley.edu> writes:
Hey Johann, long time no bunnies!
> > Since I've grown frustrated with the abstration capabilities of C, but
> > am yet at the mercy of many C libraries which I use, I have started to
> > work on a straightforward s-exp representation of C.
> >
> > I intend to use this as a target for automatic code generation. I do
> > numerics mostly, and often want clever loop merging, unrolling, etc.
>
> > I've not found the FFI's in the lisps I have access to (CMUCL and
> > CLISP, I'm a grad student with no budget) to be sufficient for what I
> > want. I'd like to write libraries which can be called from other
> > tools, such as Python or IDL or other C code, and I find that hard to
> > do with most FFI's.
> >
> > So, before I work too hard on this, am I insane? Am I re-inventing
> > the wheel? Or am I wise beyond my years? :-)
Bigloo, http://kaolin.unice.fr/~serrano/bigloo/bigloo.html, is a
Scheme designed explicitly to be fast and interface well with C
code. It's only downfall (as a Scheme) is that it's pretty inefficient
with call/cc, but I don't think that you'll be going there anyway.
No you're not insane, but not wise beyond your years either. I keep
threatening to do the same thing you're contemplating (because I want
to write an OS kernel in Scheme), but I just can't justify the cost
(while I'm working on real code) when there are pretty good
off-the-shelf solutions.
david rush
--
With guns, we are citizens. Without them, we are subjects.
-- YZGuy, IPL
David Rush writes:
> Kaelin Colclasure <······@everest.com> writes:
>> Johann Hibschman <······@physics.berkeley.edu> writes:
> Hey Johann, long time no bunnies!
Busybusybusy, you know. I'd like to finish that thesis. :-)
They're after me, you know.
>> > So, before I work too hard on this, am I insane? Am I re-inventing
>> > the wheel? Or am I wise beyond my years? :-)
> Bigloo, http://kaolin.unice.fr/~serrano/bigloo/bigloo.html, is a
> Scheme designed explicitly to be fast and interface well with C
> code. It's only downfall (as a Scheme) is that it's pretty inefficient
> with call/cc, but I don't think that you'll be going there anyway.
I experimented with Bigloo a year or so ago and at the time found that
it, like most Scheme/Lisp systems, insisted on being the top-level
loop. I have enough work invested in python glue that I can't afford
that, alas. I'll know better next time.
(Although, as an aside, I do find python/IDL/matlab infix syntax to be
easier to use as an interactive shell. "x = data*2" is somehow much
more natural than "(setq x (* data 2))". That's one of the reasons I
like using python as my top-level glue...)
> No you're not insane, but not wise beyond your years either. I keep
> threatening to do the same thing you're contemplating (because I want
> to write an OS kernel in Scheme), but I just can't justify the cost
> (while I'm working on real code) when there are pretty good
> off-the-shelf solutions.
Right. I don't think the off-the-shelf solutions quite fit my needs,
although I am still tracking down the links suggested by others in
this thread.
Realistically, I'm not going to use this for my current work.
However, I expect to do things later which will have similar
constraints, so I'm spending some time now to understand my options.
Thanks for all the comments,
--Johann
--
Johann Hibschman ······@physics.berkeley.edu
> Johann Hibschman <······@physics.berkeley.edu> writes:
>
> > Hello, folks.
> >
> > Since I've grown frustrated with the abstration capabilities of C,
> > but am yet at the mercy of many C libraries which I use, I have
> > started to work on a straightforward s-exp representation of C.
Interesting. I started to do the same thing a while back. My
motivation was partly to construct wrapper functions automatically and
cleanly for calling C from Scheme. I created a language with
arbitrarily-nestable let and begin expressions (which were lifted up
to the top level in the C output) and lambda expressions (expanded
statically, using call-by-name). I didn't get as far as adding loops
(which would complicate transformations in the face of side-effects).
I can send you a copy of the code I wrote, if you like.
If I started again, I would consider using a statically-typed language
(or add better type declaration constructs to Scheme): Transforming
the S-expressions to C involved several transformations, and it got
tricky remembering which sublanguages were being transformed between
which each time (particularly when I kept changing these
sublanguages!). Also using pattern matching is essential.
I'm also quite interested in performing the reverse process -- turning
C code into S-expressions. Can anyone recommend any lexers and
parsers for C in Scheme or in another functional language like Haskell
or ML?
> > So, before I work too hard on this, am I insane?
Certainly not.
> > Am I re-inventing the wheel?
Probably not. The various Scheme to C compilers probably contain some
similar code, but it's probably too specialised.
> > Or am I wise beyond my years? :-)
That depends how numerous your years are. :-)
--
Mark Seaborn
- ········@bigfoot.com - http://members.xoom.com/mseaborn/ -
``He who fights against dragons becomes a dragon himself''
-- Nietzsche
{stuff deleted}
> I'm also quite interested in performing the reverse process -- turning
> C code into S-expressions. Can anyone recommend any lexers and
> parsers for C in Scheme or in another functional language like Haskell
> or ML?
ckit
ckit is a C front end written in SML that translates C source code
(after preprocessing) into abstract syntax represented as a set of SML
datatypes. It also provides facilities for extending the C language
with additional syntactic constructs, which can be useful for
implementing "C-like" domain-specific languages as well as C
dialects. Ckit is currently used as the front end for a variety of
tools for static analysis of C code and at least one domain-specific
language.
http://cm.bell-labs.com/cm/cs/what/smlnj/doc/ckit/
Mark Seaborn writes:
>> Johann Hibschman <······@physics.berkeley.edu> writes:
>> > Since I've grown frustrated with the abstration capabilities of C,
>> > but am yet at the mercy of many C libraries which I use, I have
>> > started to work on a straightforward s-exp representation of C.
> Interesting. I started to do the same thing a while back. My
> motivation was partly to construct wrapper functions automatically and
> cleanly for calling C from Scheme. I created a language with
> arbitrarily-nestable let and begin expressions (which were lifted up
> to the top level in the C output) and lambda expressions (expanded
> statically, using call-by-name). I didn't get as far as adding loops
> (which would complicate transformations in the face of side-effects).
> I can send you a copy of the code I wrote, if you like.
Hm. It sounds like we're a bit different, at that. So far, I'm just
trying to produce C transliterated into sexpr syntax. Any
begin/let/etc. work will be another layer.
So far I have basic declarations, keywords, loops, and definitions
working. There's nothing more clever there than C, but now I can at
least start thinking about good abstractions to build on top of C.
> If I started again, I would consider using a statically-typed language
> (or add better type declaration constructs to Scheme): Transforming
> the S-expressions to C involved several transformations, and it got
> tricky remembering which sublanguages were being transformed between
> which each time (particularly when I kept changing these
> sublanguages!). Also using pattern matching is essential.
Well, I'm starting with a layer which is fairly direct, so I'm not
abstracted that far. Perhaps if I'd ever taken a compilers class, I'd
be trying to write something far more general, powerful, and less
likely to be completed.
>> > Or am I wise beyond my years? :-)
> That depends how numerous your years are. :-)
More than I'd like, but not enough to worry about.
--
Johann Hibschman ······@physics.berkeley.edu
On 10 Dec 2000 16:08:12 -0800, Kaelin Colclasure <······@everest.com>
wrote:
> now known as GCL, does this. And there is a commercial product called
> Ecolisp. But I would hesitate to recommend spending a lot of time
Ecolisp is free software (it's a KCL derivative, if I remember correctly).
The product you refer to is probably Eclipse.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/