Re: Scheme as a Common Intermediate Language

[Keisuke Nishida]

address@hidden (Carl R. Witty) writes:

> A common language run-time would be a very useful thing.  However, I
> fear that if your goal is to support "any high-level language" within
> a fairly small factor of optimality, that you're not there yet.

Yes, I know what I had in my mind was only a small fraction of languages,
and I am not very familiar with other languages.  Probably supporting
"any high-level language" is overambitious.  But,

> It seems likely that it will be difficult to compile languages that
> don't fit the standard imperative model into efficient iScheme.  Have
> you considered languages like Haskell and Clean (pure functional) and
> Prolog and Mercury (logic)?

The reason I considered iScheme to be a "parse tree" is because iScheme
primitives are not limited to those of Scheme.  Any set of primitives
that does not fit in the standard iScheme primitives can be added as an
extension to iScheme.

For example, someone might want to define iScheme/LOGIC, to which
Prolog-like languages can be translated.  The following Prolog code

  foo(abc).
  bar(X) :- foo(X).

might be translated into

  (@define-rule (foo 'abc) #t)
  (@define-rule (bar x) (foo x))

or something like that.  Then, an iScheme compiler that support this
logic extension may compile this code efficiently.  Once such a compiler
is written, we can use it from Scheme like this:

  (define-rule (foo 'abc) #t)
  (define-rule (bar x) (foo x))

  (let ((x (make-variable)))
    (bar x)
    (display (variable-ref x)))

This way we can share code between Prolog and Scheme.

My point was not to translate a language to Scheme, but to share a common
internal representation between languages.  If someone implemented a
Prolog compiler this way, she would not need to implement the common
functions, like arithmetic operations.  She can concentrate implementing
the logic evaluator.

The same thing can be said for other languages.  Once we have iScheme/
Haskell and iScheme/ML (sounds stupid), we are free to combine those
functionality into one language, though it will be a terrible language.

> Your static type system is not powerful enough to handle languages
> with ML-style polymorphism, let alone the more powerful extensions
> that have found their way into recent Haskell implementations.  Thus,
> compilers from these languages to iScheme would have to fall back to
> dynamic typing, with the concomitant loss in performance.

I am not sure about this.  There may be some way to get around this,
or may not.  But I suspect iScheme cannot accommodate everything.

> Have you heard about Microsoft's .NET platform?  Part of .NET is a
> common language run-time, using a specified bytecode language and a
> just-in-time compiler.  Interestingly, there are Haskell and Mercury
> implementations with .NET back-ends, although I haven't heard anything
> about how fast the .NET code is compared to native-code back-ends (and
> I don't know whether they use .NET static typing or dynamic typing).

I didn't know that.  Hmm, probably that's the way people will go.  Maybe
I'm killing my silly project..

Thanks,
Keisuke Nishida