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