A toplevel for Dylan? 
Author Message
 A toplevel for Dylan?

One thing that has impressed me about certain ( functional )
programming languages, that is that they come with a combination
of a toplevel ( interpreter ) and a compiler ( not a bytecode
compiler, a real compiler ).

This leads to more effective coding because I can interactively
develop and then when I am done either produce a more efficient
program by compiling ( if I am compiling an application, of course )
or I can produce a more efficient libray which gets incorporated into
the toplevel. At the same time I have all the advantages of an
interpreted language.

Probably the language which most effictively uses this technique is
OCaml, but close behind are Haskell and SML, along with
some Lisps.

Do Dylan environments come with this feature?
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.



Sun, 18 Dec 2005 12:20:51 GMT  
 A toplevel for Dylan?


Quote:
> One thing that has impressed me about certain ( functional )
> programming languages, that is that they come with a combination
> of a toplevel ( interpreter ) and a compiler ( not a bytecode
> compiler, a real compiler ).

> This leads to more effective coding because I can interactively
> develop and then when I am done either produce a more efficient
> program by compiling ( if I am compiling an application, of course )
> or I can produce a more efficient libray which gets incorporated into
> the toplevel. At the same time I have all the advantages of an
> interpreted language.

> Probably the language which most effictively uses this technique is
> OCaml, but close behind are Haskell and SML, along with
> some Lisps.

> Do Dylan environments come with this feature?

Functional Developer does.  Gwydion does not, alhough there is some work
being done on one.  I'd like to use the approach taken by "goo" (which
was implemented largely by one of the people who rescued Gwydion when
CMU stopped working on it), but others have other ideas, such as parse
tree interpretation.

Marlais is a Dylan interpreter with a toplevel.  It is however quite out
of date with respect to language features and standard libraries.  I've
used it in the past to quickly develop code later compiled (or even
translated into C!)

-- Bruce



Sun, 18 Dec 2005 19:00:14 GMT  
 A toplevel for Dylan?

Quote:



> > One thing that has impressed me about certain ( functional )
> > programming languages, that is that they come with a combination
> > of a toplevel ( interpreter ) and a compiler ( not a bytecode
> > compiler, a real compiler ).

> > This leads to more effective coding because I can interactively
> > develop and then when I am done either produce a more efficient
> > program by compiling ( if I am compiling an application, of course )
> > or I can produce a more efficient libray which gets incorporated into
> > the toplevel. At the same time I have all the advantages of an
> > interpreted language.

> > Probably the language which most effictively uses this technique is
> > OCaml, but close behind are Haskell and SML, along with
> > some Lisps.

> > Do Dylan environments come with this feature?

> Functional Developer does.  Gwydion does not, alhough there is some work
> being done on one.  I'd like to use the approach taken by "goo" (which
> was implemented largely by one of the people who rescued Gwydion when
> CMU stopped working on it), but others have other ideas, such as parse
> tree interpretation.

> Marlais is a Dylan interpreter with a toplevel.  It is however quite out
> of date with respect to language features and standard libraries.  I've
> used it in the past to quickly develop code later compiled (or even
> translated into C!)

The internal Apple version of Dylan in use circa 1992 had a very
lisp-like toplevel. In fact, its development environment was a
heavily-hacked version of Macintosh Common Lisp (called "Leibniz"),
with a full Common Lisp that compiled code for 680X0 and a full Dylan
implementation that compiled code for the ARM and provided a fairly
full complement of development tools in the MCL mold.

However, Dylan at that time looked a lot more like Lisp in other ways
as well.



Sun, 18 Dec 2005 23:03:04 GMT  
 A toplevel for Dylan?

Quote:

> The internal Apple version of Dylan in use circa 1992 had a very
> lisp-like toplevel. In fact, its development environment was a
> heavily-hacked version of Macintosh Common Lisp (called "Leibniz"),
> with a full Common Lisp that compiled code for 680X0 and a full Dylan
> implementation that compiled code for the ARM and provided a fairly
> full complement of development tools in the MCL mold.

Ha!  So Apple really *was* aiming Dylan at the Newton!  That was always
a rumour, but this is the most confirmation I've seen.

Even if the all-powerfull Dylan compiler wasn't ready in time, I wonder
why they didn't go with byte-coded Dylan instead of byte-coded
NewtonScript?  NewtonScript is pretty cool, and delegation (vs
inheritance) has a long and honourable history in OO GUI programming,
but I think Dylan would have been better.

-- Bruce



Mon, 19 Dec 2005 03:02:43 GMT  
 A toplevel for Dylan?

Quote:


> > The internal Apple version of Dylan in use circa 1992 had a very
> > lisp-like toplevel. In fact, its development environment was a
> > heavily-hacked version of Macintosh Common Lisp (called "Leibniz"),
> > with a full Common Lisp that compiled code for 680X0 and a full Dylan
> > implementation that compiled code for the ARM and provided a fairly
> > full complement of development tools in the MCL mold.

> Ha!  So Apple really *was* aiming Dylan at the Newton!  That was always
> a rumour, but this is the most confirmation I've seen.

> Even if the all-powerfull Dylan compiler wasn't ready in time, I wonder
> why they didn't go with byte-coded Dylan instead of byte-coded
> NewtonScript?  NewtonScript is pretty cool, and delegation (vs
> inheritance) has a long and honourable history in OO GUI programming,
> but I think Dylan would have been better.

The Dylan compiler was more than ready. It generated very good, very
fast native machine code for the ARM, and the development environment
was very nice.

It had a couple of things working against it:

- the minimum runtime image of the Dylan version of the OS was too
  large a fraction of the Newton's available RAM; the image would fit
  in the unit as designed--barely. This was before Newton had been
  released, and the team was trading off a large number of variables
  on a brand new platform, trying to find the right balance of screen
  size, battery life, form factor, price, and so on. In the end,
  Apple didn't get it right, but it's not clear that increasing the
  base RAM (and therefore price) would have improved things

- no Dylan support for threads or processes. Implementing them was
  in the pipe, but not likely to get done on the right schedule.

- one Dylan-based (actually 'Ralph'-based -- Dylan didn't get its
  final name until relatively late in development) version of the OS
  had already been declared unsuitable; the one I worked on was the
  second, and was staffed by only five people, while about 60 people
  were working on the C++ version that was eventually released.

NewtonScript was largely the inspiration of Walter Smith and Steve
Capps; Walter was familiar with frame languages and when folks told
Steve about them he them they were cool enough to implement for
Newton. The objective was to recapture some of the flexibility lost
when Dylan was abandoned, while building on a C++ foundation.

There were some neat architecture ideas in the second Dylan version
of the Newton OS.



Mon, 19 Dec 2005 03:48:07 GMT  
 A toplevel for Dylan?

Quote:

> The Dylan compiler was more than ready. It generated very good, very
> fast native machine code for the ARM, and the development
> environment was very nice.

With the number of ARM based PDA type devices out there now it's a
shame it can't be resumed.

Chris.



Mon, 19 Dec 2005 12:09:45 GMT  
 A toplevel for Dylan?

Quote:


> > The Dylan compiler was more than ready. It generated very good, very
> > fast native machine code for the ARM, and the development
> > environment was very nice.

> With the number of ARM based PDA type devices out there now it's a
> shame it can't be resumed.

Someone (maybe Andreas Bogk) asked me whether Apple might open-source
the code, so I contacted their open-source coordinator. They said
'nope; we only do code that's currently being maintained.'


Mon, 19 Dec 2005 13:32:34 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)

2. toplevel in another toplevel as virtual root

3. Toplevel -container / Toplevel -use does not work ??

4. Killing child toplevel of paent toplevel

5. archives of info-dylan/comp.lang.dylan available

6. Dylan vs DyLan

7. (fwd) harlequin's dylan-corba mailing list switching to MIT's info-dylan

8. lazy.dylan 0.1 -- add ML/Scheme-style lazy evaluation to Dylan

9. Dylan and Java [was: Harlequin Dylan - Update]

10. Dylan Programming Book and Apple Dylan

11. Dylan, guys, Dylan.

12. Dylan is the Name was(Re: Dylan (Bob) eats rotten Apple (Computer))

 

 
Powered by phpBB® Forum Software