RAYBRO%HOLON@UTRCGW.UTC.COM ("William R Brohinsky", ay) (02/14/91)
Eric Johansson write>>>>>> Subj: RE: ANS TC Magnet for Cont. Ref. Set And speaking of interesting opinions, here is another.... read with a bit of salt :-) There is one way I could agree to shrinking the ANSI wordset thereby eliminating all of these controversies over the string or file or ... wordsets. Define a standard way of calling C functions from forth. Then anyone could use all the functions in libc.a or any other C library and not need to reinvent the wheel (or words) in forth. Think about it, interface to C in an standard sequence and all the issues of strings, files, floating point, networking, GUI are mostly solved. Use the C names, with the C specified arguments in a forth context. real easy. But I figure this will never fly because the forth hackers of the world have their egos too wrapped up in reinventing the wheel in the forth way to get any real work done and make money using forth. >>>>>>>>> Ha, ha, ha! This is exactly what J-forth and (in a slightly clunkier fashion, IMHO) Multi-forth do on the Amiga. There's only a few objections I'd have to `standardizing' that: Can you get TurboC to use libraries compiled for use with MicroSoftC on the PC? Can you get C libraries at reasonable cost for the 68hc11? (I know right off of two compilers that run in the $1000 range!) Also, if you actually roll-your-own C library interface, you have to know how the compiler it is intended for keeps its stuff on the stack, which I believe is implementation dependant, and not specified in the ANSI standard. That you must have a stack, that's standard. How you keep things there (in what order) is up to you and your machine. In addition, this can be easily done on one platform, like the Amiga, because the whole hardware-software interface is determined by EXEC. There are other systems that don't have such a strict (nor so benevolent a) dictator. The Amiga also has the ability to share libraries, while talk of this is just now happening for some other OSs. Using another language's libraries is OK if they're there... Also, once you have a whole set of libraries, you have to have a way to add to them or modify routines: this is what forth is all about. If I don't like emit, or want it to emit somewhere's else... I can change it. With C libraries, you need the source (no real decompiler possible), you need a librarian, and you need to be able to compile into the library...Why not use C in the first place? Or you suggesting that we take all of the C library routines, and write them in forth, verbatim (as it were)? Then, I guess the next thing to do is to change WORD and EXPECT, etc. to work with Zero-terminated strings, and trash enumerated strings... After all, enumerated strings are fine if you want speed, but we're talking C libraries here... What you'll end up with, IMHO (alright, IMRO, R for righteous?), is C. And you'll still have a big hole where FORTH used to be, and a lot of people using un-standardized forths to fill the hole because there won't be a real FORTH any where near the standard... [NOTE: this is not a flame. [TINF?] The idea is OK for practice where the operating system (and its implementation) make a c-like interface and library access desirable, but I don't think it belongs as a foundation of the standard. These sorts of things become non-portable real quickly... >--- eric > >-- >... >^^^ eric johansson UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp >* * a juggling fool AT&T (617) 577-4068 (w) > o HAM ka1eec >\_/ CSNET johansson%hydra@polaroid.com > or hydra!johansson@polaroid.com > source of the public's fear of the unknown since 1956 raybro
esj@harvee.UUCP (Eric S Johansson) (02/17/91)
I'm glad I made you smile. (it's a wonderful day in the neighborhood...) [the following has been edited a bit - esj] In article <9102141832.AA19990@ucbvax.Berkeley.EDU> RAYBRO%HOLON@UTRCGW.UTC.COM > > Ha, ha, ha! This is exactly what J-forth and (in a slightly clunkier > fashion, IMHO) Multi-forth do on the Amiga. There's only a few objections > I'd have to `standardizing' that: > > Can you get TurboC to use libraries compiled for use with MicroSoftC > on the PC? Can you get C libraries at reasonable cost for the 68hc11? > (I know right off of two compilers that run in the $1000 range!) The issue of different binary formats and library formats is a sticky one that gives compiler venders another reason to use Tums. The PC world is a messy place whereas in the unix world we only have a half dozen binary formats (count as of last week). I guess the only answer I have for you is state that which binary/library format used is a vendor specific issue. suppliers of libraries usually support the top X popular binary formats so if you had a forth that linked to C libraries, you probably could find a vendor that supported the library format you needed. Object/library format is one of my selection criteria when I choose a compiler and library suppliers no matter what language I work in. C libs for small machines at "reasonable cost" ( example: 6811 ) I could claim that routines you find in an ANSI C RTL you would not be able use in a micro-controller environment like the 6811 but you would be justified in calling that a arguable point. Since you claim that you know of two suppliers of 1000$ C compilers, I suggest one could look there for a library supply. BTW, I consider 1000$ reasonable (if not cheap) for a compiler when a company is buying it. The only beter deal I know of are the FSF compilers for unix systems. They are less buggy than most commerical C/C++ compilers and better supported. (argue this point with me in email :-) > Also, if you actually roll-your-own C library interface, you > have to know how the compiler it is intended for keeps its stuff > on the stack, which I believe is implementation dependant, and not > specified in the ANSI standard. That you must have a stack, that's > standard. How you keep things there (in what order) is up to > you and your machine. > The issue of calling sequences is strongly tied to object format. A compiler that produces object files in the same format as another compiler but uses a different calling sequence will tend to not have a very large market place. > > Also, once you have a whole set of libraries, you have to have a way > to add to them or modify routines: this is what forth is all about. I tend to view libraries as a fixed set of atomic objects. I can't change them (except for bug fixes), or add to them. Changing the behaviour or adding routines is not acceptable IFF the library is defined by a standard. On the other hand, changing or adding to my local libraries is ok because no-one outside of my work group is counting on them. ( I will rant about resuable code at another time.) > If I don't like emit, or want it to emit somewhere's else... I can > change it. hmmm. *i* just redirect stdout if i want the equivelent of redirecting emit. :-) :-) > With C libraries, you need the source (no real decompiler > possible), you need a librarian, and you need to be able to compile > into the library...Why not use C in the first place? Well... Using C instead of forth *is* the option picked by most managers of software projects. > [NOTE: this is not a flame. [TINF?] Understood and not taken as a flame. > The idea is OK for practice where > the operating system (and its implementation) make a c-like interface > and library access desirable, but I don't think it belongs as a foundation > of the standard. These sorts of things become non-portable real quickly... I sort-of dissagree. I believe an inter-language interface belongs in the standard of any language. I also believe that the INTERFACE can be made portable whereas the implementation will tend to not be portable. > > raybro --- eric -- ... ^^^ eric johansson UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp * * a juggling fool AT&T (617) 577-4068 (w) o HAM ka1eec \_/ CSNET johansson%hydra@polaroid.com or hydra!johansson@polaroid.com source of the public's fear of the unknown since 1956
jax@well.sf.ca.us (Jack J. Woehr) (02/19/91)
esj@harvee.UUCP (Eric S Johansson) writes: ... <stuff> ... >Well... Using C instead of forth *is* the option picked by most >managers of software projects. Yeah, it's a gas. To program our Vesta Technology SBC68K 68000/68010-based single board computer you can: a) Grab an XT Clone with two floppies and MSDOS 2.1 and buy our Vesta Forth-83A+ for $99.00, or b) Grab a 386 with a big harddrive and buy our C Compiler and source-level debugger for $3495.00. In house we use our Forth-83A+ for projects because we run coencentric rigns around C programmers in terms of productivity. I'm sure glad that most of our competitors use C, it guarantees that we underbid them every time. For your next custom engineered control project, give Vesta a call. <plug> When in UNIX, do as the C programmers do, but when in Realtime, Forth! -- <jax@well.{UUCP,sf.ca.us} >< Member, > /// ///\\\ \\\ /// <well!jax@lll-winken.arpa >< X3J14 TC > /// /// \\\ \\\/// <JAX on GEnie >< for ANS > \\\ /// ///====\\\ ///\\\ <SYSOP RCFB (303) 278-0364>< Forth > \\\/// /// \\\ /// \\\
esj@harvee.UUCP (Eric S Johansson) (02/20/91)
In article <23224@well.sf.ca.us> jax@well.sf.ca.us (Jack J. Woehr) writes: > esj@harvee.UUCP (Eric S Johansson) writes: > > ... <stuff> ... > > >Well... Using C instead of forth *is* the option picked by most > >managers of software projects. > > Yeah, it's a gas. To program our Vesta Technology SBC68K > 68000/68010-based single board computer you can: > > a) Grab an XT Clone with two floppies and MSDOS 2.1 and buy > our Vesta Forth-83A+ for $99.00, or > > b) Grab a 386 with a big harddrive and buy our C Compiler and > source-level debugger for $3495.00. In my 14+ years in the field, I have worked for 6 companies. 5 would choose this option and I can name you about a hundred other companies that would do the same. (sigh) > > In house we use our Forth-83A+ for projects because we run > coencentric rigns around C programmers in terms of productivity. > > I'm sure glad that most of our competitors use C, it guarantees > that we underbid them every time. For your next custom engineered > control project, give Vesta a call. <plug> I sure will <grin>. Although you probably would not underbid as far as you think you might be able to. I am managing a contract for Polaroid now and we are paying 40K$ for a scanner toolkit. Approx. 30K$ is for documentation, unit test and regression test suites. Only 10K$ of the bid is for coding and testing. AND! if they don't pass our reviews (design, code, test) they don't get paid! When I write Forth code, I am about 10 times more productive than when I code in C. Coding in C++ without a class library is the same level of productivity as coding in Forth. Unfortunatly, coding is 20% of the effort that goes into building a software product. The rest is specifications, design, testing and acceptance. > > When in UNIX, do as the C programmers do, but when in Realtime, > Forth! > Hell, I want to make it possible to use forth *anywhere* not just realtime! Using forth and C++, I have gotten real addicted to powerful tools but my boss pays me to write specs and make designs that fit those twisted nightmares that come out of marketing. But, on the upside, they let me experiment with formal notations and OOD. -- ... ^^^ eric johansson UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp * * a juggling fool AT&T (617) 577-4068 (w) o HAM ka1eec \_/ CSNET johansson%hydra@polaroid.com or hydra!johansson@polaroid.com source of the public's fear of the unknown since 1956