# RE: [stack] (Re: ...) Strings and quotations

## Billy Tanksley — 2001-10-18 17:55:03

    From: dmitry_n_petrov@... [mailto:dmitry_n_petrov@...]

    [Assumption: let quotations be represented by the string datatype.]

     >If strings are quotations, then they can be unquoted.

     It's fairly obvious that not all strings are quotations; any string which

    doesn't form a program isn't a quotation.

     >Such understanding of string does not require programs to be

    >represented as strings (if this is a bad thing), but it needs a

    >built-in interpreter, to unquote strings.

     Right; same with lists.

     >Problem here is that strings

    >are first-class values, and do not have structure that quotations (and

    >lists) actually have. Compile-time semantic analysis also becomes a

    >problem: one can not know any semantic properties of quotation, that

    >is a result of a string operation.

     How does this differ from a list?  Or, for that matter, from an arbitrary

    machine-language binary (without JUMPs)?  Semantic properties are ALWAYS

    hard to discover.

    Both lists and strings -- and quotations -- have the same structure: linear.

    What more structure do you want?  By definition of concatenativity, that's

    exactly what you need.

     >If I am wrong, please, tell me, where and why.

     I don't know -- I can't even see the distinction you're trying to make.

    -Billy

## dmitry_n_petrov@yahoo.com — 2001-10-19 12:38:56

    >

    > [Assumption: let quotations be represented by the string datatype.]

     Yes, this is the cause of trobules.

    Strings have their specific (character-based) operations, that make

    semantic analysis impossible. Number of dynamic errors will increase,

    but these errors could be found at compile-time.

    1.) Not every string is a syntactically correct quotation.

    Ex.: Take a correct quotation. Treat it as string. Apply

    string-specific operation (for example, concat some "funny" sequence

    of characters).

    2.) Types, stack underflow and so on -- they all go to dynamic errors.

    Why? When we apply some string-specific operation to a quotation

    represented as string, we can not tell anything about its semantic

    properties: this task has no algorythm to solve.

    Note, that both (1) and (2) are pretty well (and easy) solved, if we

    do not treat quotations as strings (well, to disallow string-specific

    operations on them - and what reason remains to represent them as

    strings after this limitation?).

    Lists are also not so good (either they eliminate 1st erroneous case).

    Maybe, the best way is to introduce quotations as a specific type,

    subtype of lists. They can be concat-ed and cons-ed, but all

    projectors (uncons, member, ... etc) return lists and atoms as result.

    All these problems, anyway, arise only in case of compiled,

    strictly-typed variation. If your goal is an interpreted language,

    well, good luck. My "counter-ideas" do not do anything bad to

    concatenative programming in common; if someone will ever use

    concatenative language in a serious project (yes, I did take part in

    one project based on Forth; resume - difficulties grow exponentially

    with project size), some strictness is required (imho?).

    Thanx,

    Dmitry

## dmitry_n_petrov@yahoo.com — 2001-10-19 12:39:09

    >

    > [Assumption: let quotations be represented by the string datatype.]

     Yes, this is the cause of trobules.

    Strings have their specific (character-based) operations, that make

    semantic analysis impossible. Number of dynamic errors will increase,

    but these errors could be found at compile-time.

    1.) Not every string is a syntactically correct quotation.

    Ex.: Take a correct quotation. Treat it as string. Apply

    string-specific operation (for example, concat some "funny" sequence

    of characters).

    2.) Types, stack underflow and so on -- they all go to dynamic errors.

    Why? When we apply some string-specific operation to a quotation

    represented as string, we can not tell anything about its semantic

    properties: this task has no algorythm to solve.

    Note, that both (1) and (2) are pretty well (and easy) solved, if we

    do not treat quotations as strings (well, to disallow string-specific

    operations on them - and what reason remains to represent them as

    strings after this limitation?).

    Lists are also not so good (either they eliminate 1st erroneous case).

    Maybe, the best way is to introduce quotations as a specific type,

    subtype of lists. They can be concat-ed and cons-ed, but all

    projectors (uncons, member, ... etc) return lists and atoms as result.

    All these problems, anyway, arise only in case of compiled,

    strictly-typed variation. If your goal is an interpreted language,

    well, good luck. My "counter-ideas" do not do anything bad to

    concatenative programming in common; if someone will ever use

    concatenative language in a serious project (yes, I did take part in

    one project based on Forth; resume - difficulties grow exponentially

    with project size), some strictness is required (imho?).

    Thanx,

    Dmitry

## dmitry_n_petrov@yahoo.com — 2001-10-19 12:39:08

    >

    > [Assumption: let quotations be represented by the string datatype.]

     Yes, this is the cause of trobules.

    Strings have their specific (character-based) operations, that make

    semantic analysis impossible. Number of dynamic errors will increase,

    but these errors could be found at compile-time.

    1.) Not every string is a syntactically correct quotation.

    Ex.: Take a correct quotation. Treat it as string. Apply

    string-specific operation (for example, concat some "funny" sequence

    of characters).

    2.) Types, stack underflow and so on -- they all go to dynamic errors.

    Why? When we apply some string-specific operation to a quotation

    represented as string, we can not tell anything about its semantic

    properties: this task has no algorythm to solve.

    Note, that both (1) and (2) are pretty well (and easy) solved, if we

    do not treat quotations as strings (well, to disallow string-specific

    operations on them - and what reason remains to represent them as

    strings after this limitation?).

    Lists are also not so good (either they eliminate 1st erroneous case).

    Maybe, the best way is to introduce quotations as a specific type,

    subtype of lists. They can be concat-ed and cons-ed, but all

    projectors (uncons, member, ... etc) return lists and atoms as result.

    All these problems, anyway, arise only in case of compiled,

    strictly-typed variation. If your goal is an interpreted language,

    well, good luck. My "counter-ideas" do not do anything bad to

    concatenative programming in common; if someone will ever use

    concatenative language in a serious project (yes, I did take part in

    one project based on Forth; resume - difficulties grow exponentially

    with project size), some strictness is required (imho?).

    Thanx,

    Dmitry

## Billy Tanksley — 2001-10-19 18:06:58

    From: dmitry_n_petrov@... [mailto:dmitry_n_petrov@...]

     >> [Assumption: let quotations be represented by the string datatype.]

    >Yes, this is the cause of trobules.

     No, it's not.  You keep ignoring all discussion and just making that same

    statement over and over again.  Listen to me.

     >Strings have their specific (character-based) operations, that make

    >semantic analysis impossible. Number of dynamic errors will increase,

    >but these errors could be found at compile-time.

     All correct.  This is a fundamental problem with quotations in general!

     >1.) Not every string is a syntactically correct quotation.

    >Ex.: Take a correct quotation. Treat it as string. Apply

    >string-specific operation (for example, concat some "funny" sequence

    >of characters).

     Correct.  The concatenative property only applies when you concatenate two

    previously valid programs.  Again, a fundamental problem of quotations, not

    of strings.

     >2.) Types, stack underflow and so on -- they all go to dynamic errors.

    >Why? When we apply some string-specific operation to a quotation

    >represented as string, we can not tell anything about its semantic

    >properties: this task has no algorythm to solve.

     That's a fundamental problem of PROGRAMS in general.  According to Rice's

    theorem, dividing programs into classes is uncomputable.

    Now, if the quotations have properties attached to them, their concatenation

    will have derived properties.  This is pretty obvious.

     >Note, that both (1) and (2) are pretty well (and easy) solved, if we

    >do not treat quotations as strings (well, to disallow string-specific

    >operations on them - and what reason remains to represent them as

    >strings after this limitation?).

     That doesn't solve the problems -- it doesn't even begin to.  The problems

    are fundamental.  It's true that you can create bad programs of a different

    type with strings than you can with lists, but both are equally bad, and

    equally un-analysable.

     >Lists are also not so good (either they eliminate 1st erroneous case).

     They only eliminate one manifestation of the first case.  You still get

    unpredictable results, and you can still frustrate automated analysis.

     >Maybe, the best way is to introduce quotations as a specific type,

    >subtype of lists. They can be concat-ed and cons-ed, but all

    >projectors (uncons, member, ... etc) return lists and atoms as result.

     Actually, by the concatenative property the dissections are legal and the

    resulting types can be computed.  The problem comes when you allow truly

    arbitrary (untyped) manipulations.

     >All these problems, anyway, arise only in case of compiled,

    >strictly-typed variation.

     Yes, essentially.  As Becher's work implies, they can be worked around by

    requiring and using type declarations for quotations.

     >If your goal is an interpreted language,

    >well, good luck. My "counter-ideas" do not do anything bad to

    >concatenative programming in common; if someone will ever use

    >concatenative language in a serious project (yes, I did take part in

    >one project based on Forth; resume - difficulties grow exponentially

    >with project size), some strictness is required (imho?).

     Sounds like a well-grounded opinion to me (don't all difficulties grow

    exponentially with problem size?).

     >Dmitry

     -Billy

## John Cowan — 2001-10-26 04:24:18

    Billy Tanksley scripsit:

     > Both lists and strings -- and quotations -- have the same structure: linear.

     But they have a fundamental difference, at least in Joy: strings are

    homogeneous (they contain only characters), whereas lists are heterogeneous

    (they can contain strings, numbers, lists, booleans, symbols, etc.).

    Specifically, lists can and do contain lists, but strings don't contain

    strings.

    --

    John Cowan           http://www.ccil.org/~cowan              cowan@...

    Please leave your values        |       Check your assumptions.  In fact,

       at the front desk.           |          check your assumptions at the door.

         --sign in Paris hotel      |            --Miles Vorkosigan

## Billy Tanksley — 2001-10-26 19:01:24

    From: John Cowan [mailto:cowan@...]

     >Billy Tanksley scripsit:

    >> Both lists and strings -- and quotations -- have the same

    >> structure: linear.

    >Specifically, lists can and do contain lists, but strings don't contain

    >strings.

     A mere technicality of the current implementation.  Strings can in reality

    contain anything that the source can, and literal lists can't hold anything

    that the source can't.

    If the delimiters of strings were changed to something which could be

    recursive, such as [], they would hold the same things lists do now.

    Again, though, I'm not suggesting this for Joy.  It's more appropriate for

    Forth-quotations.

     >John Cowan           http://www.ccil.org/~cowan

     -Billy

## John Cowan — 2001-10-27 04:39:57

    Billy Tanksley scripsit:

     > >Specifically, lists can and do contain lists, but strings don't contain

    > >strings.

    >

    > A mere technicality of the current implementation.  Strings can in reality

    > contain anything that the source can, and literal lists can't hold anything

    > that the source can't.

     No, not at all.  This is a fundamental map/territory confusion.  The

    string "1.0" does not contain a float, but rather the three characters

    "1", ".", and "0", which constitute the string *representation* of a float.

    The representation of a float is not a float.

    --

    John Cowan           http://www.ccil.org/~cowan              cowan@...

    Please leave your values        |       Check your assumptions.  In fact,

       at the front desk.           |          check your assumptions at the door.

         --sign in Paris hotel      |            --Miles Vorkosigan

## Billy Tanksley — 2001-10-29 17:09:30

    From: John Cowan [mailto:cowan@...]

     >Billy Tanksley scripsit:

    >> >Specifically, lists can and do contain lists, but strings

    >> >don't contain strings.

    >> A mere technicality of the current implementation.  Strings

    >> can in reality contain anything that the source can, and

    >> literal lists can't hold anything that the source can't.

    >No, not at all.  This is a fundamental map/territory confusion.  The

    >string "1.0" does not contain a float, but rather the three characters

    >"1", ".", and "0", which constitute the string

    >*representation* of a float. The representation of a float is not a

    >float.

     Of course the representation of an Abstract Data Type is not the same as the

    ADT itself; that's why ADTs have functions defined on them.  If you're going

    to complain about strings like this you should also be complaining about

    binary.  *Everything* in a computer is a representation.

     >John Cowan           http://www.ccil.org/~cowan

     -Billy