NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/forth/3054

Text File | 1992-08-29 | 10.8 KB | 239 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!starnine!mikeh
From: [e-mail] (Mike Haas)
Subject: Re: "Free" Forth is expensive
Message-ID: <[e-mail]>
Sender: [e-mail] (Mike Haas)
Date: Sat, 29 Aug 1992 07:24:41 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: StarNine Technologies, Inc.
Lines: 227

In article <[e-mail]> [e-mail] (Nicolas Tamburri) writes:
>[e-mail] (Mike Haas) replies to me who replied to him:
>> JForth's structure mechanism is sufficient to represent every standard
>> Amiga ".h" file (and there are a TON of 'em) in JForth ".j" form.
>> Even unions and enums are supported.  signed & unsigned members (which
>> infers auto-sign-extension).  and the only structure operators needed are
>> "s@" and "s!".
>>
>> It's not as good as C, but heaven for Forth.  Since you've used JForth,
>> you no doubt are aware that it provides a utility to do 90% of the
>> work in converting a ".h" file to it's equivalent ".j" for you.
>>
>> What more does Forth need?  (That, of course is a hypothetical
>> question, since most Forths do not contain any structure mechanism).
>
>Bearing in mind that I used version 1 JForth:  I remember that the
>struct mechanism did not really scope well, meaning that I could not
>have two structures with the same element names.

That is still a limitation.  But this is just a naming issue.  We adopted
the technique used in the Amiga assembler includes (assembler 'structures'
have the same limitation)... that is to use the same
standard prefix for different structures. For example, the
'width' element for a window and a screen...

   MyWindow s@ wd_Width
   MyScreen s@ sc_Width

As the assembler includes defined these for us already, we were assured
of standard, unique names, even the same ones that are documented
in Amiga tecnical literature.

>The convention was that
>one preceded the name of any element with a couple of characters related to
>the name of the structure they belonged to.

You have a good memory... that's what I describe above.  As I said,
these are not custom structure names, but standard Amiga-documented ones.
So it was more than just a forth-convention, it was a platform-OEM
convention.

>I also don't recall s@ and s! .

They came along in 2.0.  They do the same as ..@ and ..!, except that
they look at the structure element to see if is of type APTR, and
if so, automatically convert the returned address to JForth-relative
form (does the >REL for you, or >ABS on stores).

..@, ..!, s@ and s! all do auto-sizing (byte, word, or long) and (if
the struct element is signed) sign-extension.
>Did they exist in v1?  I assume that they know the size of the element, and
>store or fetch based on that, which is very good.
>
>Data structures have always been a limitation in Forth.  I don't see
>how it could really be fixed (in a standard way,)  without hacking up the
>interpreter to first look for a word, then a number and then try to parse
>a structure element along the line of struct.element.subelement.etc . I
>don't think too many people in this group would really go for that.

JForth's structure mechanism could be implemented in any
Forth with standard CREATE DOES> words, I believe.  The great benefit
is that the high-level interface is completely independant of the
platform specific hardware quirks, such as byte ordering, cell-width,
etc.

>
>> >I would be very hesitant to use many of the
>> >things which make JForth good because I know they are not portable to
>> >the PC, or Mac or Atari ST or just about anything else.  I'm not talking
>> >about screen library routines.  I know I'm going to have to write
>> >platform specific versions of those.  I'm talking about structure
>> >access routines, ODE, Amiga specific multi-tasking tricks.
>> >Things that are an inherent part of JForth and no other Forth.
>>
>> I don't see how.  First of all, you don't HAVE to use the fancy
>> aspects of any Forth, if your goal is to create base-line Forth code
>> that can move anywhere.  There IS FORTH under there, after all!
>
>Right.  my point exactly.  You've given me all this power, and I have to
>limit my use of it because it's not standard to any other Forth.  So what
>does all this functionality do for me.  For my money, I'd rather have the
>ultimate programming environment, than the ultimate number of libraries.
>I kind of like the way MachII approach to libraries on the Mac:  provide a
>generalized CALL word into the toolbox and let the user build only library
>interfaces needed for the application.

JForth provides the same CALL-type word to access the Amiga's libraries.
In fact, the Amiga is much better, because on the Mac, many of the
routines documented in 'Inside Mac' are marked "Not in Rom".  This means
you have to LINK the object into your application...so you know where
that leaves any Forth.  For example, you cannot call words like
TopMem(), MoveHHi(), PrOpen(), RamSDOpen(), Open & CloseDriver(),
StartSound()... on and on...many more...from any Forth.

The Amiga interface has about 4 of these kind of functions, so it was
very simple to provide the Forth-source equivalent for the C-published
routines.  All the rest of the OS calls are in the form of shared
libraries, which JForth can access 100% by name, with a CALL compiler
which even pulls function args from the stack in the same order as
described in all standard tech literature, and stuffs the correct
CPU registers...automatically!

>
>> Second, how hard can it be to implement some of that interface
>> in another platform's Forth?  Or create your own "layer" that you
>> implement in JForth and ??Forth, using the features specific to
>> each.
>
>Assuming a base-line implementation, yes, but see my last paragraph.

The more work you put into the interface, the more platforms and
applications it will serve, the easier it will be to program
with.

Dr. Martin Kees, a real JForth power-user and author of many
cool shareware programs illustrated this by developing a C-string
package for JForth.  it allows you to put tokens like '\n' %s
etc INSIDE Forth strings.  It's implementable in any Forth, and
because it's NOT minimal, the syntax will work in any Forth.

(BTW, Martins largest effort that I know of is called XL.  It's a
graphic bases animator package...full GUI provided, with a large
set of AREXX commands via which the program can control and be
contriolled by other programs, as well as providing a "scripting"
capability to the user.  The program uses a popular animation-display
technique called a Light-Table to illustrate the "flow" of
the frames of the animation you are creating.  The program is a
97K standalone-executable, generated with JForth's CLONE facility).

>
>> Phil Burk's ODE runs on top of JForth and is offerred with the
>> product.
>
>Unless ODE has been ported to other platforms as well, I can't use it
>if I want portability.

It has.  It's runs on the Mac under Mach2 and Phil's own Forth package.
No reason it shouldn't be implenmentable on the PC, either, I think.

>Does the JForth licence say that I can take the
>ODE source,  (which comes with JForth still, correct?) and port it to
>another platform and then distribute the product?

ODE is Phil's creation.  He lets Delta Research include it
in JForth (not too hard to arrange, since he's in Delta Research,
too).  But you'de have to work out liscencing matters with him.
He'd probably like the idea, but I can't speak for him.

>(This ties neatly
>into my other favorite topic of having a consistent interface to the
>dictionary headers,  but I won't get into that now.  :-)
>
>
>> [Description of HMSL deleted.]
>>
>>  ... but the point is that the EZMenus & EZGraphics
>> interfaces of JForth also exists on the Mac (although his H4TH is
>> heavily geared toward HMSL and isn't exactly a general purpose
>> Forth) so it can be done.
>
>Sorry, this doesn't count.  It would if H4TH was general purpose
>and readily available for program development.  Otherwise it does me
>no good.

The core to H4TH is ODE (which IS a general purpose object-oriented
language VERY similar to YERK).  HMSL is an application built on top
of ODE, which has been built on top of 5 Forths that I know of.

>
>> Actually, I don't see where C or any language has much advantage
>> over Forth if we're talking porting graphics, sound, etc.  There
>> are no standard C libraries to cover such concepts, as there are
>> simple character-based I/O (stdio.h for C, KEY & EMIT for Forth).
>
>Agreed, but I've never argued this point.  I already conceded that
>I would have to port graphics and sound routines.  The advantage of
>"C" is that it provides a consistent data structure interface across
>all platforms, and a consistent language for extending the language,
>(even though Forth is more extendable, "C" does provide for limited
>extendability through #defines and typedefs.)

Yeah, C is a great language.  Forth has tools that can be used to
construct structure-mechanisms, but it does suffer in that it has
no standard one (similar to the CASE statement and other stuff).

I think that Forth's extensibility is actually a disadvantage in
this area.  Everyone can come up with their own.  C programmers
are stuck (???) with the structure mechanism of C...you can't
duplicate that functionality with #define's and typedefs.  Same
as CASE... same as...etc etc.  The benefit for C is that complex
mechanisms are standardized.

>
>> Yes, the WORDS list of any Forth appears intimidating.  But
>> a fair portion of those words simply support another function.
>> In other words, some of them will never need to be known.
>
>I'm not sure you're right about this.  But if you are, I think
>commercial packages should start using vocabularies a little more.

Except that vocabularies in themselves are not standard.  Even the
mechanisms which were at one time standard (as in FIG), have lost
this quality.  It's a real shame.

>
>> If the Forth community could AGREE on standards, they could begin to be
>> implemented cross-platforms.  We have just gotten to the point
>> where the majority of the community FINALLY recognizes the iomportance of
>> file and memory interfaces, much less graphics standards.  Honestly,
>> the proponents of this language have always been more concerned
>> with vehement discussion about whether state-smart words should
>> be disallowed and whether WORD returns HERE or not.  We have
>> fought over SCREENS and FILES while the rest of the world was
>> discussing device-independant graphics!
>
>No argument here.  I can understand the reason esoteric discussions
>on keeping the language "pure",  but I think we really should start
>bringing this language out of the 70's and into a world where computers
>have operating systems.  When I look at some of the hacks put into C++,
>I don't think we have anything to be ashamed of regarding purity.
>
>                            /nt

Well said.  And very true.