Suppose you had a string say s="ABCDEF", and you indexed it using:

s[3]

would the result be a character, or a string of length 1?

(For years I've been using a language with the latter approach, and it's
worked well (after all why should s[3] be that different from the slice
s[3..4]), with asc(s[3]) to get the character value.)

But which is better?

On 27 Aug, 11:44, "bartc" <ba... at (no spam) freeuk.com> wrote:

Suppose you had a string say s="ABCDEF", and you indexed it using:

s[3]

would the result be a character, or a string of length 1?

...But which is better?

Were you querying the existence of a separate char data type or simply
the result of a substring reference?

Perhaps the answer depends on string representation. C supports a char
data type but its strings have a terminating zero so C has to
distinguish, doesn't it? A character occupies a single cell but a
string of one character needs at least two cells.

On Sun, 30 Aug 2009 03:52:29 -0700 (PDT), James Harris wrote:
On 27 Aug, 11:44, "bartc" <ba... at (no spam) freeuk.com> wrote:

...

Suppose you had a string say s="ABCDEF", and you indexed it using:

s[3]

would the result be a character, or a string of length 1?

(For years I've been using a language with the latter approach, and it's
worked well (after all why should s[3] be that different from the slice
s[3..4]), with asc(s[3]) to get the character value.)

But which is better?

I don't know which is best but I think the question deserves its own
thread.

Were you querying the existence of a separate char data type or simply
the result of a substring reference?

Depends on the semantics of []. There are two different operations,
substring extraction and element extraction. [] can mean either. Yet both
are required.

On 27 Aug, 11:44, "bartc" <ba... at (no spam) freeuk.com> wrote:

...

Suppose you had a string say s="ABCDEF", and you indexed it using:

s[3]

would the result be a character, or a string of length 1?

(For years I've been using a language with the latter approach, and it's
worked well (after all why should s[3] be that different from the slice
s[3..4]), with asc(s[3]) to get the character value.)

But which is better?

I don't know which is best but I think the question deserves its own
thread.

Were you querying the existence of a separate char data type or simply
the result of a substring reference?

Perhaps the answer depends on string representation. C supports a char
data type but its strings have a terminating zero so C has to
distinguish, doesn't it? A character occupies a single cell but a
string of one character needs at least two cells.

On 27 Aug, 11:44, "bartc" <ba... at (no spam) freeuk.com> wrote:

...

Suppose you had a string say s="ABCDEF", and you indexed it using:

s[3]

would the result be a character, or a string of length 1?

Unfortunately I don't undestand what you are saying. Is this an
idealogic objection or a pragmatic one?

On Mon, 31 Aug 2009 15:01:41 -0700 (PDT), James Harris wrote:

Unfortunately I don't undestand what you are saying. Is this an
idealogic objection or a pragmatic one?

A pragmatic one, I thought about the consequences of making string an
element of itself.

On 1 Sep, 09:25, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:

On Mon, 31 Aug 2009 15:01:41 -0700 (PDT), James Harris wrote:
Unfortunately I don't undestand what you are saying. Is this an
idealogic objection or a pragmatic one?

A pragmatic one, I thought about the consequences of making string an
element of itself.

Well, in that case, what are you saying about it? Are you saying it is
impossible? If so, why? Or is your point that it should not be used in
any language, or that it's fine for some languages but not others?

Or does it depend on the operation? For example, slicing is OK but
concatenation and comparison aren't?

To make something concrete to discuss, here's a possible code sequence
using slicing (slicing and indexing were Bart's initial questions):

On Sep 2, 6:20 pm, James Harris <james.harri... at (no spam) googlemail.com> wrote:



On 1 Sep, 09:25, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:

On Mon, 31 Aug 2009 15:01:41 -0700 (PDT), James Harris wrote:
Unfortunately I don't undestand what you are saying. Is this an
idealogic objection or a pragmatic one?

A pragmatic one, I thought about the consequences of making string an
element of itself.

Well, in that case, what are you saying about it? Are you saying it is
impossible? If so, why? Or is your point that it should not be used in
any language, or that it's fine for some languages but not others?

Or does it depend on the operation? For example, slicing is OK but
concatenation and comparison aren't?

To make something concrete to discuss, here's a possible code sequence
using slicing (slicing and indexing were Bart's initial questions):

I've realised that there are a few other issues in my design, and
perhaps it's best to treat the various indexable objects separately.

Aside from arrays and strings, I can also index integers (trust me,
it's useful..):

a := (100,200,300,400)  # array of 4 ints
b := a[1]               # b is a single int 100 (not an array of 1
int)
c := a[1..3]            # c is a slice/array of 3 ints (100,200,300)
d := b[1]               # (d is an int too, but has value 0 now; bit 1
of 100)

a := "ABCDEF"           # a is a string of 6 characters
b := a[1]               # b is a string "A" of 1 character (1-based)
c := a[1..3]            # c is a string of 3 characters
d := b[1]               # d is a string "A" of 1 character
(repeatedly..)

a := 123                # a is an integer (111_1011B)
b := a[1]               # b is an integer 1 (bit 1 of 123, 0-based)
c := a[1..3]            # c is an integer 5 (bits 1 to 3 of 123)
d := b[1]               # d is an integer 0 (bit 1 of 1)

So strings and integers share the same property that index and slice
operations on them still yield a string or integer.

On arrays of type T (although the language uses variants), indexing
and slicing yield respectively objects of T, and array of T.

A single-element slice of an array can be achieved with a single index
using (a[i],), (although a[i..i] is more efficient, it looks slightly
more naff).

And the int-char value of a 1-element string is obtained with a
special function (asc(a[i])).

Strings of course can therefore be indexed any number of times:
"ABC"[1,1,1,1,1,....] but this is not harmful. Which brings me to
another concern:

Should the construction A[I,J,K] be multiple dimension array indexing,
or should I insist on A[I][J][K] as C does? Then A[I,J,K] is useful
new syntax.

On 2 Sep, 21:19, Bart <b... at (no spam) freeuk.com> wrote:

a := 123                # a is an integer (111_1011B)
b := a[1]               # b is an integer 1 (bit 1 of 123, 0-based)
c := a[1..3]            # c is an integer 5 (bits 1 to 3 of 123)
d := b[1]               # d is an integer 0 (bit 1 of 1)

I've tried to make sense of some of these but not all of them. Are you
indexing bits from the left or from the right and are you using these
0-based or 1-based?

Should the bit index operation be c := a[3..1]? What if it is?

Should the construction A[I,J,K] be multiple dimension array indexing,
or should I insist on A[I][J][K] as C does? Then A[I,J,K] is useful
new syntax.

Not sure. A[i][j][k] looks good to me though it's closer to my syntax
which would sway my opinion.

On 1 Sep, 09:25, "Dmitry A. Kazakov" <mail... at (no spam) dmitry-kazakov.de
wrote:

On Mon, 31 Aug 2009 15:01:41 -0700 (PDT), James Harris wrote:

Unfortunately I don't undestand what you are saying. Is this an
idealogic objection or a pragmatic one?

A pragmatic one, I thought about the consequences of making string an
element of itself.

Well, in that case, what are you saying about it? Are you saying it is
impossible? If so, why? Or is your point that it should not be used in
any language, or that it's fine for some languages but not others?

Or does it depend on the operation? For example, slicing is OK but
concatenation and comparison aren't?

To make something concrete to discuss, here's a possible code sequence
using slicing (slicing and indexing were Bart's initial questions):

s = "john smith"
pos = s.find(" ", ":") #To find a space or a colon delimiter
first = s[.. pos - 1] #The string up to the char before pos
delim = s[pos]
last = s[pos + 1 ..]

Now, given that we have three result strings (one of which is only one
character long) we could, perhaps, get the first element of each as

first[0]
delim[0]
last[0]

I /think/ you are saying we shouldn't be able to take the first
element of delim as it is already just one character long.

Or are you talking about having an array of strings being
automatically flattened such as

a[0] = "john"
a[1] = " "
a[2] = "smith"
if (a == "john smith") ...

I'm not sure about this latter example which I think is closest to the
ones you wrote. Perhaps it depends on the rest of the language but
most naturally a[0] seems to equal "john" and a[0][0] equals "j". I
can't see any need to run them together.

James Harris <james.harris.1 at (no spam) googlemail.com> writes:

On 27 Aug, 11:44, "bartc" <ba... at (no spam) freeuk.com> wrote:

would the result be a character, or a string of length 1?

(For years I've been using a language with the latter approach, and it's
worked well (after all why should s[3] be that different from the slice
s[3..4]), with asc(s[3]) to get the character value.)

But which is better?
Were you querying the existence of a separate char data type or simply
the result of a substring reference?

Perhaps the answer depends on string representation. C supports a char
data type but its strings have a terminating zero so C has to
distinguish, doesn't it? A character occupies a single cell but a
string of one character needs at least two cells.

I'm in favour of having separate string and character types, primarily
because you by specifying a character type specify the expectation that
you get exactly one character in a way that can be cehcked statically.
If you just specify a string type, you would need runtime checks to
verify that there is exactly one character.

Additionally, a string is a sequence of characetrs, so a good solution
is to have the language suport a generic sequence type and let strings
be one instance of this. For example, in Pascal, strings were (at least
originally) just packed arrays of characters, and in C they are arrays
of characters with 0 termination. An array is, however, not a very good
sequence representation. Haskell uses lists of characters as strings,
which is better, but random access to string elements becomes slow. I
would rather see a generic sequence type where random access,
concatenation and substring are all at most O(log(n)). This can be
achieved by using a tree structure.

Torben