On Mar 13, 12:59 pm, John Doty <j...@[EMAIL PROTECTED]
> wrote:
> > Do you intend it to be a fully extensible language like Forth,
....
> Well, I think the history of scientific and mathematical notation shows
> that more discipline is needed. Successful notational extensions have
> primarily come about by generalizing the symbols, but keeping the
> grammar ("overloading").
Answer to question: "No". This says that overload works because
grammar has channeled the extensibility in a certain direction.
So Forth can be used to write this language, not necessarily visa
versa (that depend on exactly what direction the channeling takes).
> > Would it follow a two stack model?
> At the very least, stacks should be less visible. They're an
> implementation concept, not a language concept.
Whereas in Forth, they are a language concept.
> > RPN?
> Users' discretion at edit time. Reversible automatic translation between
> RPN and infix. Mathematica is a fine example of how a readable
> traditional notation can coexist with a more powerful and flexible (but
> less readable) fundamental notation.
Which suggests that it should be possible to extend this outside the
reach of syntax drive languages entirely into a process oriented
language like Forth.
> But make it *real* RPN: discipline or eliminate the "stack gymnastics"
> words. Don't just pretend to have RPN.
Forth does not pretend to have RPN. Forth actually has the virtual
machine that many people imagine when they look at RPN syntax and
pretend that it is a process oriented language.
> > Have far from Forth are you willing to go to cater to the m*****?
> I prefer to think of it as catering to the genius who isn't a Forth
> programmer.
Forth can do that, simply specify the language and implement it in
Forth-94.
That is, of course, like the recipe for bear soup: first, catch, kill
and dress one large adult grizzly bear.
> Yesterday at breakfast, at the Cutthroat Cafe in Bailey, Colorado, I
> found myself sitting next to an industrial physical chemist. He was
> asserting that although there were too many incompatible programming
> languages, the nice thing is that they are similar enough that you can
> usually read the code in any of them, even if you don't know the
> language. Now, obviously, he'd never encountered Forth (or Lisp, APL,
...).
> For him this was a good thing. But Forth is cut off from such users by
> being willfully different. And it seems to me that a physical chemist
> working in a lab full of equipment operated by microcontrollers is a
> serious potential user of something like Forth.
However, a toolchain of raw iron, Forth, interactive incremental
compiled control language that has an explicit scope stack and
therefore can easily have a surface resemblance to an ALGOL language
is a very short one, compared to the toolchain that many people have
between their fingers and their equipment.
> From the implementation perspective, syntax is a relatively trivial
> part of the language. What really distinguishes different programming
> systems is the underlying foundation. But from a human perspective,
> syntax makes a big difference.
Once one adopt a syntax-driven language, yes. So develop a syntax-
driven language in Forth that it is easy to ex****t new operations to
from Forth. If all the device drivers are written in Forth ... hell,
if the device drivers are gzipped Forth scripts ... why would the user
care? Users don't read device driver code.
"name1" define{ [ noun1 noun2 verb1 noun3 verb2 ] }
"name2" define{
if{ [ noun1 noun2 =? ] [ noun3 noun4 adverb1 verb1 adjective1 ]
else{ [ verb2 ] }
}
}
"name3" compose{ verb1 verb2 adverb1 verb3 }
[ when compiled starts compiling a new anonymous process, which when
executed starts a new datastack frame in which:
* nouns are typed
* all verbs operate on a set number of nouns on the datastack (which
may be 0), and it is a syntax error if there are insufficient nouns in
the frame. All primitive verbs are overloaded to handle all primitive
types, and return a typed noun ...
* an adverb can modify the behavior of the following verb, and must
follow the nouns (if any) that the (modified) operator operates on, so
that the verb processes all adverb type objects on the datastack,
until it encounters a non-adverb data type, and then it consumes its
fixed number of nouns
* an adjective modifies the properties of the topmost noun on the
datastack
] places the compiled process id on the process definition stack.
define{ pushes the token name onto the scope stack, with the
definition action on top, which when executed adds that definition to
appropriate namespace, and starts the definition compiler. Definitions
can appear anywhere in place of an process provided by [ ].
compose{ pushes the token name onto the scope stack, with the
composition action on top, which when executed adds that definition to
the appropriate namespace, and starts the composition compiler.
Compositions can appear anywhere that sequence of items would be valid
inside an anonymous [ ] process.
if{ when executed pushes the conditional action onto the scope stack,
which executes the secondmost process and if the noun is a TRUE item,
executes the topmost process. The item has to be a boolean ... there
are monad verbs that perform that conversion for non-booleans.
else{ when executed replaces the if{ entry in the scope stack with if-
else, which executes the thirdmost process, executing the secondmost
item if the noun is a TRUE item, and the topmost if the noun is a
FALSE item.
Since [ noun1 noun2 ] gives a tuple, its straightforward to define
loop operators that expect a tuple secondmost on the process stack
with the action to be performed topmost on the process stack.
OK, now, that syntactic, RPN, ALGOL-looking-control-flow,
incrementally compiled language:
* Can it be implemented in Forth?
Of course it can ... designed from the ground up, it can rely on
whitespace delimited tokens, which means that the language can borrow
the whole Forth interpreter mechanism. Forth can implement arbitrary
stacks with arbitrary structures on them. A Forth wordlist can provide
a completely generic namespace hierarchy, so in particular a named
Forth wordlist can be defined that has no entries other than the
reserved wordlist names "verbs", "nouns", "adverbs", "adjectives",
"scope". Treating a leading quote as an instruction to push a string
item somewhere is a wheel that is constantly re-invented in Forth.
* If implemented in Forth, would it be easier to ****t to any
scientific control situation than if implemented in C?
Of course it would. If C is available, use a Forth that is compiled in
C. If C is not available but an assembler is, use a Forth that is
assembled in that assembly language. If its bare metal with no
toolchain, its quicker to cross-compile a Forth from the bare metal
than to write an assembler for it or to implement a C for it.
* Does the genius have to care that its implemented in Forth?
If implemented correctly, no. The Forth guru does the implementation,
once. The implementation lists which Forth-94 systems will load and
run the language, and normally the distribution package will give a
calling convention that hides the fact that there is a Forth back
there (except maybe for the entries in a log of the compilation .( )
comments that say what was added or defined on the way to starting
things up.
Also note that the above syntax means that an FSL array word appears
to be a scope word, and if implemented that way, someone dabbling with
descending into Forth to extend the available primitive words would
see array names looking just like the ones they were used to.
I think that property may make the above syntax or something like it
suitable for a "Scientific Incremental Command Language", or
"Sicl" (Ficl, Nicl ... yeah).
|
