First off, does the x86 solaris binary for SBCL work? You can bootstrap off that...

Annatar · on Aug 10, 2016

First off, does the x86 solaris binary for SBCL work? You can bootstrap off that if it does.

One of them didn't work for either i86pc (that's what we call the x86 and x86_64 platform on Solaris) or sparc, and my requirement is that it has to build and run on both exactly the same, as 50% of my server park is UltraSPARC, and 50% various forms of intel-based processors. But I'd have to look at that again. Something didn't work, or else I would be running SBCL by now.

While Guile uses ELF, it uses it as its bytecode format, and while native compilation is planned, we probably won't get it for a good few years. Chibi is bytecode, and will probably stay that way, although it has a decent FFI.

Now see, that is a severe step back for me: I had bytecode back in 1984, except then the "virtual machine" was called "Commodore BASIC", and "bytecode" was known as tokens, which is what they really are when you learn about AST parsers and trees in computer science at the university. So when I see "bytecode", that's a throwback. And a very bad, bad throwback, masked with pure brute force in terms of massive amounts of memory and processing power. It was a very bad and inefficient, slow solution then, and even with all this processing power and memory, it's a very bad and inefficient, slow solution now. I have never, and will never tolerate that. No amount of programming pleasantness and syntactical sugar will change that.

The way forward is clear to me now: ANSI Common LISP.

qwertyuiop924 · on Aug 10, 2016

...Did you miss the 1/2 of my post where I talked about two of the best native-code compilers scheme had to offer? Gambit and Chicken are both fantastic, and compile to C, no bytecode anywhere.

Also, your understanding of bytecode is deeply, deeply wrong. It's accurate to an extent, true, but Bytecode isn't the same thing as an interpreter, and can be much faster.

But even if bytecode is unacceptable to you, as it does indeed sacrifice performance and I won't deny that, I just gave you 2 native code compilers.

Did you just not notice that, or is there a reason you found them unacceptable?

Annatar · on Aug 10, 2016

I managed to miss it! FAIL.

Based on what you wrote, Chicken is out - I want reentrant.

...

I got Gambit to compile, simple expressions appear to work - but I cannot figure out how to compile them to a binary executable.

  cat t.scheme
  (define Hello "Hello")
  gsc t.scheme
  file t.o1 
  t.o1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available
  ./t.o1
  Segmentation fault (core dumped)

...so that needs more research. I also haven't tested on sparc.

qwertyuiop924 · on Aug 10, 2016

First off, the standard extension for scheme files is .scm

Not really relevant, but I thought you'd want to know.

Since Chicken's non-reentrance only matters if you're passing callbacks into C code, I'll assume you're doing that. It should be noted that Chicken can sort-of have callbacks, so it may be acceptable for your use-case. Either way, be careful to return from C calls in the same order you entered them: not doing so will crash your program. It might seem hard not to do this, but call/cc makes it very easy, and having another thread return into C causes the same problem, since scheme execution threads are pre-emptive coroutines, and are thus one thread from C's perspective.

The problem with the code above is that by default, Gambit generates a shared library for use in other compiled scheme code or a repl. To get an executable, you must specify -exe:

  gsc -exe t.scm

Note also that Gambit's configure script option page (http://gambitscheme.org/wiki/index.php/Configure_script_opti...) provides some handy options to feed to the configure script to speed up the interpreter, notes the reccomended use of GCC (although GCC is not necessary!), and also specifies how to use Sun's compiler to generate 64-bit code on SPARC architectures, if you want to do that. If you're using GCC, this shouldn't matter.

Also, I'd reccomend reading both gambit's manual and the R5RS standard. Knowing the standard and your implementation's deviations and extensions to it is important. Be sure to read the wiki as well, as gambit's manual is not as complete as the wiki.

schemers.org and the scheme wiki have a lot of aids for learning scheme, especially some of the stranger parts, like call/cc.

The Scheme Programming Language Third edition (not the 4th edition, which covers the much-maligned R6RS), and The Little/Seasoned/Reasoned Schemer series can help you think like a Schemer. Scheme is thoroughly multi-paradigm, so this is important.

Finally, there's a lot of gambit libraries all around. The Black Hole and SchemeSpheres module systems contain most of them, although some of SchemeSpheres is linux-specific. You may also take advantage of SLIB, one of the few portable scheme libraries, which contains a wide variety of handy utilities, and SXML, for processing and outputting HTML/XML without the hell.

Whatever you do, you'll probably have to write a lot of FFI code, because the library you want probably isn't wrapped. It's a little better in other schemes, mostly Chicken, but not really that much. It's just the price you pay for using a less popular language.