BNF for Forth
Valer BOCAN
language?
Bart Lateur
>Anyone has an ideea where I could find the BNF description for the Forth
>language?
There isn't one. :-) FORTH's parser doesn't work that way. Just: get a
group of characters that isn't a space, and process it. This could be
it, so repeat; or this word may extract data from the input stream,
using whatever syntax it likes.
Bart.
John Passaniti
Valer BOCAN <vbocan@NOSPAM.u s a.n e t> wrote in message
news:7mfogp$g2f$1...@ffx2nh5.news.uu.net...
> Anyone has an ideea where I could find the
> BNF description for the Forth language?
You could probably construct a BNF grammar for the core Forth
language, but once you start extending the Forth, the BNF grammar
would quickly break down. The short answer is that Forth isn't
specified in terms of a BNF grammar. In fact, if you ask here, you'll
probably get responses that say that Forth doesn't have any syntax.
That is of course untrue. A better way of putting it is that Forth's
grammar isn't defined at the language level, but at the level of the
words that comprise Forth. Each whitespace-separated word in Forth
can impose it's own syntax and semantics, and these can be nearly
anything. This makes it difficult to express in a BNF grammar because
each lexical element can do nearly anything it wants (although there
are sensible conventions most people stick with).
If you state why you want a BNF grammar for Forth, maybe we can
provide you with something more appropriate and useful for your needs.
Dmitry V. Ragozin
*Anyone has an ideea where I could find the BNF description for the Forth
*language?
*
In general:
(because numbers can be different from version to version)
<blank_symbol>::=0..32
<non_blank_symbol>::=33..255
<word>::=<non_blank_symbol>|<word><non_blank_symbol>
<blank>::=<blank_symbol>|<blank><blank_symbol>
<tokens>::=<word>|<tokens><blank><word>
<program>::=<blank><tokens><blank>
Valer BOCAN
news:ZHTi3.1734$i6.1...@newsr2.twcny.rr.com...
> If you state why you want a BNF grammar for Forth, maybe we can
> provide you with something more appropriate and useful for your needs.
I write a paper on Forth and I need to "spice" it with BNF grammar. I know
that Forth is unlike any other programming language on Earth :-) however,
there must be a way to describe the IF-ELSE-THEN structure, BEGIN-AGAIN,
etc. I only need the grammar for the core Forth language.
Regards,
Valer BOCAN
Bill Zimmerly
As one who has posted the fact that Forth is a language without a syntax, on
the Forth WebRing homepage, I believe I should defend this statement since
you have asserted that it is untrue. Merriam-Webster defines syntax as
follows...
Main Entry: syn·tax
Pronunciation: 'sin-"taks
Function: noun
Etymology: French or Late Latin; French syntaxe, from Late Latin syntaxis,
from Greek, from syntassein to arrange together, from syn- + tassein to
arrange
Date: 1574
1 a : the way in which linguistic elements (as words) are put together to
form constituents (as phrases or clauses) b : the part of grammar dealing
with this
2 : a connected or orderly system : harmonious arrangement of parts or
elements
3 : syntactics especially as dealing with the formal properties of languages
or calculi
Since the language allows the programmer, nay, ENCOURAGES the programmer, to
define the syntax that is most appropriate for the application domain, the
word "formal" loses its meaning. To illustrate this, I often quote the
saying that "Nothing in Forth is sacred", and then show what I mean by this
by contrasting it in terms of the "formal" language C...
C programmers are encouraged to think in terms of the fixed constructs and
syntax of the language. An example being...
for(i=0; i<maximum; i++)
do_something();
If C had the same flexibility and encouraged the same kind of thinking as
Forth does, then the following could be considered valid to the compiler...
for(i=0; i<maximum; i++; register)
do_something();
What is meant by "register" in this code fragment, for the purposes of this
argument, is immaterial. The point being that such syntactical rules have
the negative effect of limiting what a programmer can do with the language.
In other words, how a programmer thinks about the art and science of
programming itself.
By being "boxed into" certain ways of thinking, other innovative and elegant
solutions to programming problems are never even considered.
Some, such as yourself, may consider such thinking to be a terrible way to
program computers. You have the right to disagree. As Charles Moore is
reputed to have said once, "If I want to add 'A' to 12, I don't want some
compiler telling me that I can't do that." (Emphasis on the "I".)
In summary, Forth has no formal syntax, because it encourages the programmer
to think "outside of the proverbial box" and DEFINE the syntax that is most
appropriate for the problem domain. This is why Forth is considered a
programming heresy in some CompSci circles.
- Bill Zimmerly
http://www.zimmerly.com mailto:bi...@zimmerly.com
"Reasonable people adapt themselves to the world. Unreasonable people
attempt to adapt the world to themselves. All progress, therefore, depends
on unreasonable people." - George Bernard Shaw
John Passaniti <jp...@rochester.rr.com> wrote in message
news:ZHTi3.1734$i6.1...@newsr2.twcny.rr.com...
>
> Valer BOCAN <vbocan@NOSPAM.u s a.n e t> wrote in message
> news:7mfogp$g2f$1...@ffx2nh5.news.uu.net...
> > Anyone has an ideea where I could find the
> > BNF description for the Forth language?
>
> You could probably construct a BNF grammar for the core Forth
> language, but once you start extending the Forth, the BNF grammar
> would quickly break down. The short answer is that Forth isn't
> specified in terms of a BNF grammar. In fact, if you ask here, you'll
> probably get responses that say that Forth doesn't have any syntax.
>
> That is of course untrue. A better way of putting it is that Forth's
> grammar isn't defined at the language level, but at the level of the
> words that comprise Forth. Each whitespace-separated word in Forth
> can impose it's own syntax and semantics, and these can be nearly
> anything. This makes it difficult to express in a BNF grammar because
> each lexical element can do nearly anything it wants (although there
> are sensible conventions most people stick with).
>
Ewald Pfau
"B> I write a paper on Forth and I need to "spice" it with BNF grammar.
"B> I know that Forth is unlike any other programming language on Earth
"B> :-) however, there must be a way to describe the IF-ELSE-THEN
"B> structure, BEGIN-AGAIN, etc. I only need the grammar for the core
"B> Forth language.
In BNF it reads:
a should look like <list>
b should look like <list>
...
In Forth it reads:
a should do <list>
b should do <list>
...
Apart from this trivial similarity at a meta-level (which makes it
difficult to apply BNF on Forth), you'll end for most 'native' syntactic
requirements in Forth with the problem of 'loose binding' via a stack.
For sure a '+' will as well add two values (as expected), but the action
of adding is only bound dynamically to what is added.
One could say, similar problems end with different approaches how they
are expressed starting already with natural language:
In Forth: Please could you look up which day it is. (ok. We keep the
result.) Please could you tell me. (Wednesday. ok.)
Algol-derivatives (for which BNF was made): He(A) put to that one(B) the
question(C), which day(D) we have. That one(B) answered the question(C)
for the day(D) to him(A) with "wednesday".
Seen more practically, if necessary, the simple fact for the flow of
control words might be expressed in BNF, that a flag is expected and
consumed and the compilation result needs to be balanced. So an abstract
and uncomplete approach were to fill-in some <list1..n> plus some
<list1[1]..listn[m]>, with [1..m] items on stack meaning those are
consumed. (Limitation: this won't cope with words picking from the input
stream something which has the same name as the one which is in the
description).
Or but, other way round to make-up an approach how to compile a set of
BNF-rules in Forth so those could be applied by a parser...
Christopher Browne
>In summary, Forth has no formal syntax, because it encourages the programmer
>to think "outside of the proverbial box" and DEFINE the syntax that is most
>appropriate for the problem domain. This is why Forth is considered a
>programming heresy in some CompSci circles.
Forth folk seem to *want* to feel downtrodden for this "lack of forced
formalism of syntax;" similar is true for Lisp, and any other systems
that use macro rewriting.
--
">Open Software and freeing source code isn't socialism.
Isn't socialist. It's neither socialist nor capitalist; it just is."
-- Arthur <afr...@usa.net>
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
John Passaniti
minor and uninteresting point about Forth. Your suspicions about my
feelings about Forth are wrong (I love the language), but I think
people put a lot of fringe mysticism and Zen bullshit into what is
(and should be) a very simple language. Statements like "Forth has no
syntax" serve only to obfuscate reality, not make it clearer.
Forth has a syntax. Before one starts to extend their own Forth, the
language follows set rules and conventions that everyone knows. If
this wasn't true, there wouldn't be an ANS standard, and there
wouldn't be books on the subject. The syntax of an unextended Forth
isn't necessarily representable by an BNF grammar, but that's not the
only representation of a language available.
Certainly once a programmer starts to extend Forth to fit the needs of
the application domain, the syntax of the unextended Forth can change,
but then again, there is a syntax. It's programmer-defined, but there
is still a syntax. It's just local to the words that define the
application instead of being defined globally for the entire language.
I see statements like "Forth has no syntax" as a way to differentiate
a language that certainly doesn't need differentiation.
> C programmers are encouraged to think in terms of the
> fixed constructs and syntax of the language. An example being...
>
> for(i=0; i<maximum; i++)
> do_something();
>
> If C had the same flexibility and encouraged the same kind
> of thinking as Forth does, then the following could be considered
> valid to the compiler...
>
> for(i=0; i<maximum; i++; register)
> do_something();
All languages-- including Forth-- present a model to the programmer.
C programmers view the processor in a way different than a Lisp,
Forth, Pascal, BASIC, Smalltalk, of Java programmer would. Languages
that are more rigid in their definition are only a straight-jacket to
programmers when the model they present doesn't match the model they
need. Forth (and Lisp, and others) have a less rigid syntax, but they
still have a model. For example, you can extend Forth virtually any
way you want, but it is unlikely that most people would extend Forth
so that the underlying computational model didn't use stacks, and that
dictionaries didn't hold symbols that resolve to code to manipulate
objects on the stack. Forth's rigidity then isn't in the language,
but in the model.
This isn't good or bad. It simply is. Put another way, it's "use the
right tool for the right job." Forth may be the right tool-- or it
may not. That is less an issue of the syntax of the language, but
rather of the underlying models Forth uses.
> By being "boxed into" certain ways of thinking, other
> innovative and elegant solutions to programming problems
> are never even considered.
This is more a function of the culture surrounding the language than
the language itself. Forth can be implemented in C, which means that
the features you cite as allowing "innovative and elegant solutions"
are equally available to C programmers. Actually, pretty any language
that has the concept of addressable storage and conditional branching
can implement the "innovative and elegant solutions" you cite. If
Forth encourages such is a matter of debate.
Forth programmers are often just as "boxed into" certain ways of
thinking. You can see this often in this newsgroup. Someone presents
an idea, and people will criticize it in terms of what Charles Moore
once said in an interview, what is commonly found in other Forth
source, and so on. This isn't always indicative of being "boxed into"
a way of thinking, but it does show that Forth programmers tend to
view problems in common ways.
You can see this for yourself the next time someone posts one of their
homework assignments, asking the participants of comp.lang.forth to do
their work for them. Look not at details of the solutions that people
here offer. Look instead of the approach. You'll see far more
commonality than differences, in general.
Again, this isn't good or bad. It simply is. Forth's model tends to
make people approach problems in similar ways.
Paul E. Bennett
jp...@rochester.rr.com "John Passaniti" writes:
[%X]
> This isn't good or bad. It simply is. Put another way, it's "use the
> right tool for the right job." Forth may be the right tool-- or it
> may not. That is less an issue of the syntax of the language, but
> rather of the underlying models Forth uses.
One could probably say that Forth is almost never the right tool for the
job until it has been extended to suit the application. In Forth you get
the freedom to explore solutions to the problem without having to consider
the constraints that might be imposed very much at all. You are, in effect,
creating an Application Specific Language - which is a very powerful concept.
--
Paul E. Bennett ................... <p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .... <www.amleth.demon.co.uk>
Tel: +44 (0)7971-620145
Going Forth Safely
Jonah Thomas
>[%X]
>> This isn't good or bad. It simply is. Put another way, it's "use the
>> right tool for the right job." Forth may be the right tool-- or it
>> may not. That is less an issue of the syntax of the language, but
>> rather of the underlying models Forth uses.
>One could probably say that Forth is almost never the right tool for the
>job until it has been extended to suit the application. In Forth you get
>the freedom to explore solutions to the problem without having to consider
>the constraints that might be imposed very much at all. You are, in effect,
>creating an Application Specific Language - which is a very powerful concept.
That would imply that the occasion to use some other application-specific
language comes when it's in some way more convenient -- easier to learn
the other language than to figure out how to extend Forth, already debugged
and tested for complex results, or already extensively documented so others
can easily maintain code written in it.
Perhaps that might imply a development path -- start with a new class
of application, develop an ASL for it in Forth, and once it works well
then add enough syntactic sugar (infix notation, named parameters passed
inside parentheses, full-fledged OO, etc) to market it successfully.
Len Zettel
Jonah Thomas wrote:
>
(snip)
>
> Perhaps that might imply a development path -- start with a new class
> of application, develop an ASL for it in Forth, and once it works well
> then add enough syntactic sugar (infix notation, named parameters passed
> inside parentheses, full-fledged OO, etc) to market it successfully.
These days the syntactic sugar for the masses is point-and-click.
-LenZ-
John Passaniti
Len Zettel <zet...@orchard.washtenaw.cc.mi.us> wrote in message
news:378E224D...@orchard.washtenaw.cc.mi.us...
> These days the syntactic sugar for the masses
> is point-and-click.
And there is nothing wrong with that. Only people who want to
restrict programming to a cadre of individuals instead of opening up
to the masses are the ones who lament this. I personally find it
terrific that there are people who are using visual programming
languages to churn out useful work.
Visual programming languages are increasingly popular these days. Dr.
Dobbs has in the past and current issues had articles that showed that
visual programming languages aren't just programming languages with a
graphical syntax-- but they can also lead to viewing problems entirely
differently.
Where I last worked, I had experience with one visual programming
system. The system was called MAX and was an adaptation of a
commercial product used by musicians to construct MIDI applications.
The version of MAX I used ran on a NeXT cube and was focused on DSP
algorithm development. Fundamental DSP blocks could be pulled from a
palette and lines could be drawn to indicate data flow. Blocks of
code could be reused by creating new blocks. As a data flow language,
the visual metaphor was particularly well suited to expressing the
connections. The end result was that people who understood DSP
techniques, but who didn't understand programming could represent
their ideas far more quickly than a textual language which obfuscated
the essential quality of the system-- the flow of data-- behind a
textual syntax.
My point is simply that point-and-click isn't necessarily syntactic
sugar. There are application domains where a visual metaphor is far
more intuitive and powerful than any textual language could ever be.
jethomas
>Jonah Thomas wrote:
>(snip)
>> Perhaps that might imply a development path -- start with a new class
>> of application, develop an ASL for it in Forth, and once it works well
>> then add enough syntactic sugar (infix notation, named parameters passed
>> inside parentheses, full-fledged OO, etc) to market it successfully.
>These days the syntactic sugar for the masses is point-and-click.
But point-and-click is write-only.
Andreas Kochenburger
<jp...@rochester.rr.com> wrote:
>My point is simply that point-and-click isn't necessarily syntactic
>sugar. There are application domains where a visual metaphor is far
>more intuitive and powerful than any textual language could ever be.
We have distributed control systems with full graphic CAE tools i.e.
you configure your algorithms by using blocks out of libraries and
interconnecting them. It has come out that this way of doing things is
good for 80 to 90 percent of application engineering. But it blows up
code size and code generation time, too. Creating new blocks is very
expensive because you have to create the automation runtime version,
the code generator in the engineering system, and the counterparts in
the visualization system. We lose a lot of time and costs for tasks
which are very simple in a freely programmable environment, like
balancing, reporting, modelling, if-else-scenarios etc.
The point is: you need both - visual _and_ textual programming - to be
really productive.
Andreas
Walter Rottenkolber
paragraph. This is made up of Words that are scanned from left to right. You
start at the beginning and continue until you get to the end, then you stop.
Why make it more complex than that?
There have been some mini BASICs written in Forth, but it's hardly worth the
effort.
The closest thing to BNF in Forth is VALUE, a form of constant variable.
As far as the Forth structures go:
<expression> IF <true code> ELSE <false code> THEN <continue>
BEGIN <code> AGAIN -- infinite loop.
Chuck Moore, in his talk 1x, describes some of his ideas on machine and
color forth. He eliminated the traditional branching and loop structures
picked up from other languages, and replaced them with a few multipurpose
primitives. A transcript of the talk is on Jeff Fox's website. An
interesting read on Chuck's new ideas on Forth.
Walter Rottenkolber
Bill Zimmerly
> Forth has a syntax. Before one starts to extend
> their own Forth, the language follows set rules
> and conventions that everyone knows.
I can live with that.
The reason I say that Forth is a language without a syntax is because it
doesn't *CEASE* to be Forth when it is extended into a problem domain where
the syntax is made to mimic the natural way of working with the problem.
(Whatever "natural" means in the problem domain context.)
To illustrate this, owing to the fact that the Forth "outer" interpreter is
supremely flexible, the following can ALL be valid Forth expressions and are
therefore executable...
y=mx+b
<jpassaniti>
<first=John>
<last=Passaniti>
</jpassaniti>
select * for age > 42
etc.
> Forth programmers are often just as "boxed into"
> certain ways of thinking. You can see this often
> in this newsgroup.
Certainly we all have our blind spots and our areas of creative insight, but
Forth, unlike the Algol type languages (C, Pascal, etc.) encourages thinking
outside of the syntactic boundaries of the language BECAUSE IT (Forth)
DOESN'T PRESENT US WITH SUCH BOUNDARIES! That is the point. Again, C
programmers simply don't think in terms of changing the structure of the
language itself because it does not accomodate such a thing.
- Bill
Jerry Avins
I wish! I can type on the keyboard with a dead monitor, but I need to
see in order to click.
Jerry
--
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
---------------------------------------------------------
Ewald Pfau
"Z> Certainly we all have our blind spots and our areas of creative
"Z> insight, but Forth, unlike the Algol type languages (C, Pascal,
"Z> etc.) encourages thinking outside of the syntactic boundaries of
the
"Z> language BECAUSE IT (Forth) DOESN'T PRESENT US WITH SUCH
BOUNDARIES!
"Z> That is the point. Again, C programmers simply don't think in terms
"Z> of changing the structure of the language itself because it does
not
"Z> accomodate such a thing.
Anyway, I guess you can make up some kind of syntax requirements for the
Forth construct which parses input. The difference is, the applied
syntax rules may need to change dynamically. So this is not about _the_
syntax, but about _a_ syntax which is valid at a specified moment while
parsing.
The most trivial parser is that one which finds [ELSE] or [THEN] after
[IF]. This shows another pecularity: As I understand, here the
conveniance is, to remain on the static side: If [THEN] appears below a
domain of sub-parsing, so the fact of sub-parsing is ignored:
[IF] ( if I'd write [THEN] (1) here so it were resolved immediately )
[ELSE] ... [THEN] (2)
For usual Forths are built more for fulfilling practical tasks than to
fulfill theoretical requirements, and the above (1) balances [IF]
instead of (2). Now, such a fact makes it harder again to talk about
syntax in Forth. A big advantage for everyday work with Forth is given
with its bottom-up style, for fast turn-around and compact overhead, so
this is a conveniance in favour of compact code.
Since this is commonly applied when working with Forth, so something
like the above should turn out to be a special case only. For a
'learning' parser, it is mostly enough to cope with defining words
(directly, and indirectly which may turn out to be non-trivial). As an
example one may think of mechanically translating Forth coding style to
a different lay-out. This should be pure syntax-parsing as I understand
it, and within practical limits this is not too hard too achieve (done
that, been there).
It becomes a good deal more difficult when a 'learning' parser should be
able to predict requirements of combinations during interpreter state,
of words, names and literals - i.e. to track definition first, and then
application of more elaborated defining words. (When it comes to
literals, so there might be a collision with the versatility of the
stack machine.)
I'd regard those examples as no-op-parsers (parsing with any other
reason except compiling), giving a reason to regard Forth sources from
the one ore the other special syntax viewpoint.
It is two points up to here (and more for sure still waiting): The one
is the 'learning' interpreter; the other is late binding via the stack,
which may be _very_ late binding and which may induce a completey
different syntax, bound by a parameter (anonymously) which waited very
long for being consumed.
Though, maybe you see the general point here: let the word 'syntax' work
for to use it in Forth instead of regarding it as an alien beast ;)
William Tanksley
>John Passaniti <jp...@rochester.rr.com> wrote in message
>> If you state why you want a BNF grammar for Forth, maybe we can
>> provide you with something more appropriate and useful for your needs.
>I write a paper on Forth and I need to "spice" it with BNF grammar.
That makes sense. Unfortunately, there's no existing documentation which
does this, simply because even at the unchanging, basic level, Forth is
better described by semantics than syntax. In other words, each word has
an action, and that's all you need to know.
>I know that Forth is unlike any other programming language on Earth :-)
Grin -- thanks!
>however,
>there must be a way to describe the IF-ELSE-THEN structure, BEGIN-AGAIN,
>etc. I only need the grammar for the core Forth language.
The official description of what each word is certain to do is in the ANSI
document. You can get that at taygeta.com.
This is the best you can get currently; to do better you'd have to
formalize the ANSI descriptions, perhaps using Turing machines or Abstract
State Machines. Syntax description wouldn't help.
Why? Well, for example, what about IF? The syntax for IF should be
really simple, but just try modelling it. SWAP IF, OVER IF, and so on all
violate any BNF-describable syntax for IF.
>Valer BOCAN
--
-William "Billy" Tanksley
Anton Ertl
wtan...@dolphin.openprojects.net (William Tanksley) writes:
> This is the best you can get currently; to do better you'd have to
> formalize the ANSI descriptions
Actually, the standard uses a formal notation that's at least as
powerful as BNF: stack effects. I am not sure, however, if the types
are used consistently enough in the standard so the standard stack
effects can be used as realistic grammar (it should be good enough
for the control structures, though).
For more info read
@InProceedings{poeial94,
author = "Jaanus P{\"o}ial",
title = "Forth and Formal Language Theory",
crossref = "euroforth94",
pages = "47--52",
annote = "Shows that the stack effect notation is at least as
powerful as context-free grammars and that it is better
suited for specifying the syntax of Forth."
}
@Proceedings{euroforth94,
title = "EuroForth~'94 Conference Proceedings",
booktitle = "EuroForth~'94 Conference Proceedings",
year = "1994",
key = "EuroForth '94",
address = "Winchester, UK",
}
I also remember a paper about syntax in JFAR (in Vol. 4 or so).
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Bernd Paysan
> Actually, the standard uses a formal notation that's at least as
> powerful as BNF: stack effects. I am not sure, however, if the types
> are used consistently enough in the standard so the standard stack
> effects can be used as realistic grammar (it should be good enough
> for the control structures, though).
I'm not sure if it works out with a set of automatic conversion rules
that prohibit certain directions (e.g. you can add address and u/n to
get an address, but not address+address), but if you allow conversions
from everything to everything (but keeping floats and ints/addresses on
stacks apart), it will work. Proof: Gforth's primitive stack effects are
automatically converted to C this way.
For a formal notation however, the undefined patterns are a problem
(e.g. EXECUTE ( x1 .. xi xt -- y1 .. yj )). Your stack simply is
undefined after an EXECUTE or anything that contains one or more
EXECUTEs.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bill Ragsdale
Forth in the early 1980's. Only ran about 50 lines.
I don't know his email address. Contact Trace Carter at the Forth Interest
Group office or post a notice on the Forth NG.
People say Forth has no BNF. True in the rigorous sense of writing a compiler
compiler. But Ting's BNF is useful to understand the control constructs and
syntax of word definitions (CODE, : etc.)
Bill Ragsdale
Bernd Paysan
> People say Forth has no BNF.
It has one:
statement ::= blanks word <bl> eaten-up-by-word-tokens statement |
blanks word <eol>
word ::= non-blank word | non-blank
blanks ::= <bl> blanks |
eaten-up-by-word-tokens ::= <anything> eaten-up-by-word-tokens |
non-blank ::= left as exercise for the reader
It just is useless, because all the important parts are defined by the
semantics of the words. And the eaten-up-by-word-tokens aren't nice,
either ;-) (though they are empty for most words).
Anton Ertl
Bernd Paysan <bernd....@gmx.de> writes:
> Anton Ertl wrote:
> > Actually, the standard uses a formal notation that's at least as
> > powerful as BNF: stack effects. I am not sure, however, if the types
> > are used consistently enough in the standard so the standard stack
> > effects can be used as realistic grammar (it should be good enough
> > for the control structures, though).
>
> I'm not sure if it works out with a set of automatic conversion rules
> that prohibit certain directions (e.g. you can add address and u/n to
> get an address, but not address+address),
Not with the standard rules: multiplying an address by 5 is correct
according to the standard subtyping rules (addr is a subtype of u).
> but if you allow conversions
> from everything to everything (but keeping floats and ints/addresses on
> stacks apart), it will work.
Yes, and typical BNF grammars for programming languages have even less
type checking encoded (e.g., address*float is syntactically correct C,
and only the type checker notes that it is not type-correct).
> For a formal notation however, the undefined patterns are a problem
> (e.g. EXECUTE ( x1 .. xi xt -- y1 .. yj )). Your stack simply is
> undefined after an EXECUTE or anything that contains one or more
> EXECUTEs.
Yes, and control flow joins is also a problem (correct Forth programs
need not have statically determinable stack effects). And if the type
rules were more exact, the memory words would also be a problem,
because we don't know much about the type of something fetched from
memory.
Ewald Pfau
code _does_ at its run-time, as BNF only describes how the _source_ of
code _looks_like_. Maybe it has to do with the term 'parser' for which
the meaning is occupied in the programmer's neighbourhood by special
tools, which have in common with BNF-descriptions that those mean _one_
BNF-description and have been built in a tradition which started with
such _a_ BNF-description to act accordingly. Finally, of those tools the
_result_ has to do with what code _does_. Now, to see Forth set in its
relation to _an_appropriate_ BNF-description would be nice to study. But
I'm afraid this is a different party. Comments?