Re: dylan revival

[address@hidden (marc)]

robmyers@mac.com wrote in message news:<200204032101.QAA11783@life.ai.mit.edu>...
> On Tuesday, April 2, 2002, at 01:00 PM, marc wrote:
> 
> > - new devices (e.g. symbian-os based smart-phones) open a new
> > mass-market
> 
> Possibly Marlais is small enough to fit on a mobile device? I don't know 
> how low we can get the footprint of an OODL with multiple dispatch and 
> GC.

Well, Suns KVM requires only 128 kB Heap on a Device to run Java (kind
of an OODL ;-) Of course, this restricts the set of useful
applications somewhat, nevertheless there already exist some quite
nice programs which execute on cheap mobile phones:
http://www.midlet.org

Java achieves this low footprint by:

- defining a subset of the standard runtime for small devices (e.g.
CLDC does not support floats and the java.lang and java.util packages
contain only basic classes).

- using a virtual machine (bytecodes are by far more compact than
native-code (anyone knowing of a verified factor though?))

I also don't think that any of dylans advanced features (macros,
multi-methods, closures, ...) would prevent it to run in limited
environments.


> > - establish as best in class environment for emerging WebServices
> > world
> 
> We have XML, XML-RPC, a web page system and a Web Server available, as 
> well as database access libraries and (on Functional Developer) COM and 
> CORBA. We just need more people using them. :-)
> 

So is anyone 'porting' XML-RPC to SOAP?

What would be also needed for WebServices is an easy way to 'export'
functions as WebMethods like in c# (ughh, yes):

[WebMethod]
public int getReason () { return 42; }

-> generates SOAP stubs/skeletons as well as the appropriate WSDL-file
entries.

So, a dylan (macro) lib allowing equivalent (or superior) ease of use
would be of great help.


> > - develop a dylan-to-clr compiler (knowing that clr is quite
> > unapropriate for a closure and generic-function based langauge like
> > dylan)
> 
> CLR is going to be a major time and resource waster for languages that 
> cannot compete with VB and C-hash in terms of FUD and lock-in. Dylan 
> would do much better to side with Apache and open web services.
> 

You might be true on this point - but see it in the following light:
Dylan needs attention from a much bigger audience to survive, so the
deal is like this: announce and deliver some CLR port and get all the
indirect marketing for dylan from M$ for free!

If the clr porting would just be a 'side-effect' of a more general
project extending the compiler/vm-portfolio of dylan we could have the
best of both worlds.

Comming back to my first statement of this posting, I think a
dylan-virtual-machine would be something worth investigating. This
could potentially allow dylan to run on:

- small devices
- any os the dvm is ported to
- clr
- jvm

with different backend-modules:

dylan-source-code 
  -(d-to-dbc-compiler)-> dylan-byte-code 
    -(dbc-to-clr-compiler)-> clr
    -(dbc-to-jvm-compiler)-> .class
    -(dbc-to-c-compiler) -> c
    -(dbc-in-dylan-interpreter) {dvm written in dylan (such one was
reportedly developed at Harlequin by Tony Mann and Eliot Miranda)}
    -(dbc-in-c-interpreter) {portable dvm written in c (or via d2c)}

What is the current thinking about a dylan-virtual-machine in this
group?

cheers
marc