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

Hi Danny,

thanks a lot for the detailed explanations! That helped a lot.

I will also definitely read the PLAI book, in fact it's exactly
something I've been looking for!

[At the moment I'm in the middle of "Design Concepts in Programming
Languages", which I like a lot - even though it's been hard to get into
at first when you've never been a student of computer science but just a
self-taught career-changer and have never heard of "denotational
semantics" before -, it's very fascinating but what I was searching for
was also something more practical about parsing and compiling.
Which was why I just now started the Aho Compiler book in-between which
at least in the new edition seems more practical, but here I'm already
missing all the scheme/functional stuff I'm used to/addicted to since
SICP...
So I'll definitely read this now!]

Have a nice weekend and thanks again,
Sigrid


Danny Yoo schrieb:
>>> 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!
>
>