LANGOWSKI@FREMBL51.BITNET (Joerg Langowski / EMBL Grenoble) (03/19/90)
A while ago, Bob Loewenstein <rfl@oddjob.uchicago.edu> posted a note on this
board about his extensions to NEON, a Forth-based OOP system for the Mac.
People on this board might recall that NEON was originally developed by Kriya
Systems, who don't support it any more; a sad fact that everyone regrets who
ever used this excellent product.
I recently received a letter from a MacTutor reader in Australia who doesn't
have access to E-mail systems and thus asks that his letter be posted. (The
letter was originally sent to Bob Loewenstein). His name and address:
Michael Hore
5/137 Elouera Rd.
Cronulla, NSW 2230, Australia
The copy of Mike's letter follows:
"Dear Bob,
I've just read your comments on NEON in the October issue of MacTutor (which
takes a while to arrive on the newsstands here). I was amazed (and delighted)
to see that there are still a number of folks using NEON - I thought I might
be the only one! I have always thought that this was the most underrated
development system for the Mac. A good product with potential to be a great
one, but torpedoed by a marketing strategy which bordered on the nonexistent.
I also found no problem running on a Mac II - my personal finances don't run
to one, but I had a report that an application that I wrote in NEON worked OK
on a Mac II. Like you I kfound I had to set a larger stack size than the
default - unless I set at least 7K I got random crashes, usually during
Standard File calls. Maybe this was the cause of the problems others ran into.
I also started to develop NEON, but thinking I was about the only user I took
a more radical line than you - I completely reimplemented the nucleus from
scratch. It now compiles subroutine-threaded code, with optimized native code
for common sequences. The result is that applications run 4-5 times faster,
and are about 10% smaller. The compilation speed is now over 1000 LPM. The
whole assembler compiles in about a minute. I've also introduced quite a few
improvements to the high-level code - at least I think they are improvements.
Multiple inheritance, for example. I thought the changes were radical enough
to justify a change of name, so now I'm calling it Mops (Michael's
Object-oriented Programming System!)
My understanding of copyright legalities is that the Mops nucleus, being
completely new, would not violate Kriya's copyright on NEON. That is unless a
language, as such, is copyrightable, rather than the specific code which
comprises a specific implementation. I think it probably isn't copyrightable,
but I'm not a lawyer. But since I haven't changed all the high-level code,
Kriya still definitely hold the copyright to that (unless you were able to
persuade them to release it into the public domain - how did you get on?). But
I'm quite happy to send Mops to anyone who has NEON, since that doesn't
involve legal problems. In any case, I don't have the time or inclination to
document Mops from scratch for someone unfamiliar with NEON. I will produce a
file listing the changes between Mops and NEON, if anyone wants Mops. If I'm
the copyright holder on the Mops nucleus, my only conditions are that it not
be used for commercial purposes without my permission.
So if you or any other NEON users are interested in giving Mops a try, just
write me, or better, send me a disk with some of your NEON developments on it,
and I'll send it back to you with Mops. Sorry for the horse and buggy method,
but distance precludes electronic transfer. Perhaps you could do me a favor
and post some of this letter on some appropriate bulletin board, in case
anyone might be interested.
Of course, if your NEON code makes much use of implementation details of NEON,
like expecting certain things to be at CFAs or whatever, it won't work under
Mops without rewriting. Also, I took a different line on floating point.
Actually, this was only experimental since I don't need FP in my work - it's
all string handling. NEON FP is very implementation-dependent, so a fair bit
of work would have to be done to get existing FP code to work under Mops. But
it certainly could be done.
Apart from that, the main differences from NEON are in the direction of
improving the error checking, and also in bringing the underlying Forth more
in line with Forth 83 and the forthcoming ANSI standard. Most of the necessary
changes to NEON code can be done semi-mechanically. I found the most
troublesome was the change in boolean "true" from 1 to -1. If you don't often
do arithmetic on booleans, you won't have much trouble.
I've also tried to make Mops 32-bit clean, and it seems to work OK on new
Macs. At least it worked on a friend's SE/30 (which cheered me up, and
slightly compensated for the green colour of my face).
I haven't had time yet to update all the various NEON utilities, or the
classes that I don't actually use. But I have updated all the standard stuff,
implemented a modeless dialog class, and written a new decompiler/debugger. I
also have code that will read and write formatted Microsoft Word documents, if
that's any use to anybody."
-------------------------
If anyone is interested in getting the Mops code, mail Michael Hore a disk.
Please, comments - I'd like to see a revival of NEON.
+----------------------------------------------------------------------------+
| Joerg Langowski Bitnet/EARN: LANGOWSKI@FREMBL51 |
| European Molecular Biology Lab Applelink: LANGOWSKI.J |
| Grenoble Outstation MACTUTOR |
| c/o ILL, 156X Calvacom: JL10 |
| F-38042 Grenobyl Cedex GEnie: J.Langowski |
| France analog: +33-76487306 |
+----------------------------------------------------------------------------+
| "C++ is the Forth of the 90's - |
| they don't call it OOPS programming for nothing" |
+----------------------------------------------------------------------------+