Path: utzoo!attcan!utgpu!watmath!iuvax!uxc.cso.uiuc.edu!tank!oddjob!rfl
From: rfl@oddjob.uchicago.edu (Bob Loewenstein)
Newsgroups: comp.lang.forth
Subject: NEON
Message-ID: <4707@tank.uchicago.edu>
Date: 28 Jul 89 15:32:30 GMT
Sender: news@tank.uchicago.edu
Reply-To: rfl@oddjob.UChicago.EDU (Bob Loewenstein)
Organization: U of Chicago - Astronomy & Astrophysics
Lines: 64


Kriya is no longer supporting Neon, as far as I know.  But we at
U of C are, having been involved with Chuck Duff and its development.
Kriya updated Neon up to version 2.0 which supported HFS, floating
point, and assembly; in addition, most of the bugs were fixed.

Since then we have created interfaces to color quickdraw and have 
developed image processing software on a Mac II.  The original
2.0 works on a MacII and SE030, and under multifinder; I think
this is testimony to Chuck and the others that created this
environment when 512 macs were just becoming widespread (prior
to Mac+'s).

Even though Kriya no longer supports it, it is easy to massage
it to keep current on newer macs and ROMS. It's simple to write
interfaces to new calls in the toolkit of the Mac. I look at Neon
as a great enhancement to Forth.  Forths have a tradition of
being supported by its users, and Neon is not unique in this.


kevinbe@microsoft.UUCP (Kevin Berg) writes:
> It might also be interesting for you to share some of the OO implementations
> that you find useful, or cumbersome, via example. I'm sure many others
> would be interested.

One example is color image support on a Mac II. If anyone has tried this
after reading the sections in IM V5, you know what I mean. A lot
of things need to be done for each image and window that is created.
By making an image class and a colorWindow class, with the appropriate
pixmaps and colortables as instance variables created when needed,
the whole operations becomes quite easy. Multiple images are just
multiple instances of the same class, which can be targeted to any
colorWindow object. I don't have to write specialized code for each
image, nor do I have to worry about creating the windowPalette, the
colorTable, etc. each time I create another image. In fact, it works
so nicely, I really have forgotton how things work since it's now part
of my system.

I don't have to handle button hits, menu hits, event queues...they are all
handled by the Neon system. It's relatively simply to affect global
changes deep in the system by small inheritances later on. 

Nicholas Geovanis writes:
> but filed and forgot about. Can anyone point me to a comprehensive source
> describing syntax and philosophy? How about commercial and PD interpreters?

Kurt Schmucker's book on object oriented languages and the Mac had
a section on Neon. It was prior to version 2.0. As I remember, he rated
it the fastest of all the implementations. This is partly due to the
fact that early binding is the default, with an option to late bind if
one wants.

We have thought of porting Neon to other machines. It doesn't seem
to be that difficult, just requiring some time to do the work.
Most of the code is at high level.

If anyone is interested, they could write me directly, or call.

Bob Loewenstein
Dept. of Astronomy and Astrophysics
University of Chicago
Williams Bay, Wi  53191

414-245-5555