Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ncar!boulder!sunybcs!rutgers!rochester!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: Jack Woehr's amazing productivity!
Keywords: Parallel, controllers
Message-ID: <2852@pt.cs.cmu.edu>
Date: 1 Sep 88 14:19:57 GMT
References: <8808121826.AA23206@jade.berkeley.edu> <1575@crete.cs.glasgow.ac.uk> <917@helios.ee.lbl.gov>
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 25

In article <917@helios.ee.lbl.gov>, wbrown@beva.bev.lbl.gov (Bill Brown) writes:
> I've seen a language (I think it was called "MagicL") which was an
> attempt to combine "c" and "Forth".  I was never in a position where
> I had to untangle it, and it was before I really started to use "c",
> but I had the feeling that it combined the worst features of both languages.
>                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

YES -- that's the point!  What you get when you try to force a "normal"
infix parser on top of Forth can easily be a mess!  From what little
I could see of MagicL from the articles I read about it a few years ago,
it looked like Fraser's preprocessor idea carried to a full implementation.
A preprocessor can be put onto Forth, but that's not the issue.  Evaluating
complex arithmetic expressions is not what most Forth code does.

When I said that I have considered combining C and Forth environments,
what I mean is having either:
1) Separate C and Forth compilers that can share routines
2) A C compiler that can include pieces of normal Forth code
   as "assembly language" insertions, not a hybrid language.
The idea is to be able to port existing C code onto a stack machine,
then optimize the inner loops using Forth == "machine language."

  Phil Koopman                koopman@maxwell.ece.cmu.edu   Arpanet
  5551 Beacon St.
  Pittsburgh, PA  15217    
PhD student at CMU and sometime consultant to Harris Semiconductor.