Re: [stack] Re: POP-11: another concatenative language
Serguey Zefirov — 2002-01-29 12:32:32
Hello e1_t,
вторник, 29 января 2002 г., you wrote:
>>
>> You're drawing the same line I'm drawing, but in a different
e> place. Forth
>> has a feature which makes it non-concatenative: the ability for
e> words to
>> parse ahead of themselves (thus applying themselves to parameters).
>>
e> That's a consequence of Forth being the only programming language
e> (that I know of anyway) that provides the programmer with full access
e> to it's internals. This was more true with older implementations of
e> Forth than it is now but it's mostly still the case (at least with
e> those Forths that were written in Forth or assembler).
Nope, this is just a matter of convenience.
And this is the way early human mind works, otherwise we wouldn't get
any sentences like "tom, harry and dave", where ", <name>"
concatenative and "and" is infix and is not concatenative. ;)
If you'll try to speak the above sentence you'll find that "and" helps
to structure phrase and indicates a nearby end. It is easy to draw a
bunch of hypothesis from that fact.
Best regards,
Serguey Zefirov mailto:
sz@...
John Cowan — 2002-01-29 13:24:05
Serguey Zefirov scripsit:
> And this is the way early human mind works, otherwise we wouldn't get
> any sentences like "tom, harry and dave", where ", <name>"
> concatenative and "and" is infix and is not concatenative. ;)
In some languages. Latin can't say that; it has to say either
"Thomasus et Henricus et Davidus", with full words infixed,
or else "Thomas Henricusque Davidusque", Forth-style.
Classical Greek shows the same pattern, with "kai" and "-te".
(BTW, the English idiom is "Tom, Dick, and Harry". ObJoke:
"You're going to name him John? Why?? Every Tom, Dick, and Harry
is named John!")
--
John Cowan
http://www.ccil.org/~cowan cowan@...
To say that Bilbo's breath was taken away is no description at all. There
are no words left to express his staggerment, since Men changed the language
that they learned of elves in the days when all the world was wonderful.
--_The Hobbit_
Billy Tanksley — 2002-01-29 23:08:30
From: e1_t [mailto:
e1_t@...]
[I stated that POP-11 is an interesting, and possibly informative, example
of a primitive concatenative language. Someone else says:]
>> >I think the only languages I would classify as "concatenative"
>> >right now
>> >are Joy, Forth, Postscript as well as some more specialized
>> >languages like that in the dc calculator on unix.
[I reply:]
>> You're drawing the same line I'm drawing, but in a different
>> place. Forth
>> has a feature which makes it non-concatenative: the ability for
>> words to
>> parse ahead of themselves (thus applying themselves to parameters).
>That's a consequence of Forth being the only programming language
>(that I know of anyway) that provides the programmer with full access
>to it's internals.
I would have to disagree with that statement. The ability for words to
parse ahead of themselves is not a result of full access to internals; it's
simply one possible means of providing full access to internals.
ThisForth provides words the ability to parse ahead using a completely
different mechanism than is used in traditional Forths. In other words,
there's no need to directly access internals.
My point was that Forth provides non-concatenative features, and it's still
a concatenative language. Thus, although POP-11 provides nonconcatenative
features it still might be (largely) concatenative, and certainly is an
interesting thing to compare and contrast with.
>This was more true with older implementations of
>Forth than it is now but it's mostly still the case (at least with
>those Forths that were written in Forth or assembler).
Yes; the main problem is a change in philosophy, I'd say, rather than
implementation language.
>Also, I'm not completely sure but from what I know Charles Moore's
>ColorForth doesn't have a word like PARSE or WORD nor does it give
>you access to some form of an input buffer and I don't think it
>allows you to parse ahead.
>I could be wrong though.
That's my understanding as well; in order to build a parsing word, you have
to modify the editor, not the language.
This is an offshoot of the long-known rule that "you shouldn't build parsing
words". Chuck has always maintained that parsing words are bad form, but
nobody's ever managed to get them out of Forth -- there are too many places
where you need them. So he finally completely redesigned Forth, and as a
side effect parsing words went away. It doesn't seem to hurt as much as I
would have expected.
It's interesting that one of the old informal rules of Forth (don't build
parsing words) has the accidental side-effect of making Forth more purely
concatenative.
A little sidelight:
Forth uses parsing words to support things like string literals and comments
-- a comment is just a sequence of ignored text inside parentheses, so we
just define a word named "(" which discards text until it finds a ")"
character. A string literal is a sequence of characters inside quotes, so
we define a word '"' which parses text and compiles the literal value of the
text into the current definition until it reaches a '"' character.
ColorForth turns everything on its head! In ColorForth the entire idea of
source text goes away; your editor loads a preparsed representation of your
code and presents it to you as though it were color-coded (kind of like
syntax highlighted) text. Comments are stored where the compiler won't ever
see them; literals are stored as code to compile their literal values,
together with some clues to help the editor display them (so a literal PNG
would be easily possible, and the editor would display and edit it as a
picture).
It seems that ColorForth is more concatenative than Forth. Is it more
concatenative than Joy? Even definitions in ColorForth follow the
concatenative property:
:myWord do this then that ;
:otherWord do something else ;
This defines two words, myWord and otherWord. You can split this up into
any number of subprograms; it still defines those same two words. Even if
you wrap it inside some other word definition, it'll still define those two
words.
Here's an example of those two definitions wrapped inside another
definition:
:outerWord check something IF
:myWord do this then that ;
THEN
:otherWord do something else ;
It's kind of hard to see what I just did. Let me expand that to its Forth
equivalent:
: outerWord check something IF do this then that ELSE do something else THEN
;
: myWord do this then that ;
: otherWord do something else ;
As you can see, word definitions simply define _entry points_, not
functions.
>Ivan
-Billy
e1_t — 2002-01-30 01:25:16
>
> e> That's a consequence of Forth being the only programming language
> e> (that I know of anyway) that provides the programmer with full
access
> e> to it's internals. This was more true with older implementations
of
> e> Forth than it is now but it's mostly still the case (at least
with
> e> those Forths that were written in Forth or assembler).
>
> Nope, this is just a matter of convenience.
>
> And this is the way early human mind works, otherwise we wouldn't
get
> any sentences like "tom, harry and dave", where ", <name>"
> concatenative and "and" is infix and is not concatenative. ;)
> If you'll try to speak the above sentence you'll find that "and"
helps
> to structure phrase and indicates a nearby end. It is easy to draw a
> bunch of hypothesis from that fact.
>
Right, conveniance. The reason why implementation of PARSE was so
conveniant in first implementations of Forth was because Forth
provided direct access to it's input buffer. Back then memory was
expensive and while now we have enough memory to build various
abstractions and can therefore choose different implementation
strategies back then this was very conveniant.
Note that parsing words in initial Forths weren't there to aid in
adding infix or prefix operators to Forth (although it did make it
possible) - they were there to aid in compiling string constants and
similar things. So really this has nothing to do with structure of
spoken languages.
Ivan
e1_t — 2002-01-30 01:31:59
--- In concatenative@y..., Billy Tanksley <wtanksley@b...> wrote:
> From: e1_t [mailto:e1_t@y...]
> [I stated that POP-11 is an interesting, and possibly informative,
example
> of a primitive concatenative language. Someone else says:]
> >> >I think the only languages I would classify as "concatenative"
> >> >right now
> >> >are Joy, Forth, Postscript as well as some more specialized
> >> >languages like that in the dc calculator on unix.
> [I reply:]
> >> You're drawing the same line I'm drawing, but in a different
> >> place. Forth
> >> has a feature which makes it non-concatenative: the ability for
> >> words to
> >> parse ahead of themselves (thus applying themselves to
parameters).
>
> >That's a consequence of Forth being the only programming language
> >(that I know of anyway) that provides the programmer with full
access
> >to it's internals.
>
> I would have to disagree with that statement. The ability for
words to
> parse ahead of themselves is not a result of full access to
internals; it's
> simply one possible means of providing full access to internals.
>
Right.
> ThisForth provides words the ability to parse ahead using a
completely
> different mechanism than is used in traditional Forths. In other
words,
> there's no need to directly access internals.
>
As I said it was the case with older Forths more than it is now -
various new implementations of Forth written in C (like ThisForth)
and Java are implemented in different ways.
For example you can't really directly access internals of a Forth
written in Java.
I guess I should have explained what I meant more clearly.
PARSE can be implemented in any Turing complete language. It's just a
matter of how many abstractions you have to add or how much code you
have to write before you have everything you need to implement PARSE.
My point, although I failed to explain it, was that I believe that
the reason why PARSE and similar words entered Forth in first place
was simply because implementation of such words in Forth is
practical, intuitive and as Serguey pointed out conveniant.
Implementation of PARSE comes quite naturally after you have access
(or even 'simulated' access) to the input buffer (or terminal input
buffer as it was called in old Forths).
In my opinion this doesn't really conflict with Forth's
concatenativity. It does give you the power to change the language
itself.
Most parsing words are really meant to be called from within
immediate words which are Forth's (more powerfull) equivalent of
Joy's meta language.
> My point was that Forth provides non-concatenative features, and
it's still
> a concatenative language. Thus, although POP-11 provides
nonconcatenative
As I said I'm not quite sure whether the ability of Forth to parse
ahead really conflicts with Forth's concatenativity.
> features it still might be (largely) concatenative, and certainly
is an
> interesting thing to compare and contrast with.
>
> >This was more true with older implementations of
> >Forth than it is now but it's mostly still the case (at least with
> >those Forths that were written in Forth or assembler).
>
> Yes; the main problem is a change in philosophy, I'd say, rather
than
> implementation language.
>
Well, it's both. As I said direct access to the internals of a Forth
written in Java just isn't possible, so the implementation language
does limit you in deciding how to implement something. But the reason
for that is again because of the way Java was designed which is due
to a change in philosophy.
> >Also, I'm not completely sure but from what I know Charles Moore's
> >ColorForth doesn't have a word like PARSE or WORD nor does it give
> >you access to some form of an input buffer and I don't think it
> >allows you to parse ahead.
> >I could be wrong though.
>
> That's my understanding as well; in order to build a parsing word,
you have
> to modify the editor, not the language.
>
> This is an offshoot of the long-known rule that "you shouldn't
build parsing
> words". Chuck has always maintained that parsing words are bad
form, but
> nobody's ever managed to get them out of Forth -- there are too
many places
> where you need them. So he finally completely redesigned Forth,
and as a
> side effect parsing words went away. It doesn't seem to hurt as
much as I
> would have expected.
>
I never really saw parsing or immediate words as a problem in Forth.
I saw them as a meta language.
They're really just meant to aid in compiling new words - kind of
like macros.
> It's interesting that one of the old informal rules of Forth (don't
build
> parsing words) has the accidental side-effect of making Forth more
purely
> concatenative.
>
> A little sidelight:
>
> Forth uses parsing words to support things like string literals and
comments
> -- a comment is just a sequence of ignored text inside parentheses,
so we
> just define a word named "(" which discards text until it finds
a ")"
> character. A string literal is a sequence of characters inside
quotes, so
> we define a word '"' which parses text and compiles the literal
value of the
> text into the current definition until it reaches a '"' character.
>
> ColorForth turns everything on its head! In ColorForth the entire
idea of
> source text goes away; your editor loads a preparsed representation
of your
> code and presents it to you as though it were color-coded (kind of
like
> syntax highlighted) text. Comments are stored where the compiler
won't ever
> see them; literals are stored as code to compile their literal
values,
> together with some clues to help the editor display them (so a
literal PNG
> would be easily possible, and the editor would display and edit it
as a
> picture).
>
> It seems that ColorForth is more concatenative than Forth. Is it
more
> concatenative than Joy? Even definitions in ColorForth follow the
> concatenative property:
>
> :myWord do this then that ;
> :otherWord do something else ;
>
> This defines two words, myWord and otherWord. You can split this
up into
> any number of subprograms; it still defines those same two words.
Even if
> you wrap it inside some other word definition, it'll still define
those two
> words.
>
> Here's an example of those two definitions wrapped inside another
> definition:
>
> :outerWord check something IF
> :myWord do this then that ;
> THEN
> :otherWord do something else ;
>
That kind of introduces additional syntax to Forth. I know ColorForth
doesn't really have : and instead it just uses colors but it's still
true. On the other hand that syntax is part of the editor and not the
interpreter in which from what I understood defining new words isn't
possible. Since both the editor and the interpreter are both integral
parts of the language this does seem like additional complexity.
I haven't played with ColorForth so I only know what I've read about
it. I can't really see how has ColorForth improved on older Forths.
It's simply made the distinction between parsing/compiling and
interpreting more explicit.
> It's kind of hard to see what I just did. Let me expand that to
its Forth
> equivalent:
>
> : outerWord check something IF do this then that ELSE do something
else THEN
> ;
> : myWord do this then that ;
> : otherWord do something else ;
>
> As you can see, word definitions simply define _entry points_, not
> functions.
>
> >Ivan
>
> -Billy
Ivan
Serguey Zefirov — 2002-01-30 11:47:07
Hello e1_t,
среда, 30 января 2002 г., you wrote:
>>
>> e> That's a consequence of Forth being the only programming language
>> e> (that I know of anyway) that provides the programmer with full
e> access
>> e> to it's internals. This was more true with older implementations
e> of
>> e> Forth than it is now but it's mostly still the case (at least
e> with
>> e> those Forths that were written in Forth or assembler).
>>
>> Nope, this is just a matter of convenience.
>>
>> And this is the way early human mind works, otherwise we wouldn't
e> get
>> any sentences like "tom, harry and dave", where ", <name>"
>> concatenative and "and" is infix and is not concatenative. ;)
>> If you'll try to speak the above sentence you'll find that "and"
e> helps
>> to structure phrase and indicates a nearby end. It is easy to draw a
>> bunch of hypothesis from that fact.
>>
e> Right, conveniance. The reason why implementation of PARSE was so
e> conveniant in first implementations of Forth was because Forth
e> provided direct access to it's input buffer. Back then memory was
e> expensive and while now we have enough memory to build various
e> abstractions and can therefore choose different implementation
e> strategies back then this was very conveniant.
There is an unusual complexity for mantaining stack of unparsed words,
distinguishing them from words that must be executed, etc. It is more
convenient to create a program that has just two states: execute and
compile and in compile state we get only two possibilites - to compile
a reference or to execute it. And executed words can use it's own
means to determine what to do with words PARSEd ahead.
Just compare ":", ";" and "CREATE" mechanics with the machinery you
needed to be pure concatenative in any place of program text.
That's where the real genius shine - to use the simplest yet practical
approach possible.
e> Note that parsing words in initial Forths weren't there to aid in
e> adding infix or prefix operators to Forth (although it did make it
e> possible) - they were there to aid in compiling string constants and
e> similar things. So really this has nothing to do with structure of
e> spoken languages.
Structure of spoken (or communicated) languages directly affect the
way we think and creates an awesome obstacle to be overcomed by
sufficiently interested thinking being. I know very enlightened
example of this - here in Russia deafs were most often belongs to
criminal groups where their form of mind (concrete and fast style of
thinking) and unique social niche allows them to get enough money. I
do not know ANY born-deaf in the whole history of human kind that was
(or is) successful in the field where abstract thinking is a must, ie,
mathematic, programming, even car racing. This fact contrasts the
statistic for normal people and even for deaf-blinds (of course,
AFAIK, and I want to be proved wrong).
Best regards,
Serguey Zefirov mailto:
sz@...
John Cowan — 2002-01-30 17:11:06
Serguey Zefirov wrote:
> I do not know ANY born-deaf in the whole history of human kind that was
> (or is) successful in the field where abstract thinking is a must, ie,
> mathematic, programming, even car racing.
It took a bit of googling, but I turned up Omer Zak, software engineer:
http://www.zak.co.il/omer/eng/bio.html
And Dmitri Kanevsky, theoretical mathematician and speech researcher (!):
http://www.diversitycareers.com/articles/pro/oct-nov-01/att_ibm.htm
--
John Cowan <
jcowan@...>
http://www.reutershealth.com
I amar prestar aen, han mathon ne nen,
http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_
Billy Tanksley — 2002-01-30 17:57:35
From: e1_t [mailto:
e1_t@...]
>--- In concatenative@y..., Billy Tanksley <wtanksley@b...> wrote:
>> From: e1_t [mailto:e1_t@y...]
>> ThisForth provides words the ability to parse ahead using a
>> completely
>> different mechanism than is used in traditional Forths. In other
>> words, there's no need to directly access internals.
>As I said it was the case with older Forths more than it is now -
>various new implementations of Forth written in C (like ThisForth)
>and Java are implemented in different ways.
>For example you can't really directly access internals of a Forth
>written in Java.
I think we may have different definitions of "internals".
>I guess I should have explained what I meant more clearly.
>PARSE can be implemented in any Turing complete language. It's just a
>matter of how many abstractions you have to add or how much code you
>have to write before you have everything you need to implement PARSE.
No. You can't implement PARSE in C because C code has no access to its own
source. It doesn't matter how many layers of abstraction you add; C code
can't see its own source, because its source has to be completely compiled
before any part of it can run.
There's another reason you can't implement PARSE in C: C, like all other
applicative languages, is parsed by the compiler. Words can't be allowed to
take responsibility for parsing beyond their own parameters. So even if you
redefined C to make it completely capable of executing at compile-time,
you'd still be unable to implement PARSE, because parsing is limited to what
the compiler hasn't already parsed.
In Forth, and in other concatenative languages, the compiler only has to
parse up to the current word; thus, PARSE can be allowed to read, discard,
and modify code arbitrarily after the current word.
>My point, although I failed to explain it, was that I believe that
>the reason why PARSE and similar words entered Forth in first place
>was simply because implementation of such words in Forth is
>practical, intuitive and as Serguey pointed out conveniant.
>Implementation of PARSE comes quite naturally after you have access
>(or even 'simulated' access) to the input buffer (or terminal input
>buffer as it was called in old Forths).
I'd agree with this.
>In my opinion this doesn't really conflict with Forth's
>concatenativity. It does give you the power to change the language
>itself.
You haven't looked at the reason it interferes, though. The reason is that
in order for a language to be concatenative, it must be true that any single
program can be split at any token boundary to produce two valid programs.
With PARSE and its friends, this is no longer possible.
>> >Also, I'm not completely sure but from what I know Charles Moore's
>> >ColorForth doesn't have a word like PARSE or WORD nor does it give
>> >you access to some form of an input buffer and I don't think it
>> >allows you to parse ahead.
>> >I could be wrong though.
>> That's my understanding as well; in order to build a parsing word,
>> you have to modify the editor, not the language.
>> This is an offshoot of the long-known rule that "you shouldn't
>> build parsing
>> words". Chuck has always maintained that parsing words are bad
>> form, but
>> nobody's ever managed to get them out of Forth -- there are too
>> many places
>> where you need them. So he finally completely redesigned Forth,
>> and as a
>> side effect parsing words went away. It doesn't seem to hurt as
>> much as I would have expected.
>I never really saw parsing or immediate words as a problem in Forth.
Understandable. But Chuck did, and now we see one possible reason
(concatenativity) why he disliked them.
>I saw them as a meta language.
Of course. The odd thing about them is that they aren't needed for Forth
itself; no part of Forth uses them. They're needed only for certain odd
words which don't act very Forthish anyhow.
>They're really just meant to aid in compiling new words - kind of
>like macros.
Sort of. They're meant to allow you to add syntax within the language -- a
language which doesn't need syntax of its own.
>> A little sidelight:
>> It seems that ColorForth is more concatenative than Forth. Is it
>> more
>> concatenative than Joy? Even definitions in ColorForth follow the
>> concatenative property:
>> :myWord do this then that ;
>> :otherWord do something else ;
>> This defines two words, myWord and otherWord. You can split this
>> up into
>> any number of subprograms; it still defines those same two words.
>> Even if
>> you wrap it inside some other word definition, it'll still define
>> those two words.
>> Here's an example of those two definitions wrapped inside another
>> definition:
>> :outerWord check something IF
>> :myWord do this then that ;
>> THEN
>> :otherWord do something else ;
>That kind of introduces additional syntax to Forth.
Absolutely true. At the same time, it removes the need for some syntax
(note that the ELSE clause goes away; semicolon-THEN has the same effect),
and also removes the need for the subtle IMMEDIATE distinction, which can
make Forth a lot harder to read, because you can't tell the difference
between IMMEDIATE and normal words just by looking.
>I know ColorForth
>doesn't really have : and instead it just uses colors but it's still
>true.
Definitely.
>On the other hand that syntax is part of the editor and not the
>interpreter in which from what I understood defining new words isn't
>possible.
I don't understand what you're saying. Sorry.
>Since both the editor and the interpreter are both integral
>parts of the language this does seem like additional complexity.
Are you saying here that having an editor be part of the language increases
complexity of the language?
If so, then I'd agree, to a limited extent. Yes, it does make the
language's implementation bigger; but no, it keeps the written language
small and simple. In fact, it allows you to move a lot of slow computation
from compile-time into edit-time; the user will never notice the computation
in edit-time, since he's FAR slower than the slowest of the computations,
but put the same thing in compile-time and the little delays add up to make
a compile take more than human reaction time (and as a result people don't
compile as often as they should).
>I haven't played with ColorForth so I only know what I've read about
>it. I can't really see how has ColorForth improved on older Forths.
>It's simply made the distinction between parsing/compiling and
>interpreting more explicit.
Sounds like you've answered your question; that's how it improves.
However, I also am not certain that ColorForth is a true improvement,
because I also don't know it. My question was much more limited: ColorForth
is clearly more concatenative than Forth. I suspect, but don't know, that
ColorForth is more concatenative than Joy. True?
>Ivan
-Billy
e1_t — 2002-01-30 23:26:15
--- In concatenative@y..., Serguey Zefirov <sz@u...> wrote:
> Hello e1_t,
>
> ñðåäà, 30 ÿíâàðÿ 2002 ã., you wrote:
>
> >>
> >> e> That's a consequence of Forth being the only programming
language
> >> e> (that I know of anyway) that provides the programmer with full
> e> access
> >> e> to it's internals. This was more true with older
implementations
> e> of
> >> e> Forth than it is now but it's mostly still the case (at least
> e> with
> >> e> those Forths that were written in Forth or assembler).
> >>
> >> Nope, this is just a matter of convenience.
> >>
> >> And this is the way early human mind works, otherwise we wouldn't
> e> get
> >> any sentences like "tom, harry and dave", where ", <name>"
> >> concatenative and "and" is infix and is not concatenative. ;)
> >> If you'll try to speak the above sentence you'll find that "and"
> e> helps
> >> to structure phrase and indicates a nearby end. It is easy to
draw a
> >> bunch of hypothesis from that fact.
> >>
>
> e> Right, conveniance. The reason why implementation of PARSE was so
> e> conveniant in first implementations of Forth was because Forth
> e> provided direct access to it's input buffer. Back then memory was
> e> expensive and while now we have enough memory to build various
> e> abstractions and can therefore choose different implementation
> e> strategies back then this was very conveniant.
>
> There is an unusual complexity for mantaining stack of unparsed
words,
> distinguishing them from words that must be executed, etc. It is
more
Forth doesn't have a stack of unparsed words. It has an input buffer.
PARSE simply looks into the input buffer and returns a string.
In fact PARSE (or WORD) is used by Forth's outer interpreter.
It's actually very simple.
Forth's simplicity is the only reason why a working (but minimal)
Forth interpreter can fit in about 8Kb (more or less.. depending on
type of the Forth system, processor architecture - 8Kb is realistic
for 16-bit systems and 32-bit token threaded systems, multiply that
by 2 for 32-bit (in)direct threaded systems, implementation language
(8Kb is really only possible in assembler and Forth),...)
> convenient to create a program that has just two states: execute and
> compile and in compile state we get only two possibilites - to
compile
> a reference or to execute it. And executed words can use it's own
That's actually how Forth works.
Granted that it first needs to parse what you typed in.
> means to determine what to do with words PARSEd ahead.
>
Not sure what you mean by that.
> Just compare ":", ";" and "CREATE" mechanics with the machinery you
> needed to be pure concatenative in any place of program text.
>
What do you mean?
Consider the fact that a purely concatenative language still needs to
parse source text before it gets compiled or executed. Most languages
won't let you access the facilities they use to perform parsing
unlike Forth. I wouldn't call that a weakness of Forth.
> That's where the real genius shine - to use the simplest yet
practical
> approach possible.
>
If you're talking about practical approach then Forth's approach is
very practical really.
Not very aesthetic from the theoretical point of view though.
> e> Note that parsing words in initial Forths weren't there to aid in
> e> adding infix or prefix operators to Forth (although it did make
it
> e> possible) - they were there to aid in compiling string constants
and
> e> similar things. So really this has nothing to do with structure
of
> e> spoken languages.
>
> Structure of spoken (or communicated) languages directly affect the
> way we think and creates an awesome obstacle to be overcomed by
> sufficiently interested thinking being. I know very enlightened
> example of this - here in Russia deafs were most often belongs to
> criminal groups where their form of mind (concrete and fast style of
> thinking) and unique social niche allows them to get enough money. I
> do not know ANY born-deaf in the whole history of human kind that
was
> (or is) successful in the field where abstract thinking is a must,
ie,
> mathematic, programming, even car racing. This fact contrasts the
> statistic for normal people and even for deaf-blinds (of course,
> AFAIK, and I want to be proved wrong).
>
I still don't see what's this got to do with existance of parsing
words in Forth.
>
> Best regards,
> Serguey Zefirov mailto:sz@u...
Ivan
e1_t — 2002-01-30 23:28:52
--- In concatenative@y..., Billy Tanksley <wtanksley@b...> wrote:
> From: e1_t [mailto:e1_t@y...]
> >--- In concatenative@y..., Billy Tanksley <wtanksley@b...> wrote:
> >> From: e1_t [mailto:e1_t@y...]
>
> >> ThisForth provides words the ability to parse ahead using a
> >> completely
> >> different mechanism than is used in traditional Forths. In
other
> >> words, there's no need to directly access internals.
>
> >As I said it was the case with older Forths more than it is now -
> >various new implementations of Forth written in C (like ThisForth)
> >and Java are implemented in different ways.
> >For example you can't really directly access internals of a Forth
> >written in Java.
>
> I think we may have different definitions of "internals".
>
By internals I meant that Forth gives you access to the very words it
was built with. PARSE is used by Forth's outer interpreter and so is
the input buffer. And yet the programmer is still allowed to use
them. It gives you additional control over the language, compiler and
the interpreter.
> >I guess I should have explained what I meant more clearly.
> >PARSE can be implemented in any Turing complete language. It's
just a
> >matter of how many abstractions you have to add or how much code
you
> >have to write before you have everything you need to implement
PARSE.
>
> No. You can't implement PARSE in C because C code has no access to
its own
I was talking about Forth's PARSE.
Implementing that in C would probably mean implementing Forth in C.
> source. It doesn't matter how many layers of abstraction you add;
C code
> can't see its own source, because its source has to be completely
compiled
> before any part of it can run.
>
> There's another reason you can't implement PARSE in C: C, like all
other
> applicative languages, is parsed by the compiler. Words can't be
allowed to
> take responsibility for parsing beyond their own parameters. So
even if you
> redefined C to make it completely capable of executing at compile-
time,
> you'd still be unable to implement PARSE, because parsing is
limited to what
> the compiler hasn't already parsed.
>
As I said you'd have to write Forth in C.
> In Forth, and in other concatenative languages, the compiler only
has to
> parse up to the current word; thus, PARSE can be allowed to read,
discard,
> and modify code arbitrarily after the current word.
>
> >My point, although I failed to explain it, was that I believe that
> >the reason why PARSE and similar words entered Forth in first
place
> >was simply because implementation of such words in Forth is
> >practical, intuitive and as Serguey pointed out conveniant.
> >Implementation of PARSE comes quite naturally after you have
access
> >(or even 'simulated' access) to the input buffer (or terminal
input
> >buffer as it was called in old Forths).
>
> I'd agree with this.
>
> >In my opinion this doesn't really conflict with Forth's
> >concatenativity. It does give you the power to change the language
> >itself.
>
> You haven't looked at the reason it interferes, though. The reason
is that
> in order for a language to be concatenative, it must be true that
any single
> program can be split at any token boundary to produce two valid
programs.
> With PARSE and its friends, this is no longer possible.
>
Not if you see PARSE as part of Forth's meta language.
Same can be said about Joy if when you talk about Joy you also talk
about it's meta language (the == construct).
The difference is probably that Forth's meta language is written in
Forth and Forth is written in it's own meta language. So it's what
came first? The chicken or the egg?
It's sometimes hard to draw a line at where Forth's meta language
ends and where Forth begins because they're so well integrated.
> >> >Also, I'm not completely sure but from what I know Charles
Moore's
> >> >ColorForth doesn't have a word like PARSE or WORD nor does it
give
> >> >you access to some form of an input buffer and I don't think it
> >> >allows you to parse ahead.
> >> >I could be wrong though.
>
> >> That's my understanding as well; in order to build a parsing
word,
> >> you have to modify the editor, not the language.
>
> >> This is an offshoot of the long-known rule that "you shouldn't
> >> build parsing
> >> words". Chuck has always maintained that parsing words are bad
> >> form, but
> >> nobody's ever managed to get them out of Forth -- there are too
> >> many places
> >> where you need them. So he finally completely redesigned Forth,
> >> and as a
> >> side effect parsing words went away. It doesn't seem to hurt as
> >> much as I would have expected.
>
> >I never really saw parsing or immediate words as a problem in
Forth.
>
> Understandable. But Chuck did, and now we see one possible reason
> (concatenativity) why he disliked them.
>
I think he wanted to further simplify the language rather than make
it more concatenative. But that's just a speculation.
> >I saw them as a meta language.
>
> Of course. The odd thing about them is that they aren't needed for
Forth
> itself; no part of Forth uses them. They're needed only for
certain odd
> words which don't act very Forthish anyhow.
>
Well actually Forth itself is built using them. And rather then
hiding those words from the programmer Forth exposes them.
Maybe the reason why Chuck didn't like them is that those words can
easily be abused.
I personally saw (current) object oriented extensions to Forth as
abuse of those words.
Note that without those words adding such an extension would be
impossible without changing the source code.
> >They're really just meant to aid in compiling new words - kind of
> >like macros.
>
> Sort of. They're meant to allow you to add syntax within the
language -- a
> language which doesn't need syntax of its own.
>
I agree.
> >> A little sidelight:
>
> >> It seems that ColorForth is more concatenative than Forth. Is
it
> >> more
> >> concatenative than Joy? Even definitions in ColorForth follow
the
> >> concatenative property:
>
> >> :myWord do this then that ;
> >> :otherWord do something else ;
>
> >> This defines two words, myWord and otherWord. You can split
this
> >> up into
> >> any number of subprograms; it still defines those same two
words.
> >> Even if
> >> you wrap it inside some other word definition, it'll still
define
> >> those two words.
>
> >> Here's an example of those two definitions wrapped inside another
> >> definition:
>
> >> :outerWord check something IF
> >> :myWord do this then that ;
> >> THEN
> >> :otherWord do something else ;
>
> >That kind of introduces additional syntax to Forth.
>
> Absolutely true. At the same time, it removes the need for some
syntax
> (note that the ELSE clause goes away; semicolon-THEN has the same
effect),
> and also removes the need for the subtle IMMEDIATE distinction,
which can
> make Forth a lot harder to read, because you can't tell the
difference
> between IMMEDIATE and normal words just by looking.
>
> >I know ColorForth
> >doesn't really have : and instead it just uses colors but it's
still
> >true.
>
> Definitely.
>
> >On the other hand that syntax is part of the editor and not the
> >interpreter in which from what I understood defining new words
isn't
> >possible.
>
> I don't understand what you're saying. Sorry.
>
ColorForth is split into an editor and an interpreter and while
you're working with the interpreter you can't add any new words.
This discussion about ColorForth somehow got off topic, I appologize
for that.
> >Since both the editor and the interpreter are both integral
> >parts of the language this does seem like additional complexity.
>
> Are you saying here that having an editor be part of the language
increases
> complexity of the language?
>
> If so, then I'd agree, to a limited extent. Yes, it does make the
> language's implementation bigger; but no, it keeps the written
language
> small and simple. In fact, it allows you to move a lot of slow
computation
> from compile-time into edit-time; the user will never notice the
computation
Compiling doesn't take all that much time on conventional Forth
systems and can be run without pauses on even the slowest processors
(granted that you follow the Forth coding guidelines and write small
definitions). It takes a bit more time on newer native-code systems
but then again those are made for more powerful processors anyway.
> in edit-time, since he's FAR slower than the slowest of the
computations,
> but put the same thing in compile-time and the little delays add up
to make
> a compile take more than human reaction time (and as a result
people don't
> compile as often as they should).
>
> >I haven't played with ColorForth so I only know what I've read
about
> >it. I can't really see how has ColorForth improved on older
Forths.
> >It's simply made the distinction between parsing/compiling and
> >interpreting more explicit.
>
> Sounds like you've answered your question; that's how it improves.
>
> However, I also am not certain that ColorForth is a true
improvement,
> because I also don't know it. My question was much more limited:
ColorForth
> is clearly more concatenative than Forth. I suspect, but don't
know, that
> ColorForth is more concatenative than Joy. True?
>
Again it depends on how you look at Joy. If you take into account the
meta language then yes. Otherwise no, neither is more concatenative
than the other.
> >Ivan
>
> -Billy
Ivan
Serguey Zefirov — 2002-01-31 07:41:06
Hello e1_t,
÷åòâåðã, 31 ÿíâàðÿ 2002 ã., you wrote:
>>
>> There is an unusual complexity for mantaining stack of unparsed
e> words,
>> distinguishing them from words that must be executed, etc. It is
e> more
e> Forth doesn't have a stack of unparsed words.
And pure concatenative approach will. I just don't see any other way
to do it.
e> It has an input buffer.
e> PARSE simply looks into the input buffer and returns a string.
e> In fact PARSE (or WORD) is used by Forth's outer interpreter.
e> It's actually very simple.
e> Forth's simplicity is the only reason why a working (but minimal)
e> Forth interpreter can fit in about 8Kb (more or less.. depending on
e> type of the Forth system, processor architecture - 8Kb is realistic
e> for 16-bit systems and 32-bit token threaded systems, multiply that
e> by 2 for 32-bit (in)direct threaded systems, implementation language
e> (8Kb is really only possible in assembler and Forth),...)
I did two Forths - in Assembler and C.
>> convenient to create a program that has just two states: execute and
>> compile and in compile state we get only two possibilites - to
e> compile
>> a reference or to execute it. And executed words can use it's own
^^^^ their
e> That's actually how Forth works.
e> Granted that it first needs to parse what you typed in.
>> means to determine what to do with words PARSEd ahead.
>>
e> Not sure what you mean by that.
Consider word ALIAS. We may develop it that way:
ALIAS ( xt --<name>-- )
creates new dictionary item <name> which has same execution behavior
as given execution token xt.
And use it like that:
' DUP ALIAS SUPERDUP
(let word ' parse blank separated word in input stream, and return an
execution token using a dictionary search)
And we may develop it that way:
ALIAS' ( --<name>--<name>-- )
: ALIAS' ' ALIAS ;
And use it like that:
ALIAS' DUP SUPERDUP
ALIAS' know what to do with first and second word. ALIAS is more
flexible, but ALIAS' notation is shorter and "good enough".
Show me what to do with my desire for shorter notation of ALIAS' in
pure concatenative way. I'd like to see interpreter internals as well.
>> Just compare ":", ";" and "CREATE" mechanics with the machinery you
>> needed to be pure concatenative in any place of program text.
>>
e> What do you mean?
For example, what would you do with sequence like this:
wordnotindictionary1 wordnotindictionary2 ... wordnotindictionaryn
wordthatindictionary
Here your interpreter ought to have a stack of words that contains
wordnotindictionary1..n strings until it found wordthatindictionary.
Then it may perform the action. In the PARSE and WORD machinery you
use normal operand and return stacks for that, if you need it. Also
you may change separator for parsing, as in CHAR " WORD.
e> Consider the fact that a purely concatenative language still needs to
e> parse source text before it gets compiled or executed. Most languages
e> won't let you access the facilities they use to perform parsing
e> unlike Forth. I wouldn't call that a weakness of Forth.
And I. I advocate minor unconcatenativity of Forth for the simplicity
it brings to the language.
>> That's where the real genius shine - to use the simplest yet
e> practical
>> approach possible.
>>
e> If you're talking about practical approach then Forth's approach is
e> very practical really.
e> Not very aesthetic from the theoretical point of view though.
I'd like to see approach that is clean from theoretical point of
view.;)
>> e> Note that parsing words in initial Forths weren't there to aid in
>> e> adding infix or prefix operators to Forth (although it did make
e> it
>> e> possible) - they were there to aid in compiling string constants
e> and
>> e> similar things. So really this has nothing to do with structure
e> of
>> e> spoken languages.
>>
>> Structure of spoken (or communicated) languages directly affect the
>> way we think and creates an awesome obstacle to be overcomed by
>> sufficiently interested thinking being. I know very enlightened
>> example of this - here in Russia deafs were most often belongs to
>> criminal groups where their form of mind (concrete and fast style of
>> thinking) and unique social niche allows them to get enough money. I
>> do not know ANY born-deaf in the whole history of human kind that
e> was
>> (or is) successful in the field where abstract thinking is a must,
e> ie,
>> mathematic, programming, even car racing. This fact contrasts the
>> statistic for normal people and even for deaf-blinds (of course,
>> AFAIK, and I want to be proved wrong).
>>
e> I still don't see what's this got to do with existance of parsing
e> words in Forth.
Oh, no. This just a small example how language structure affects style
of thinking. Minor unconcatenativity in Forth allowed it to be so small.
Forth, in my opinion, jumps over two barriers: it simplify compiler by
allowing postfix notation where it is convenient and it simplify
compiler even further by allowing ahead parsing wherever it is useful.
First is a break from traditional notation and second is a break from
Forth main style.
Best regards,
Serguey Zefirov mailto:
sz@...
e1_t — 2002-01-31 09:33:43
--- In concatenative@y..., Serguey Zefirov <sz@u...> wrote:
> Hello e1_t,
>
> e> Forth doesn't have a stack of unparsed words.
>
> And pure concatenative approach will. I just don't see any other way
> to do it.
>
Then you're not really talking about Forth because in Forth that is
not the case.
Speaking of concatenativity as I pointed out in my other post Forth's
parsing words are much like Joy's meta language. And in that case
Forth isn't any more or less concatenative then Joy.
>
> Consider word ALIAS. We may develop it that way:
>
> ALIAS ( xt --<name>-- )
> creates new dictionary item <name> which has same execution behavior
> as given execution token xt.
>
> And use it like that:
>
> ' DUP ALIAS SUPERDUP
> (let word ' parse blank separated word in input stream, and return
an
> execution token using a dictionary search)
>
> And we may develop it that way:
>
> ALIAS' ( --<name>--<name>-- )
> : ALIAS' ' ALIAS ;
>
> And use it like that:
>
> ALIAS' DUP SUPERDUP
>
> ALIAS' know what to do with first and second word. ALIAS is more
> flexible, but ALIAS' notation is shorter and "good enough".
>
> Show me what to do with my desire for shorter notation of ALIAS' in
> pure concatenative way. I'd like to see interpreter internals as
well.
>
I still don't follow.
ALIAS is very easy to implement. Here's one possible definition:
: ALIAS CREATE , DOES> @ EXECUTE ;
If you're asking for a way to do this without parsing words I don't
think it can be done without adding additional syntax to the
language. ALIAS as such really belongs to Forth's meta language and
not Forth.
Assuming you had an optimizing Forth compiler, ALIAS is not the kind
of word you'd use in your program. It's a word you'd use to help you
in constructing things that may be needed by your program.
If you did decide to use ALIAS in your program, the program would end
up being compiled with a full blown Forth interpreter as a part of it
(because of CREATE).
I'm not saying that's bad or anything because that may just be the
kind of thing you want to do (for example if you're building a
language on top of Forth) but the thing is that a program that at run-
time requires parsing words, immediate words or parts of Forth's
interpreter (like EVALUATE or even QUIT) really requires Forth's meta
language and hence Forth itself which is what the meta language is
written in.
Maybe this concept about parsing and immediate words belonging to
Forth's meta language would be easier to grasp if those particular
words were presented as syntax of Forth (although I'm not really
happy with that definition).
> >> Just compare ":", ";" and "CREATE" mechanics with the machinery
you
> >> needed to be pure concatenative in any place of program text.
> >>
> e> What do you mean?
>
> For example, what would you do with sequence like this:
>
> wordnotindictionary1 wordnotindictionary2 ... wordnotindictionaryn
> wordthatindictionary
>
> Here your interpreter ought to have a stack of words that contains
> wordnotindictionary1..n strings until it found wordthatindictionary.
> Then it may perform the action. In the PARSE and WORD machinery you
> use normal operand and return stacks for that, if you need it. Also
> you may change separator for parsing, as in CHAR " WORD.
>
Hmm... no not really - I never mentioned anything even remotely
similar to that.
> e> Consider the fact that a purely concatenative language still
needs to
> e> parse source text before it gets compiled or executed. Most
languages
> e> won't let you access the facilities they use to perform parsing
> e> unlike Forth. I wouldn't call that a weakness of Forth.
>
> And I. I advocate minor unconcatenativity of Forth for the
simplicity
> it brings to the language.
>
> >> That's where the real genius shine - to use the simplest yet
> e> practical
> >> approach possible.
> >>
>
> e> If you're talking about practical approach then Forth's approach
is
> e> very practical really.
> e> Not very aesthetic from the theoretical point of view though.
>
> I'd like to see approach that is clean from theoretical point of
> view.;)
>
There's a language that I'd say is very clean and extremely simple
from theoretical point of view (it's not something a computer
scientist would come up with though). Now that I think about it it's
also concatenative. It's called Brainfuck.
I don't think a language can get any cleaner, smaller or simpler than
that.
I also don't think that's the kind of language you'd ever want to
program in ;)
You might want to check out this link if you haven't come across
Brainfuck already:
http://home.wxs.nl/~faase009/Ha_BF.html
> >> e> Note that parsing words in initial Forths weren't there to
aid in
> >> e> adding infix or prefix operators to Forth (although it did
make
> e> it
> >> e> possible) - they were there to aid in compiling string
constants
> e> and
> >> e> similar things. So really this has nothing to do with
structure
> e> of
> >> e> spoken languages.
> >>
> >> Structure of spoken (or communicated) languages directly affect
the
> >> way we think and creates an awesome obstacle to be overcomed by
> >> sufficiently interested thinking being. I know very enlightened
> >> example of this - here in Russia deafs were most often belongs to
> >> criminal groups where their form of mind (concrete and fast
style of
> >> thinking) and unique social niche allows them to get enough
money. I
> >> do not know ANY born-deaf in the whole history of human kind that
> e> was
> >> (or is) successful in the field where abstract thinking is a
must,
> e> ie,
> >> mathematic, programming, even car racing. This fact contrasts the
> >> statistic for normal people and even for deaf-blinds (of course,
> >> AFAIK, and I want to be proved wrong).
> >>
I just remembered that Beethoven was deaf (although he wasn't born
deaf). He composed some of his greatest work after he went deaf.
Speaking of deaf people I don't know what the statistics are and
what's the ratio of people who were born deaf to those who weren't
is, but the ratio is definitly small. Now if you compare that to the
ratio of great scientists to the total population of the world at the
time they lived I don't think it's such a big surprise there are no
famous scientists who were born deaf.
There are other factors of course. Deaf people do have to struggle
with many things we take for granted which may be another obstacle.
That's getting off topic though.
>
> e> I still don't see what's this got to do with existance of parsing
> e> words in Forth.
>
> Oh, no. This just a small example how language structure affects
style
> of thinking. Minor unconcatenativity in Forth allowed it to be so
small.
> Forth, in my opinion, jumps over two barriers: it simplify compiler
by
> allowing postfix notation where it is convenient and it simplify
> compiler even further by allowing ahead parsing wherever it is
useful.
> First is a break from traditional notation and second is a break
from
> Forth main style.
I don't agree with the second because this wasn't an addition to
Forth - it's something that's always been there (I can't actually
comment on the very first Forths written by Charles Moore though).
I also don't fully agree with the first statement either. It doesn't
really allow postfix notation where it's conveniant. Forth was
derived from Lisp (and a few other languages). Chuck just realized
that by using RPN he could eliminate parens and hence simplify the
language. From a point of view of a (unbiased) programmer RPN isn't
any more or less conveniant then other notations.
Forth doesn't use RPN where conveniant - RPN is really the only thing
Forth allows. Forth does however give you a meta language that gives
you the power to change Forth into a new language that has infix and
prefix operators or constructs.
>
>
> Best regards,
> Serguey Zefirov mailto:sz@u...
Ivan
Ocie Mitchell — 2002-01-31 18:34:43
--- e1_t <
e1_t@...> wrote:
>
> I just remembered that Beethoven was deaf (although
> he wasn't born
> deaf). He composed some of his greatest work after
> he went deaf.
>
If I remember correctly, he was only outer-ear deaf.
He was able to play the piano with a stick between his
teeth and the other end against the frame of the
piano. He was able to hear the music through bone
conduction.
Ocie Mitchell
__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
Billy Tanksley — 2002-01-31 18:58:51
From: Serguey Zefirov [mailto:
sz@...]
>Hello e1_t,
>e> Forth doesn't have a stack of unparsed words.
>And pure concatenative approach will. I just don't see any other way
>to do it.
How can you possibly have a stack of unparsed words? That's a contradiction
in terms. "Unparsed" means that the text hasn't been looked at by the
compiler, so it couldn't have been split into words or placed on a stack.
So what do you mean?
>Show me what to do with my desire for shorter notation of ALIAS' in
>pure concatenative way. I'd like to see interpreter internals as well.
You're asking for an applicative notation in a purely concatenative
language. That's literally impossible, by definition. Furthermore, there's
no need for it.
>>> Just compare ":", ";" and "CREATE" mechanics with the machinery you
>>> needed to be pure concatenative in any place of program text.
>e> What do you mean?
>For example, what would you do with sequence like this:
>wordnotindictionary1 wordnotindictionary2 ... wordnotindictionaryn
>wordthatindictionary
>Here your interpreter ought to have a stack of words that contains
>wordnotindictionary1..n strings until it found wordthatindictionary.
>Then it may perform the action. In the PARSE and WORD machinery you
>use normal operand and return stacks for that, if you need it. Also
>you may change separator for parsing, as in CHAR " WORD.
OH! Well, I would just error out the moment I hit the first
wordnotindictionary. There's no reason to keep going at that point. It
frankly makes no sense at all to go any further. So why add the notion of a
"parsed word stack"? How could it possibly improve you language to be able
to do things that make no sense?
>e> Consider the fact that a purely concatenative language
>e> still needs to
>e> parse source text before it gets compiled or executed. Most
>e> languages
>e> won't let you access the facilities they use to perform parsing
>e> unlike Forth. I wouldn't call that a weakness of Forth.
>And I. I advocate minor unconcatenativity of Forth for the simplicity
>it brings to the language.
I actually agree. However, I do call it a lack of pure concatenativity,
because it IS. That's not an insult to Forth; on the contrary, it's
incredible to note that although nothing was known about concatenativity at
the time, Forth was nonetheless the pioneer of concatenativity.
It's of historical interest as well that the traditions of Forth encourage
less use of its less concatenative features. I can see that you two don't
like that tradition, but the fact remains that it's there, and the inventor
of Forth was at the forefront in trying to support the tradition, even
though he's as untheoretical of a person as you could imagine.
>Serguey Zefirov mailto:sz@...
-Billy
Billy Tanksley — 2002-01-31 19:16:48
From: e1_t [mailto:
e1_t@...]
>--- In concatenative@y..., Serguey Zefirov <sz@u...> wrote:
>Speaking of concatenativity as I pointed out in my other post Forth's
>parsing words are much like Joy's meta language. And in that case
>Forth isn't any more or less concatenative then Joy.
This is a severe abuse of the term "meta language". A metalanguage is a
language in which you write other languages. Forth's metalanguage is Forth
(and Forth is designed to be a metalanguage). Joy's metalanguage is C.
Joy (the language) contains some non-concatenative features. These features
are required to write real programs, so Joy isn't purely concatenative.
Forth is in the same situation, but it also provides programmer access to
the non-concatenative features. So not only is Forth non-concatenative, you
can write further things in Forth which are even less concatenative.
>: ALIAS CREATE , DOES> @ EXECUTE ;
>If you're asking for a way to do this without parsing words I don't
>think it can be done without adding additional syntax to the
>language. ALIAS as such really belongs to Forth's meta language and
>not Forth.
I find your definition of "meta language" to be lacking. Forth is one
language, not two; so is Joy. There aren't two seperate languages.
>Ivan
-Billy
e1_t — 2002-01-31 23:52:57
--- In concatenative@y..., Billy Tanksley <wtanksley@b...> wrote:
> From: e1_t [mailto:e1_t@y...]
> >--- In concatenative@y..., Serguey Zefirov <sz@u...> wrote:
> >Speaking of concatenativity as I pointed out in my other post
Forth's
> >parsing words are much like Joy's meta language. And in that case
> >Forth isn't any more or less concatenative then Joy.
>
> This is a severe abuse of the term "meta language". A metalanguage
is a
> language in which you write other languages. Forth's metalanguage
is Forth
> (and Forth is designed to be a metalanguage). Joy's metalanguage
is C.
>
I don't think so. On the contrary. C is not a meta language - C is a
general purpose programming language. By your definition of a meta
language assembler would be the meta language for an implementation
of Forth written in assembler.
Meta languages are more specialised.
Forth is a meta language as it provides the facilities for defining
new languages (and note that is only true because of it's immediate
words - ColorForth is not a meta language).
StandardML was first designed as a meta language for theorem proving
systems (hence the name Standard Meta Language).
Also note that in papers on Joy, meta language does not reffer to C.
> Joy (the language) contains some non-concatenative features. These
features
> are required to write real programs, so Joy isn't purely
concatenative.
>
Not completely true. Programming in Joy would be possible even
without the == construct although it would be more difficult and
impractical.
> Forth is in the same situation, but it also provides programmer
access to
> the non-concatenative features. So not only is Forth non-
concatenative, you
> can write further things in Forth which are even less concatenative.
>
Yes, because Forth gives you access to it's meta language.
> >: ALIAS CREATE , DOES> @ EXECUTE ;
> >If you're asking for a way to do this without parsing words I
don't
> >think it can be done without adding additional syntax to the
> >language. ALIAS as such really belongs to Forth's meta language
and
> >not Forth.
>
> I find your definition of "meta language" to be lacking. Forth is
one
> language, not two; so is Joy. There aren't two seperate languages.
>
Again not completely true. Chuck Moore has said on a few occasions
that he saw immediate words as something that didn't belong to Forth
and that's why he eliminated them from ColorForth.
As I already said immediate words are the very thing gives the
programmer the power to change Forth or to add extensions to Forth.
They can really be seen as a separate language.
> -Billy
Ivan
Manfred von Thun — 2002-02-01 05:38:06
I have placed a small Lisp interpreter written in Joy onto the
main Joy page, at the end of the Joy libraries section.
Files:
1 lsplib.joy - the interpreter itself, written in Joy.
It has the classical Eval+Apply format,
wrapped inside a classical Read-Eval-Print loop.
2 lsplib.lsp - a collection of definitions, just for this Lisp,
but without tests.
3 lsptst.lsp - same as the previous (2),
but with tests.
4 lsptst.joy - a driver:
some tests for just (1), followed by all tests in (3)
5 lsptst.out - the output from (4)
Do not use it for any serious Lisp programming, because there
is no error checking, and any error throws you off without any
explanation. The aim was to write a truly complex Joy program
in (1).
I shall write some documentation about the interpreter as soon
as possible.
In the meantime .. enjoy
- Manfred
Manfred von Thun — 2002-02-01 09:12:12
Let me explain what I think is the conventional usage of these
terms, at least in the literature that I am familiar with.
In formal language theory a language is a set of strings of
symbols (characters or words or punctuation signs).
The less interesting languages are the finite sets, they can be
specified by simple enumeration of their members. But most languages
of interest are infinite, even if every member is only finitely long.
For these the question arises whether that infinite set can be
specified in a finite way.
For the true sentences of arithmetic, and for some other sets too,
the answer is NO, there is no finite specification (Goedel).
For most others the answer is YES, and all sorts of ways of giving
such finite specifications are available. Grammars and other recursive
mechanisms are one way, Turing and Post machines are another,
well written natural language another.
The best known grammars are the context free grammars, and a language
which can be so specified is called a context free language.
Most programming languages are not context free. For their full
specification one needs something stronger: attribute grammars,
vW grammars, well written natural language.
In any of these cases the object language is the one being specified,
and the metalanguage is the one in which the specification is
written. One and the same object language can be specified in
many different metalanguages - provided these metalanguages are
powerful enough. So an object language does not have a particular
metalanguage in which it _is_ or _must_ be specified. For example
the grammar (or better: a grammar) for Japanese can be written in
English or in French, or in any other natural language that has
sufficient concepts for talking about languages. (The subset of
English that is spoken by a four-year old is not sufficient.
This is true even though a four-year old would be much quicker
than an adult at learning Japanese by - well - linguistic osmosis.)
Just about all programming languages are suitable as metalanguages
for specifying object languages, provided the basic symbols of
the object language can be rendered in ASCII. This includes
programming languages as object languages. So one can write
in the metalanguage Pascal a specification (a parser) for the
object language Lisp. One can do the same thing in reverse.
One can even write a parser for a language in the very same language.
Everything I have said so far was only about syntax, specifying what
the language is. I have said nothing about semantics, concerned
with the meaning of various parts of the language. But much the
same holds here, except that the metalanguage now has to have
sufficient concepts to express meaning.
There are two ways of specifying the semantics of an object
language, by using an adequate metalanguage to write
what is called an implementation, which may be
a) an interpreter of the object language, or
b) a compiler from the object language (now called the source)
into another language (called the target).
Typical examples are interpreters for object languages such
as Lisp, Joy etc implemented in metalanguages such as Pascal or C.
Other examples are compilers from object languages such as
Pascal, C, Haskell implemented in some metalanguage to produce
target code which is machine language or some other language
which will be interpreted.
Again it is possible to write an interpreter for, say, Lisp
in Lisp itself, and this used to be quite common for exploring
extensions of Lisp. It is also possible to write a compiler
for, say, Pascal in Pascal itself, and this is how the early
versions of Pascal were developed. Finally, things can go
round a circle: C is written in Yacc, which is written in C.
Again, what was true for syntax also holds for semantics:
An object language and its meaning are not specifically
associated with any particular metalanguage - any adequate
metalanguage will do.
In some languages such as Lisp, Prolog and Joy, program = data
and hence these languages are particularly good at manipulating
their own programs with a minimum of fuss. In other languages
such as Pascal and C such manipulation must be (at least
initially) at the level of characters. But any of these,
Lisp, Prolog, Joy, Pascal and C can serve as their own metalanguage,
both for writing interpreters or for writing compilers.
Well - I did not intend to write a lecture, really.
Sorry.
- Manfred
Manfred von Thun — 2002-02-02 00:48:26
On Fri, 1 Feb 2002, Manfred von Thun wrote:
> I have placed a small Lisp interpreter written in Joy onto the
> main Joy page, at the end of the Joy libraries section.
...
I failed to mention that I needed to make two small changes elsewhere:
1. interp.c - a new operator "case", a sort of cross between
"opcase" and "cond". Without such an operator
the "eval" and "apply" functions in Lisp are
ugly and inefficient.
You should recompile your Joy with the new interp.c
2. inilib.joy - a very small addition: call == [] cons i
This is used just once in the Lisp interpreter,
and it is not clear whether it needs to be in
a library at all. Quite a while ago somebody
(was it Billy ?) commented on the desirability
of being able to execute an operator, say +,
which got onto the stack, say by [+] first.
Now call can execute it. (In the Lisp it is
used differently, though.)
Sorry about that.
- Manfred
Heiko.Kuhrt@t-online.de — 2002-02-02 13:59:21
On Sat, 2 Feb 2002, Manfred von Thun wrote:
>
> On Fri, 1 Feb 2002, Manfred von Thun wrote:
>
> > I have placed a small Lisp interpreter written in Joy onto the
> > main Joy page, at the end of the Joy libraries section.
> ...
> 2. inilib.joy - a very small addition: call == [] cons i
> This is used just once in the Lisp interpreter,
> and it is not clear whether it needs to be in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> a library at all. Quite a while ago somebody
^^^^^^^^^^^^^^^^
> (was it Billy ?) commented on the desirability
> of being able to execute an operator, say +,
> which got onto the stack, say by [+] first.
> Now call can execute it. (In the Lisp it is
> used differently, though.)
>
> Sorry about that.
>
> - Manfred
In my opinion it is a good idea to to have it in the libs.
I will change my j == unitlist i;
-Heiko