Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!cbmvax!daveh
From: daveh@cbmvax.cbm.UUCP (Dave Haynie)
Newsgroups: net.micro.amiga
Subject: Re: A Hybred system
Message-ID: <834@cbmvax.cbmvax.cbm.UUCP>
Date: Fri, 3-Oct-86 18:03:25 EDT
Article-I.D.: cbmvax.834
Posted: Fri Oct  3 18:03:25 1986
Date-Received: Sat, 4-Oct-86 13:03:56 EDT
References: <1873@well.UUCP>
Organization: Commodore Technology, West Chester, PA
Lines: 50

> 
> 
>                      A HYBRED DEVELOPMENT SYSTEM
>                      ---------------------------

>    I am thinking of a hybred of C and FORTH.   It is NOT the scope of 
> this posting to argue which language is BETTER,  but to point out an
> idea, and open for discussion,  a different approach to software
> development,  taking advantage of the strong points of each language.

Another idea along these lines is a C interpreter.  Never used one myself,
but I see all kind of them advertised for the PC[lone] family.  The speed
wouldn't be that much of an issue (certainly slower than a TIL like 
Forth), its basically a development tool.  If you can use the object
modules from "debugged" code in it, perhaps inhereting symbolic info like
a debugger would, this might be the ultimate solution.  I've written lots
of code in the traditionally interpreted LISP language, and just the
fact that the thing's interpreted dramatically increases the debugging time,
and probably results in better though out code.  Which is why, I guess,
Leo Brody claims that Forth programmers write every program twice.


>   -- Knowledge of the .o file format for Manx or Lattice.

Lattice uses the standard ALink object format, which is cryptically
described in the AmigaDOS Technical Reference Guide, I believe (or
one of the AmigaDOS books, which are typically much less informative
than the RKM series <flames magically appear>).  Some of the programming
I've done under VAX/VMS got me used to the idea that everything should
have a standard object format (one application I worked with linked
BLISS, Fortran, Pascal, ISPS, and Assembler modulse together).  If a
standard object module exists, an interpreter could conceivably access
these objects as you mentioned.  As for choosing Forth, the idea sounds
interesting too; a Forth kernal would only take up a few K, just about
everything's stack allocated and thus reentrant, and it can approach the
speed of traditionally compiled code while at the same time tending to
produce smaller (if not faster) final output than assembled code.
How about a forth.library?

> John Draper
> WELL: crunch
> BIX: crunch
> CIS: 76703,4322
> UUCP: ihnp4!acad!well!crunch
-- 
============================================================================
Dave Haynie    {caip,ihnp4,allegra,seismo}!cbmvax!daveh

	These opinions are my own, though if you try them out, and decide
	that you really like them, a small donation would be appreciated.