[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU and MzScheme's Internal design



   Hi, you wrote:

> I was being sarcastic.  So sarcastic, in fact, that you seem to have
> taken my response literally.

    I knew you were :).  I just wanted to explain that I had
reasons behind my wanting a relatively efficient interpreter.
I did nto get too much into details is that -- it is probably
pretty boring stuff to this group (who seem to be scarily bright and
up to date on all recent major software system developments),
and mostly unrelated to MzScheme or Scheme for that matter.

> My point is that the issue of "efficient compilers" is so broad and
> ill-defined that, for the questions you posed, even a patently
> nonsensical answer would suffice.  It is still wholly unclear to me
> why you need to be modifying MzScheme at all.

    I think you'd agree MzScheme is a great library, right?
Nonetheless, people would like to modify it for different purposes --
Some would like to use it for embedded systems, and some would
like to use it for extending their existing set of tools.  Whatever
the application, there are differing degrees of modifications that need to
be
made.  Some who simply want to extend MzScheme with extra c++/c operations
only need to add/write extra primitives and link them.

    Some would like to do play just a bit more with way the language is
compiled -- for me, instance, I wanted to perform
distributed compiling.

    You *might* ask why, so here is a brief description of the system
I am concerned with.

    This "thing" I am building
 is a client-servers system in which
a client can request a given set of servers to create
distributed objects for XML
processing (transactions, filtering, etc).

     The distributed XML processing objects are CORBA
objects -- but they are bound to Scheme environment of
each scheme virtual machine.

    When the each SchemVM receives a script from the client,
one must compile and run that code.  One way of doing this is to
have the client transmit bytecodes.  Another way, which I am looking into,
involves direct compilation of the client requests
without going through bytecode generation/transmission.  This
is nice for several reasons (whose boring details
I won't elaborate).

    With respect to MzScheme, this means, to incorporate it into
my current xml project, I have to rip the guts out of MzScheme compiler and
wrap
them in CORBA objects that take remote calls.  Modifying MzScheme for
this, I think, would have required simply too time and effort
at this point in my brief life.

     (You might ask, why not just use Java with RMI?   Let us
say that Java introduces its own
set of problems, which are well hidden)

    Anyways, this is just one aspect of it.

> I don't speak for my colleagues here, only myself, but I'm a bit
> disappointed that you would use this list merely as a resource to get
> answers to difficult questions you have.

    I didn't think this list merely as a "resource" to take advantage of --
I had taken MzScheme mailing list as the "place" where people exchange
helpful ideas about MzScheme and in so doing, benefit each other.  (In the
past,
I think  I tried to "contribute" -- if you just go back and read my email
about
define-syntax, you'd see that I I tried to be helpful by porting Clinger's
code --
 even though I ended up embarassing myself more than anything).

> I wish you would look into constructive ways of collaboration instead.

    I think what you are saying is "(1) use PLT scheme,
and (2) contribute, in the good spirit of exchange (also
don't reinvent the wheel and waste your time)."

    Hopefully, in the future, I have opportunities to contribute
to your library set.  I am certain that some of my Scheme related code
will be easily portable to MzScheme, with few minor changes -- so
I will submit them for your consideration.

> The Scheme world has
> absolutely no need for additional implementations with their own
> little deficiencies and non-standard quirks.

    I agree with you whole heartedly -- but I was not trying to write a
scheme
interpreter for the world.  I just needed a small subsystem with
interpretive
powers.  MzScheme was "too powerful"  for this purpose.