Redefine keyword item (word, line, ...)

[FourthWorld]

As with 'word" and "trueWord", each of which is useful for different tasks, maybe all we need here is a new token type for the proposed new behavior.

[Mikey]

which would also be fine, but that was also shot down by Mark, previously.

[jacque]

@jacque and Craig:

I would prefer to discuss here about facts, not about esoterica:

I wouldn't call it esoterica. Mark Waddingham's list of issues are things that need to be addressed and resolved if the current behavior is changed in the engine. He sees no way to do that until lists are no longer stored as strings internally.

And all developers have to work around it. Funny game.

No, some of us rely on the current behavior and have been using it to good advantage for 27 years. There are instances where the current behavior makes scripting shorter and easier. It all depends on how you interpret the function of the delimiter character.

[dunbarx]

All.

I think the current thread is about perfecting, as opposed to curing, a, what, peculiarity in the language? As Jacque says, there has been almost three decades of work that has gone before, pretty well, thank you very much, with just a little accommodation, acceptance and, what, forgiveness?

The current implementation is not broken, it is just a bit counterintuitive. Is that the right word?

Perhaps, as Richard suggested, and an earlier thread requested, (see "multiple itemDelimiters" in this forum) a new token might both resolve this issue and at the same time add fabulous new functionality.

What do you think, RunRev? I am far more interested in that than "fixing" the current schema.

Craig

[[-hh]]

What I don't understand in the current discussion is the insisting on an exclusive usage of old patchwork structures.

To introduce new features doesn't involve to give up old ones or to disregard work done in the last 20, 30, 40 years (although the portion of nonsense in that will not be smaller than in today's work). Learning a new name is everything required, no difficulty involved.

It all depends on how you interpret the function of the delimiter character.

Thanks, now I got it. We simply have to ask the comma what's its current role.

I came upon a comma,
was delimiting a chunk.
I accused it there
with its tortured chunk.
It said "Listen to me,
listen to me child,
I am what I am, and this,
this is my only chunk."

[jacque]

Thanks, now I got it. We simply have to ask the comma what's its current role.

Or revise your understanding of delimiters as used in LC.

Here is an example of the "esoterica" that must be resolved if the behavior is changed. A stack creates many buttons dynamically, of different colors. I need to find out how many are red and how many are blue, and keep their names in separate lists for use elsewhere:

Code: Select all

on mouseUp
  repeat with x = 1 to the number of btns
    if the backcolor of btn x = "red" then
      put the short name of btn x & comma after tRedList
    else if the backcolor of btn x = "blue" then
      put the short name of btn x & comma after tBlueList
    end if
  end repeat
  put the number of items in tRedList into tRedCount
  put the number of items in tBlueList into tBlueCount
  put the number of items in tRedList & tBlueList into tTotalCount
end mouseUp

If we decide that trailing delimiters indicate an empty item, how many blue buttons will LC report? How many red? How many total?

If the understanding of a delimiter is simply that it is the last character of a substring, the math works.

[[-hh]]

LC will report with the new definition the exact number of items of each of the lists including the empty ones. That is the math that will work reliably.

What you now call "understanding of a delimiter" is the logical fault the scripter makes by thinking each button would correspond to an item.

If you currently decide that delimiters indicate objects then you have to count the number of delimiters, not the number of chunks that relate in an inconsistent way to these delimiters.

[dunbarx]

Another, similar to Jacque's example. The process of generating these sorts of strings is mentally straightforward and a standard and time-worn process.

There are innumerable cases, I am sure familiar to all programmers from 1987 on, where trailing returns especially, but also commas, spaces and other chars, might or might not need to be stripped before other code acts upon certain data.

Code: Select all

on mouseUp
   repeat 3
      put "XX" & return after fld 1
   end repeat
   
   --delete last char of fld 1
end mouseUp

The number of lines is three, whether or not the commented line is included. So, deleting the trailing return (or comma or whatever) does not change the number of chunks, BUT IT SURE DOES change the way the example below works:

Code: Select all

put "YY" after  fld 1

You get quite different results. And the place where that added string ought to end up could go either way. The author decides that. In one sense, it might be argued that the trailing return is "set up" to allow newly appended data to follow its existing "format". This begs the technical issues that Hermann as so formally and cogently set forth, but is nonetheless an example of how things have always been done. Legacy code is filled with instances of this sort of thing, certainly mine is.

It will require, therefore, as Richard mentioned, a new token in order to "fix" this. As Hermann states, now is a perfect time. This discussion should shift to exhorting RunRev to implement that, and I say again the place to start is the "Multiple ItemDelimiters" thread. Mark Waddingham has commented favorably on that thread, and pressure should be brought to bear. We would kill two birds with one stone. Though why anyone would kill a bird with a 14 pound rock is beyond me.

Craig

[Mikey]

Don't forget that while "a" and "a," are somehow equivalent, they are not equivalent to "a,,".

I've been using these tools forever, too, and I also have legacy code that is closing on 30 years old, but I am not going to let tradition stand in the way of fixing this (or any other) goofy behavior. Every time we have an opportunity, we should be trying to reinvent this environment and this language, deprecating and pruning, and making and keeping it state-of-the-art.

[[-hh]]

Start dreaming now ...

Call the chunk objects TERM, pl. TERMS.
Each defining delimiter is a TERMINATOR (no joke, you'll love that).

We will often use directly:
The number of terminators (as jacque used above in her last script).
This number is 0-based (starting with 0=the number of terminators of empty).

The number of terms = 1 + the number of terminators.
This number is 1-based; 1=the number of terms of any string (incl. empty) that doesn't contain the terminator.

Craig's "multiple-items" fit in this concept. Presumably also "trueWords", Richard?

And starting with 8.1 we will also have "leftTerminator" and rightTerminator",
for example parentheses ( ), brackets[ ], braces { }.

Set terminator to "RunRev".

p.s.
Empty is among the terms of empty (no matter who's terminator). And:
A string S is empty if and only if (empty is term 1 of S and the number of terms of S is 1).
[More in words: "A string S is empty if and only if empty is the one and only term of S."]

[dunbarx]

Hermann.

I would rather have the new operator suggested by Phaworth, "delimited by", and make that conform to the new thinking. In that way, we may not need a new token at all:

Code: Select all

answer the number of items of "a,b,c," delimited by comma --yields  4
answer the number of items of "a,b,c," -- yields 3
answer the number of items of "a,b,c" -- yields 3

Works with all chunks. Now the user can maintain legacy code intact, and he or she can rewrite/create new code as desired with the new gizmo. It may be that the inclusion of this will not be backward compatible, so the "rewrite" part may be moot. Nonetheless...

RunRev???

Craig

[[-hh]]

[An "item delimited by comma" is not yet defined? Is empty among the items of empty delimited by comma? The number of items of empty delimited by comma? Check Ali's collection of inconsistencies with "delimited by", this bears still the burden of "item"!]

But, as I said,
the "multiple-delimiter/delimited-by"-concept fits perfectly in the new concept. It is a clever idea, a comfortable way to set the terminator "on the fly", for that single expression only (so that even different terminators can be used in combining/concatenating such expressions).

Code: Select all

the number of terms of "a,b,c," (delimited by comma) -- 4
the number of terminators of "a,b,c," (delimited by comma) -- 3
the number of terms of "" (delimited by comma) -- 1, this  term is empty
the number of terminators of "" (delimited by comma) -- 0
empty is among the terms of "" (delimited by comma) -- true
(term 3 of "C8,...b +C7,L" delimited by comma ) & \
(term 2 of "C8,...b +C7,L" delimited by (space & "+") ) & \
(term 1 of "C8,...b +C7,L" delimited by "b" ) -- "LC7,LC8,..." 

The old item-patchwork can still be there, whoever will use it:
the number of items of "a,b,c," -- 3
the number of items of "a,b,c" -- 3

And each one of Ali's problems is solvable by using either (number of) terms or (number of) terminators. Try, it's possible.

Alice laughed. "There's no use trying," she said. "One can't believe impossible things."
"I dare say you haven't had much practice," said the queen.

[[-hh]]

If 'dunbarx' and 'phaworth' don't mind if changing the naming "delimited" this could also read as follows.

Code: Select all

the number of terms of "a,b,c," terminated by comma -- 4
the number of terminators of "a,b,c," terminated by comma -- 3

There could be also a terminatorSet (as currently with word) where one ore more occurences in row of such terminator elements do terminate once. Of course the "superTerminators", beginOfString and endOfString, are always members of such sets.

Starting from LC 7, trueWords are already terms that use such a terminatorSet.

[dunbarx]

All good stuff, and I see this enhancement as fundamental and profound, similar to the effect of allowing other chars than comma to be delimiters. And remember that in LC 7, if I am correct, the delimiter can now be any string, not just a single character.

Should several people here send a "petition" to RunRev? I know they are busy, but I think they already see the potential, maybe just needing a reminder, to include it in their short list of things to do.

Craig

[[-hh]]

There are more important things to do. I take this back.