
Orbit: An Optimizing Compiler for Scheme (1986) [pdf] - tosh
http://cpsc.yale.edu/sites/default/files/files/tr445.pdf
======
raattgift
This was [1986], citation details:
[http://dl.acm.org/citation.cfm?id=13333](http://dl.acm.org/citation.cfm?id=13333)

Rees maintains a related archive [most recently updated 2010] on his page at
[http://mumble.net/~jar/tproject/](http://mumble.net/~jar/tproject/)

That in turn links to Shivers's overview of T and the development of its
compilers (including Orbit) at
[http://www.paulgraham.com/thist.html](http://www.paulgraham.com/thist.html)

~~~
sctb
There are some more bits of T-ness here:
[http://mumble.net/~campbell/t/](http://mumble.net/~campbell/t/) related to
the T Revival Project, which itself is in need of reviving.

~~~
drdre2001
It says on the revival project page [1] that the plan was to make T R5RS
compatible. That is probably why they abandoned T to make Scheme 48 [2]

I am also interested in the revival of this language, but I don't see what the
point of that would be. Does anyone here feel the same way?

[1]
[http://web.archive.org/web/20070103020434/http://mumble.net/...](http://web.archive.org/web/20070103020434/http://mumble.net/~campbell/t/t.html)

[2] [http://s48.org/](http://s48.org/)

~~~
nickpsecurity
It was verified as part of VLISP project. So, I've been keeping papers on
PreScheme, Scheme48, and VLISP in case anyone wants to redo them with modern
techniques. Another commenter, hga, helped me find a few I didn't have before
with the specific algorithms. The basic ones are on the bottom here:

[https://en.wikipedia.org/wiki/PreScheme](https://en.wikipedia.org/wiki/PreScheme)

PreScheme itself is possibly worth reviving esp with ref counting or Rust's
type of no-GC safety. I know another LISP, Carp, is trying to do something
like the latter.

------
lisper
Interesting historical note: this is the compiler we used to program the
research rovers at JPL before the Sojourner mission. It compiled an object-
oriented dialect of Scheme called T which IMHO is one of the most elegant
programming languages ever designed. It is not almost totally forgotten, and
the world is poorer for it. :-(

(OakLisp is another beautiful riff on Scheme. Like T, it too has been all but
completely forgotten AFAICT.)

~~~
lsh
> It compiled an object-oriented dialect of Scheme called T

do you have a link for this? It's difficult to search for.

update: ignore me, found a link in the comments:
[http://mumble.net/~jar/tproject/](http://mumble.net/~jar/tproject/)

first line: "It occurred to me recently that The T Project had no coherent
presence on the web." :)

~~~
lisper
Also:
[https://en.wikipedia.org/wiki/T_(programming_language)](https://en.wikipedia.org/wiki/T_\(programming_language\))

------
sddfd
There is also Kelsey's 1989 popl paper, which explains the idea of compilation
as program transformation very clearly.

Kelsey and Hudak "Realistic Compilation by Program Transformation" POPL 1989

------
tammet
A similar Scheme-to-C project I wrote last century for the SCM scheme, should
be still usable:
[http://people.csail.mit.edu/jaffer/hobbit.pdf](http://people.csail.mit.edu/jaffer/hobbit.pdf)

One goal of the project was to produce human-readable C.

------
fizixer
\- Stalin WPO compiler:
[https://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)](https://en.wikipedia.org/wiki/Stalin_\(Scheme_implementation\))

\- Larceny:
[https://en.wikipedia.org/wiki/Larceny_(Scheme_implementation...](https://en.wikipedia.org/wiki/Larceny_\(Scheme_implementation\))

(Personally, I haven't explored any of these yet. I plan to get into scheme-
to-C compilation some day. I think it's the future of programming, but I might
be wrong.)

~~~
drdre2001
Why do you think scheme-to-C compilation is the future of programming?

~~~
fizixer
Scheme allows practically infinite possibility of language extension due to
its syntax (this is same with lisp and scheme, but I prefer scheme due to its
lexical scoping, a minimal standard like R7RS etc). (Note that I'm a big
advocate of Python-C hybrid programming too, and so for me it's either python-
and-C or scheme-and-C)

Moving towards Scheme-to-C is moving towards solving all
performance/concurrency/what-not problems of a high-level-language like
Scheme, without having to drop down to a low-level-language like C (or
assembly). (I guess I should say that there might be a need for generating
code for GPU, e.g., OpenCL. Just a heads up that I'm not trying to ignore
that).

What I say has to be qualified with two very important assumptions:

\- I believe 'large-scale programming' is 'research'. E.g., if the system
you're building is under 20k-50k lines of code, give or take, it largely
doesn't matter what paradigm you're using, or what language you're using. But
for larger systems, the best way forward is to treat such a complex system as
a research topic, and try to work at a higher level of abstraction, watch out
for opportunities of creating new DSLs, and so on. (I believe this is part of
the reason large projects do better in open source, firefox, linux, chromium,
etc, etc. No manager is watching over your shoulders with a stick and a
deadline on their notepad.).

\- You have to think in terms of meta-programming. It comes in many flavors
but take code-generation. Think of the whole purpose of your scheme code is to
let you generate human-readable C code. For me, meta-programming means never
having to write your program (here the program is the C code), but using tools
and machines that write the program for you (here the tool and the machine is
Scheme).

E.g., take a very large system like the linux kernel. It's 90% C with some
assembly. A big motivation for my ideas comes from asking the question 'Can we
develop and work at a high layer of abstraction in Scheme and create a code of
~100K to ~200K lines, that, using the ideas of meta-programming, compiles down
to ~20M lines of C code which is functionally equivalent, as well as equally
readable, to the current ~20M lines of the linux kernel?' (Note the scheme
code size being 1% of the C code size!)

When you think along those lines, and realize that 21st-century large-scale
programming is just getting started and something like a linux kernel is just
the tip of the iceberg, you probably would reach many of the conclusions and
beliefs that I gravitate towards.

Note that my ideas are in stark contrast to people who think the problem is
that we need a new programming language. In that regard, I'm anti C++, D, Go,
Rust, Swift, Kotlin, etc, etc. We don't need a new programming language. We
need to treat the activity of programming as a research activity. (again, I'm
talking about large-scale).

~~~
dTal
What does C get you, in the long run? Why not just compile Scheme to machine
code directly?

Note that Chez takes this approach, and is faster than Chicken, which compiles
to C.

~~~
peatmoss
Some apparently regularly updated benchmarks comparing implementations of
scheme: [https://ecraven.github.io/r7rs-
benchmarks/benchmark.html](https://ecraven.github.io/r7rs-
benchmarks/benchmark.html)

Chez isn't always the fastest, but it's the fastest so often that I wouldn't
look much beyond it if performance were of major importance to me. It's been
written about here on HN before, but the next major version of Racket will be
based on Chez. Chez will get package management, libraries, and modern tooling
of Racket, and Racket will (presumably) be able to capitalize on the
performance of Chez.

Of course if you come from, say Python, performance shouldn't really matter
much to you, as pretty much all the schemes are already playing in a different
league:
[http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=racket&lang2=python3)

------
aswanson
Can anyone recommend an ocr program that can convert these old pdf scans to
modern type?

~~~
ocrimgproc
ABBYY Finereader

