# 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