Fwd: [plt-scheme] Volunteers: help with Moby!

>> I'd be glad to help out. I suppose the most suitable might be the
>> translation of primitive functions, to get into the project, if you
>> agree.
>>
>> Also, would it be possible to get some more background information?
>> I checked out the project, ran the test suite, read the README
>> etc., but I'm still a bit unclear about the general purpose: Why a
>> source-to-source compiler? mzc already compiles to bytecode, why
>> not simply use this (plainly asked ;-) )

Hi Sigrid,

We're emitting Java source because it's fairly simple, and the
approach interacts more compatible with the components of our
toolchain.  i.e. the Android virtual machine uses bytecodes altogether
different from mzscheme's (and from the JDK, for that matter!).

One other point against bytecode translation is that mzscheme's
bytecodes are a moving target, and as far as I can tell, Android's
bytecodes are undocumented and subject to change at whim.  Our
approach, to translate to a single output language (Java), is simpler
than writing translators between different bytecodes whose definition
languages have a good chance of changing on us.

The other restriction we're up against is J2ME, whose API is more
restrictive than the full Java J2SE API.  Existing Scheme to Java
compilers assume they've got all of J2SE; we don't, since we're
targeting mobile devices.  We're also a bit specialized because our
applications will be based on the World paradigm.



>> Then, about the source translation itself, are the essentials of
>> how the translation to Java is done described somewhere - perhaps
>> in some scientific publication you could mail me?

The translation is dumber than you might expect.  :)
src/beginner-to-java.ss does as standard pattern matching against the
Beginner Level scheme grammar.  The techniques are well known; you can
learn more about them from a book like PLAI:

http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/



>> And is this translation based on some other, preexisting
>> scheme->java compiler, or is it independent? In fact this lets me
>> clarify my question from above - I should have thought there must
>> be quite some scheme->java compilers already?

Independent.  There are existing scheme->java translators out there; I
know of Bigloo off the top of my head, and I'm aware of Kawa as
well. Both of these introduce dependencies to their respective
runtimes and J2SE primitives, and might not fit into the constraints
of the mobile platforms we're aiming at. In any event, even if it did
fit J2ME, a JVM bytecode approach isn't amendable with the Android
toolchain, which requires Java source to process to its proprietary
format.

Since we're working with a restricted subset of the Java API, we
wanted full control of how that translation worked.  If it turns out
that we can reuse an existing translator, with fine-grained control
over how that translation works, we can swap that component out.  But
this is a secondary concern.  Your next question brings up the primary
one:


>> Perhaps this assumption was totally wrong - or perhaps most
>> directly compile to bytecode, and the speciality of this project is
>> exactly the translation to Java source?

The focus of our work isn't actually about the Scheme->Java stuff: the
more interesting stuff will be: how do we naturally expose features
that are specific to cell-phones and other mobile devices?  Things
like handling the accelerometer, or the location service, or
touchscreens, those will be the avenues that we'll be working on in
the immediate future.



>> (Please don't get angry on my plain questions ;-) , I just want to
>> "get" the main things about the application)

No problem!



>> [[[As an example of why I'd like some background on the compiler
>> implementation, I just played around a bit and entered
>>
>> (program->java-string '(+ 2 3))


Oh!  There's a comment in src/beginner-to-java.ss that should explain
what happened.

   ;; A program is a (listof (or/c defn? expr?))

The input that you gave isn't either of those.  :) To do what you
really wanted:

  (program->java-string '((+ 2 3)))

would be it.



>> in drscheme, and the output
>>
>> "static { org.plt.Kernel.identity(org.plt.Kernel._plus_); }\nstatic {
>> org.plt.Kernel.identity((new org.plt.types.Rational(2, 1))); }\nstatic {
>> org.plt.Kernel.identity((new org.plt.types.Rational(3, 1))); }\n"
>>
>> is not too clear to me...]]]

It's garbage in, garbage out.  You should have gotten a contract error
here, if not for my lax contracts.  It serves me right for not putting
the right contracts on those functions.  I'll fix this tonight.


If you have more questions, please feel free to ask!