Ticket #0002177

Type	Wish	Status	submitted	Date	3-Oct-2014 01:35
Version	r3 master	Category	Datatype	Submitted by	fork
Platform	All	Severity	major	Priority	normal

Summary	Make TUPLE! implementation run as ANY-STRING! under the hood
Description	TUPLE! is currently very limited both in its range of element values, and the number of values it can support. 255.255.255 is valid, for instance...while 256.257.258 is not. The constraints are applied because TUPLE! was designed to fit into a value slot. This limitation is not going to please people, and seems misguided in something you use for semantic version numbering. Especially in systems where you need to constantly bump the most minor version number or they won't allow new commits. You simply can't push a version that has the same minor version into deployment. It gets into the thousands very easily. http://semver.org The constraint could be disposed while making a tuple! no more costly than a string! ... which is a series of codepoints of positive ranging integers, and not a series of generic Rebol values. Regarding the current behavior, consider the difference: foo: [1 2 3] bar: foo print [{second foo is} second foo] foo/2: 100 print [{after change, second foo is} second foo {and second bar is} second bar] That produces: second foo is 2 after change, second foo is 100 and second bar is 100 Trying with a tuple: foo: 1.2.3 bar: foo print [{second foo is} second foo] foo/2: 100 print [{after change, second foo is} second foo {and second bar is} second bar] You will get: second foo is 2 after change, second foo is 100 and second bar is 2 If TUPLE! was able to store a greater capacity such as that for codepoints in Unicode, the underlying implementation is already there and it's just a matter of rendering. Construction syntax would allow for creating tuples of lengths shorter than two; and MOLD should be sensitive to that (as it should with the result of reversing a URL! for instance). It would probably be nice to have a syntax for hexadecimal and other input notations, but that doesn't need to be a priority. The main issue I see here is that if TUPLE! is to become an ANY-STRING! in spirit, is the behavior of appending an integer. Note the behaviors are different today for strings and binaries: >> append "abc" 12 == "abc12" >> append #{AABBCC} 12 == #{AABBCC0C} This is something that we might call into question in the first place, as to whether FORMing 12 makes more sense than adding the codepoint 12. Routines like COMBINE offer richer ways of connecting things intentionally, so perhaps the purpose of APPEND should be rethought. In any case, appending an integer to a tuple should stick the integer onto the tuple. And other operations like TAKE or PICK would be expected to give integers back vs. characters. So that raises a question as to if that would push it out of the ANY-STRING! class or not. It probably does, but maybe it would be an ANY-BINARY! ? Don't know. But it could still use the same implementation as the ANY-STRING!s under the hood. The optimization of trying to limit both the length of elements in a tuple and their values, and not having the same semantics as other series, suggests a priority of tuple compaction that does not make it a good candidate for many of its supposed applications...and which seems to distort the priority of this packing in the scheme of other things.
Example code

Assigned to	n/a	Fixed in	-	Last Update	31-Oct-2014 02:14

Comments
(0004532) BrianH 21-Oct-2014 18:41	Read through #1976 before you make any suggestions. Larger number spaces were part of that discussion, and proposed in a way that doesn't have the downsides of your proposal. Btw, they're not characters, so not any-string!; they're not bytes, so not binary! (though all types are binary in one way or another underneath). You're thinking of vectors of integers as an underlying datatype. But we would need to keep the immutable, immediate semantics.
(0004535) fork 31-Oct-2014 02:14	Per #1976, I agree strongly with Adrian: > seems that it is quite limited given that it has a very general sounding name Just looks like history, and apparently a history of sacred cows: > we would need to keep the immutable, immediate semantics. But that's not the way any other series-ish thing works. And most colors I see these days are in hex, they'd be issues if left alone. #FF8800 is way more common than 255.136.0 in representation of colors, and nowadays people want many more options like #F80 to mean #FF8800. If you use an ISSUE! you get the value semantics, although I think it's an example of a poor choice in dialect design to use a word for such an encoding. This needs more thought. I think the plan from the South Park underwear gnomes is relevant here... Step 1: immutable immediate value semantics for tuple! Step 2: ... Step 3: profit We've seen a retreat from the idea that FIRST and SECOND and THIRD should be applied to things like FUNCTION!. There was a movement to BODY-OF and SPEC-OF etc. with picking disallowed. I would personally like to see: >> first 21-Apr-1975 == 1975 ...changed into accessors more like: >> year-of 21-Apr-1975 == 1975 It simply doesn't make sense to be using numbers to get at that, especially when 1 is somehow getting the last display element... So when everything that actually has semantic series access actually acts like a series...with indexed positionality and passed about by reference, then you're talking about something sensible that fits in with the rest of the language. People who can't deal with mutability of series and position accesses are going to complain about STRING! long before complaining about TUPLE!. The basic idea of the underlying implementation of piggy-backing on STRING! was just to keep TUPLE! on life support with low implementation cost...reusing the codepoint based code and doing minimal churn. And perhaps switching into IPV6 notation as a default after a certain length. Though regarding IPv6...unfortunately if considering URIs: "The scheme name consists of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). Although schemes are case-insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. The scheme name is followed by a colon (":")." This means that with hexadecimal, an IPV6 address can be ambiguous with a so-called "opaque URI". BFD3:1020:1337:0421:1975:1337:0304:3DBF is both a valid URI and a valid IPV6 address. But I'll agree any challenges to the TUPLE! type are conflated with the matter raised in #1976. The thing I'd throw in is that I fundamentally disagree that the value semantics on this esoteric type are any kind of critical issue. Why exactly colors need immutable semantics but strings don't is beyond me.

Comments

(0004532)
BrianH
21-Oct-2014 18:41

Read through #1976 before you make any suggestions. Larger number spaces were part of that discussion, and proposed in a way that doesn't have the downsides of your proposal.

Btw, they're not characters, so not any-string!; they're not bytes, so not binary! (though all types are binary in one way or another underneath). You're thinking of vectors of integers as an underlying datatype. But we would need to keep the immutable, immediate semantics.

(0004535)
fork
31-Oct-2014 02:14

Per #1976, I agree strongly with Adrian:

> seems that it is quite limited given that it has a very general sounding name

Just looks like history, and apparently a history of sacred cows:

> we would need to keep the immutable, immediate semantics.

But that's not the way any other series-ish thing works. And most colors I see these days are in hex, they'd be issues if left alone. #FF8800 is way more common than 255.136.0 in representation of colors, and nowadays people want many more options like #F80 to mean #FF8800. If you use an ISSUE! you get the value semantics, although I think it's an example of a poor choice in dialect design to use a word for such an encoding. This needs more thought.

I think the plan from the South Park underwear gnomes is relevant here...

Step 1: immutable immediate value semantics for tuple!
Step 2: ...
Step 3: profit

We've seen a retreat from the idea that FIRST and SECOND and THIRD should be applied to things like FUNCTION!. There was a movement to BODY-OF and SPEC-OF etc. with picking disallowed. I would personally like to see:

>> first 21-Apr-1975
== 1975

...changed into accessors more like:

>> year-of 21-Apr-1975
== 1975

It simply doesn't make sense to be using numbers to get at that, especially when 1 is somehow getting the last display element...

So when everything that actually has semantic series access actually acts like a series...with indexed positionality and passed about by reference, then you're talking about something sensible that fits in with the rest of the language. People who can't deal with mutability of series and position accesses are going to complain about STRING! long before complaining about TUPLE!.

The basic idea of the underlying implementation of piggy-backing on STRING! was just to keep TUPLE! on life support with low implementation cost...reusing the codepoint based code and doing minimal churn. And perhaps switching into IPV6 notation as a default after a certain length.

Though regarding IPv6...unfortunately if considering URIs:

"The scheme name consists of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). Although schemes are case-insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. The scheme name is followed by a colon (":")."

This means that with hexadecimal, an IPV6 address can be ambiguous with a so-called "opaque URI". BFD3:1020:1337:0421:1975:1337:0304:3DBF is both a valid URI and a valid IPV6 address.

But I'll agree any challenges to the TUPLE! type are conflated with the matter raised in #1976. The thing I'd throw in is that I fundamentally disagree that the value semantics on this esoteric type are any kind of critical issue. Why exactly colors need immutable semantics but strings don't is beyond me.

Date	User	Field	Action	Change
31-Oct-2014 05:50	fork	Comment : 0004535	Modified	-
31-Oct-2014 02:15	fork	Comment : 0004535	Modified	-
31-Oct-2014 02:15	fork	Comment : 0004535	Modified	-
31-Oct-2014 02:14	fork	Comment : 0004535	Added	-
21-Oct-2014 18:43	BrianH	Comment : 0004532	Modified	-
21-Oct-2014 18:41	BrianH	Comment : 0004532	Added	-
3-Oct-2014 01:51	Fork	Summary	Modified	Make TUPLE! implementation run as ANY-STRING!, possibly interface too => Make TUPLE! implementation run as ANY-STRING! under the hood
3-Oct-2014 01:45	Fork	Description	Modified	-
3-Oct-2014 01:44	Fork	Description	Modified	-
3-Oct-2014 01:36	Fork	Description	Modified	-
3-Oct-2014 01:35	Fork	Ticket	Added	-