why not the scheme implementation written in scheme?
Changying Li
why are almost all of implementatin of scheme written in c?
is it possible to write a not very slow scheme compiler & intepreter in
scheme-- not toy, but a real implementation?
I'm writing a scheme->llvm compiler in scheme as a toy. I don't know whether it
is possible to make it as a real compiler.
--
Thanks & Regards
Changying Li
Shiro Kawai
goal was
interoperability with C, specifically that I wanted to use core part
of Gauche
as "convenient list processing library" from C.
It is certainly possible to write a real implementation in Scheme.
Take a look at
Scheme48, for example. (Its core part is written in subset of Scheme
which can
be compiled to native code via C. Other things are built on top of
it.)
--shiro
Michael Sperber
Changying Li <lchan...@gmail.com> writes:
> why are almost all of implementatin of scheme written in c?
> is it possible to write a not very slow scheme compiler & intepreter in
> scheme-- not toy, but a real implementation?
Scheme 48 is almost entirely written in Scheme. (That is, pretty much
everything except the interface to the OS.)
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Changying Li
Now I know it is a possible way.
Michael Sperber <spe...@deinprogramm.de> writes:
> Changying Li <lchan...@gmail.com> writes:
>
>> why are almost all of implementatin of scheme written in c?
>> is it possible to write a not very slow scheme compiler & intepreter in
>> scheme-- not toy, but a real implementation?
>
> Scheme 48 is almost entirely written in Scheme. (That is, pretty much
> everything except the interface to the OS.)
>
> http://www.s48.org/
--
Thanks & Regards
Changying Li
Changying Li
BTW, glad to meed you here. Gauche is one of my favorite scheme.
comp.lang.scheme
Hi, Changying.
I use four Schemes, that I checked to be much faster than the others.
Three of them are written in Scheme, not in C. They are:
1 --- Stalin --- It is not only written in Scheme, but you need a
Scheme compiler to bootstrap it. It takes six hours to compile Stalin
for Windows. If you want binaries for Windows, go to http://code.google.com/p/stalingui/
By the way, if you find sources of Stalin in C, this does not mean
that it was written in C. This means that someone used Scheme-C to
generate C source code from Scheme sources. Felix used Chicken to
compile Stalin. Romildo used Scheme-C.
2 --- Bigloo --- It was written in Scheme, and compiled to C. There is
a version compiled to Java VM. I belive that there are core libraries
written in C, but they are very few, and most of them (possibly all?)
have Scheme-only options; for instance, SQL-light, and bignums, have
Scheme-only options.
3 --- Gambit-C --- I am not sure about this one. The distributed
sources are in C, but Stalin has C-sources too, but was written in
Scheme. It is possible that Gambit-C was written in Scheme and
translated to C using a previous version of the compiler. In the case
of Stalin, people use other Schemes to perform the translation. I have
seen people using Scheme-C, Gambit, Bigloo, or Chicken to compile
Stalin. For instance, Chicken team has a Stalin distribution compiled
with Chicken, what I think is very nice of them: If you want a very
complete Scheme to do things like GUI, use Chicken; however, if you
want sheer speed and small memory footprint, you can compile part of
your program with Stalin.
4 --- Larceny --- This is the fastest Scheme if you need to run code
on the fly. For instance, if you work with that kind of optimization
problem that needs to generate code, and test the generated code (like
in especulative programming, adaptative filtering or genetic
programming), I noticed that Larceny can make Bigloo bite the dust.
Interesting that I discovered this fact only four days ago. I noticed
that Gambit and Bigloo are 2.6 times faster than Larceny for numerical
calculations. However, when it comes to adaptative filtering, Larceny
becomes 30 times faster than other Schemes for Windows. Since I do not
know much about adaptative filtering, genetic programming or Scheme, I
cannot tell you why Larceny is so good for certain jobs, and not so
good for others. One explanation is that I do not know how to deal
with numbers in Larceny, and do not know how to deal with adaptative
filtering and genetic programming in Gambit. By the way, I downloaded
the sources of Larceny from http://www.ccs.neu.edu/home/will/Larceny/download.html.
They are written in Scheme.
Conclusion: In 4 Schemes, 3 are written in Scheme. It is possible that
Gambit, the fourth one, is written in Scheme too.
Changying Li
Thanks again.
Aaron W. Hsu
>why are almost all of implementatin of scheme written in c?
I would argue that most of the major ones are written chiefly in Scheme.
Many use C as a portable basis for a small kernel, as a loader, or as an
intermediate language through which they compile their apps.
>is it possible to write a not very slow scheme compiler & intepreter in
>scheme-- not toy, but a real implementation?
See most of the fast compilers.
--
Aaron W. Hsu <arc...@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
Felix Klock
> I noticed
> that Gambit and Bigloo are 2.6 times faster than Larceny for numerical
> calculations. However, when it comes to adaptative filtering, Larceny
> becomes 30 times faster than other Schemes for Windows. Since I do not
> know much about adaptative filtering, genetic programming or Scheme, I
> cannot tell you why Larceny is so good for certain jobs, and not so
> good for others. One explanation is that I do not know how to deal
> with numbers in Larceny, and do not know how to deal with adaptative
> filtering and genetic programming in Gambit.
Will has been spending some time looking into bignum (and other)
overheads recently and taking notes. If you care to learn more, you
may want to skim over:
https://trac.ccs.neu.edu/trac/larceny/wiki/WhyMillicodeIsSlow
The 0.97 bignums should be much faster than the 0.96 ones.
There are other potential reasons for why Larceny's numerics are not
as fast as in other systems (e.g. here is a reasonable one that has
floated around for a while: many systems delegate bignum computation
to GMP ( http://gmplib.org/ ) and that is more highly bummed than
Larceny's bignum implementation. I am sure there are many others.)
-Felix Klock
comp.lang.scheme
> Larceny's bignum implementation. I am sure there are many others.)
>
> -Felix Klock
Hi, Felix.
That is exciting news! If Larceny will deal with number efficiently,
then it will excell in everything. I have one question however. Are
other Schemes trying to play catch with Larceny in problems that
requires the use of eval? I mean, can I expect Bigloo to be as fast as
Larceny when dealing with genetic programming? I do not mind about
learning Larceny, but I prefer Bigloo, because it does not require
loading libraries and stuff. There are many people around here who are
using genetic programming and adaptative filtering. In this kind of
problem, Larceny beats Bigloo badly. I suppose that Bigloo team and
Gambit team can easily check Larceny eval, and implement something
equivalent in Bigloo and/or Gambit.
William D Clinger
> Conclusion: In 4 Schemes, 3 are written in Scheme. It is possible that
> Gambit, the fourth one, is written in Scheme too.
Yes, Gambit also is written mostly in Scheme.
Felix Klock wrote:
> The 0.97 bignums should be much faster than the 0.96 ones.
More relevant here is the fact that flonum-specific
operations will be somewhat faster in Larceny v0.97 than
in v0.97b1.
> There are other potential reasons for why Larceny's numerics are not
> as fast as in other systems...
For floating point calculations, Stalin, Bigloo, and
Gambit are probably the three fastest implementations
of Scheme. MIT Scheme, Chez Scheme, Ikarus, Larceny,
and maybe Chicken would form the second tier.
Compiling directly to machine code, as in Larceny, is a
lot faster than compiling to C and then going through a
C compiler. That may be why Larceny was faster than
Stalin, Bigloo, and Gambit for problems that "generate
code, and test the generated code".
From his description of adaptative filtering, it sounds
as though the problem is inherently higher order and so
dynamic that static flow analysis doesn't help much.
Larceny's representations of closures aren't super, but
they're still within a small constant factor of being
optimal for the general case, which means no other system
is likely to do much better than Larceny on that kind of
program.
It's also possible that his program is calling eval on
dynamically constructed list structures, which would give
Larceny a huge advantage because it JIT-compiles eval'ed
lambda expressions to machine code, while the other
systems presumably use an interpreter. That might very
well make Larceny faster by the observed factor of 30.
Will
William D Clinger
> I have one question however. Are other Schemes trying to
> play catch with Larceny in problems that requires the use
> of eval? I mean, can I expect Bigloo to be as fast as
> Larceny when dealing with genetic programming?
Not if you're relying on eval. To compete with Larceny's
eval, a system would have to JIT-compile eval'ed lambda
expressions to machine code. That isn't practical unless
the compiler is reasonably fast, which pretty much limits
the technique to a handful of implementations that compile
to machine code without having to go through an external
compiler: Chez Scheme, Ikarus, Larceny, and PLT Scheme.
Some of the JVM- or CLR-based implementations may provide
a JIT-compiling eval, but none of those systems are as
fast as native Larceny.
OTOH, it is possible to implement genetic programming using
closures instead of eval. If you were to do that, then
Stalin, Bigloo, and Gambit would probably perform about as
well as Larceny.
Will
Shiro Kawai
is written in Scheme, and Gauche's VM is written in a DSL using
S-expressions that translates into C.
What I mentioned about interoperability is for core runtime routines.
--shiro
Michael Sperber
"comp.lang.scheme" <phi5...@yahoo.ca> writes:
> I use four Schemes, that I checked to be much faster than the others.
> Three of them are written in Scheme, not in C. They are: [...]
> 2 --- Bigloo --- [...]
> 3 --- Gambit-C --- [...]
> 4 --- Larceny --- [...]
Last I looked, the run-time systems of these Scheme systems (or at least
the largest portion of them) were written in C.
leppie
> Some of the JVM- or CLR-based implementations may provide
> a JIT-compiling eval, but none of those systems are as
> fast as native Larceny.
IronScheme does that, so eval is just as fast as IronScheme's compiled
code.
I am currently in the process of rewriting almost all of my runtime
code from C# into Scheme (which does not seem to be hard at all!).
With my future planned version 2 of IronScheme, everything (possible)
will be written in Scheme, including the compiler and reader/parsers.
Perhaps at version 3, I can start looking into making it fast :) But
for now, completeness counts.
Cheers
leppie
Alex Queiroz
On Mar 26, 6:52 am, Michael Sperber <sper...@deinprogramm.de> wrote:
> "comp.lang.scheme" <phi50...@yahoo.ca> writes:
> > I use four Schemes, that I checked to be much faster than the others.
> > Three of them are written in Scheme, not in C. They are: [...]
> > 2 --- Bigloo --- [...]
> > 3 --- Gambit-C --- [...]
> > 4 --- Larceny --- [...]
>
> Last I looked, the run-time systems of these Scheme systems (or at least
> the largest portion of them) were written in C.
>
Most of the Gambit-C runtime is also written in Scheme: I/O,
bignums, threads etc. There is a small C core, though, which takes
care of things like memory management, for instance.
-alex
William D Clinger
> Last I looked, the run-time systems of these Scheme systems
> (or at least the largest portion of them) were written in C.
That is true only if you adopt a narrow definition of
"run-time system" that corresponds quite closely to the
portions of those systems that are written in C. Shiro
is the only previous poster in this thread who may have
interpreted the original poster's question so narrowly.
In all varieties of Larceny, most of the code is written
in Scheme.
For Larceny/IA32, if we arbitrarily exclude libraries
that are loaded dynamically (which excludes all R6RS
libraries), then the code that goes into the standard
runtime breaks down as follows:
Scheme code 82000 lines
C code file 24000 lines
C header files 2000 lines
assembly code 1000 lines
Counting dynamically loadable libraries such as R6RS
would add about 170000 lines of Scheme code, but only
a hundred lines of C code.
Common Larceny contains no C code at all, but contains
about 12000 lines of C# code.
Will
comp.lang.scheme
Since you seem to know so much about Larceny, I have a few questions.
However, I need to explain my approach to programming. I learned
Scheme from generic books, not from user manuals. If an implementation
requires me to read more than is "in the book", I tag it as "very
difficult", and drop it. Every program from Ierusalimsky book worked
out of the box on Larceny. However, I feel that I am not using a lot
of features. Here are things that I may be missing:
1 --- I have seen a lot of libraries that deal with GUI, macros, etc.
I do not know how to use these libraries. For instance, I wanted to
use match. Here is my first trial:
> (load "match.sch")
WARNING: Assertion is false: (\x2e;check! #f 1 '(1 2 3))
WARNING: Assertion is false: (\x2e;check! #f 1 '(1 2 3))
> (match 4 (?x (display ?x)))
4
>
I guess that it is not necessary to load the libraries the way I did.
2 --- I do not know how to build a standalone. It is possible that
Larceny does not generate stand alone files.
3 --- The below program does not work. I would appreciate if you could
help me with the error:
D:\larceny>type temacro.scm
(define-syntax incre
(syntax-rules ()
((incre x) (begin (set! x (+ x 2)) x))))
(define-syntax $
(syntax-rules ()
(($ v i) (vector-ref v i) ) ) )
(define-syntax $!
(syntax-rules ()
(($! v i b) (vector-set! v i b) ) ) )
(define (xeco x w)
($! w 1 54)
(* (incre x) ($ w 1)))
D:\larceny>larceny
Larceny v0.97b1 (beta test) (Aug 25 2008 10:57:44,
precise:Win32:unified)
larceny.heap, built on Mon 08/25/2008
> (load "temacro.scm")
> (incre 4)
ERROR detected during macro expansion:
Malformed assignment
(\x2e;set!\x7c;1 4 (\x2e;+\x7c;1 4 2))
#f
However, if I use the macro from a definition inside the file where it
is defined, it works:
> (xeco 4 '#(3 4 5 6 7 8 9 9))
324
>
William D Clinger
> Since you seem to know so much about Larceny, I have a few questions.
I am flattered. Thank you.
> 1 --- I have seen a lot of libraries that deal with GUI, macros, etc.
> I do not know how to use these libraries. For instance, I wanted to
> use match. Here is my first trial:
>
> > (load "match.sch")
I would guess that the match.sch file is not part
of Larceny's standard distribution, because
(require 'match) loads a definition that doesn't
behave like the file you loaded. If your question
has to do with how to suppress the warning messages,
however, then the answer is to incant
(issue-warnings #f)
at the beginning of your session.
> 2 --- I do not know how to build a standalone. It is possible that
> Larceny does not generate stand alone files.
That is true. I was disappointed by the response to
MacScheme's ability to build standalone applications,
so that has not been a high priority for Larceny. If
there is sufficient demand for that feature, however,
then we will add it as a request for enhancement.
> 3 --- The below program does not work. I would appreciate if you could
> help me with the error:
The macro definition of incre causes (incre 4) to
macro-expand into
(begin (set! 4 (+ 4 2)) 4)
which contains an assignment that is illegal in Scheme.
I apologize for the poor error message, which has long
been a known problem in Larceny, and has only gotten
worse in recent years [1].
> However, if I use the macro from a definition inside the file where it
> is defined, it works:
>
> > (xeco 4 '#(3 4 5 6 7 8 9 9))
The procedural definition of xeco invokes the incre
macro as (incre x), where x is a formal parameter of
xeco, so (incre x) macro-expands into
(begin (set! x (+ x 2) x))
which is legal in Scheme.
Will
Michael Sperber
William D Clinger <cesu...@yahoo.com> writes:
> Mike Sperber wrote:
>> Last I looked, the run-time systems of these Scheme systems
>> (or at least the largest portion of them) were written in C.
>
> That is true only if you adopt a narrow definition of
> "run-time system" that corresponds quite closely to the
> portions of those systems that are written in C.
Yes - this was to illustrate the difference between these systems and
Scheme 48. Most of that same "portion", in Scheme 48, is written in
Scheme.
> Scheme code 82000 lines
> C code file 24000 lines
> C header files 2000 lines
> assembly code 1000 lines
In the default development build of Scheme 48 under Unix, the C code
files add up to about 9600 lines. This includes 2000 for the bignum
code (not essential for the running of the system; an alternative
implementation in Scheme exists), and another 3000 lines for the FFI
infrastructure, and 1800 lines for the sockets interface. The VM itself
can run, in a limited fashion, completely in Scheme. In particular, the
GC is written in Scheme, which I believe is not the case for Larceny,
Gambit-C, or Bigloo.
William D Clinger
> In the default development build of Scheme 48 under Unix, the C code
> files add up to about 9600 lines.
Two thirds of Larceny's C code consists of instrumentation
and support for its interchangeable garbage collectors.
That is a legacy of Larceny's origins as a vehicle for
experimental research in garbage collection, which is
still going on.
If Larceny were changed to support only one hard-wired
garbage collector, and that collector were similar to the
one used in Scheme 48 (but implemented in C instead of
Scheme), then the amount of C code in Larceny would be
less than in Scheme 48.
> This includes 2000 for the bignum
> code (not essential for the running of the system; an alternative
> implementation in Scheme exists), and another 3000 lines for the FFI
> infrastructure, and 1800 lines for the sockets interface.
Larceny's bignums are implemented in Scheme, as is most
of its FFI and all of its sockets interface.
Will