LiveCode Forums.

jacque wrote:I still don't see what's so hard to grasp about this concept:

A delimiter terminates the string it follows.

This is neither stupid nor dated, it's just how it has to work in this language. Any other implementation introduces problems that are harder to solve and which would require more workarounds.

I have always thought of the delimiter as a separation rather than a termination, however I see your point and it makes some things clearer. This does however raise a question for me. Why, when using "combine", doesn't the delimiter terminate the line?

I am confused about what you mean.

"a,b,c" and "a,b,," and "a,b,c," all have three items. The trailing comma in the second case delimits an empty string before it. The trailing comma in the third case delimits the "c" (it follows the "c").

Can you give an example of a string that:

...Item delimiters ... all delimit the strings they follow, UNLESS that string is the very last "item" before that item delimiter ... AND that item is empty,

Anyway, you must not read the string "a,b,c," as if that trailing comma implied that there must (ought to, has to) be something following it, even if only empty, but nonetheless SOMETHING. But it is not so. It is NOT that there is empty there, for that path is fraught with peril, but rather that the existing syntax simply rules. Jacque's definition is clear: don't look past a delimiter, ever, ever, especially if there is nothing there.

Craig

Mikey wrote:If it is not "dated", then why does every argument FOR this behavior start and end with "legacy code"?

...except for the opinion that matters most on this, that of LiveCode lead engineer Mark Waddingham.

Earlier I linked to his explanation of why he feels this the current implementation is a good one, and in it he never uses "legacy" at all, instead describing what he feels is the inherent merit of the implementation.

Here's the link again:
http://forums.livecode.com/viewtopic.ph ... =15#p82959

dave.kilroy wrote:Actually I'm hoping that they will at the very least tweak the SQLite db externals long before Open Language is completed!

FourthWorld wrote:and a rewrite of the DB externals is on the Road Map for after the Open Language projects is completed

See http://quality.runrev.com/show_bug.cgi?id=14295

Thanks again for filing that bug report.

Yes, while a complete rewrite of the DB externals is planned post-Open Language, that would have no bearing on more time-sensitive quick fixes to the current externals. I'd be surprised if the current RCs go final without that fix.

See the database example (or the dgtext example). The only defense you have is to take the output from a SELECT or dgText, and append a <tab> to the end of every line, because you must not...but LC does.

Right, I forgot about data coming from the database.

The solution there is to to use revQueryDatabase to create a cursor and get your data with revDatabaseColumnNamed or revDatabaseColumnNumbered. More code but not really difficult. I frequently use that in conjunction with a handler to create an array keyed by row number with subkeys of column name.

Doesn't solve the generic last item issue but gets around it for database access.

Pete

magice wrote: I have always thought of the delimiter as a separation rather than a termination, however I see your point and it makes some things clearer. This does however raise a question for me. Why, when using "combine", doesn't the delimiter terminate the line?

I don't know, but possibly to keep the list in more natural format. It allows the list to be placed in a field without trailing punctuation, which is what I think most people expect. Since working with the resulting list still produces an accurate item count, a missing trailing delimiter isn't an issue. The engine assumes one if it isn't already there.

I don't see any inconsistencies in the engine's approach if you think of delimiters as "belonging" to the item it follows. Mark Waddingham outlined only two rules that govern lists; the first is that trailing delimiters must be preserved. If the script doesn't do that, and there is data in the last item, the engine adds the delimiter internally. If the script produces an empty last item, then the script itself needs to preserve the trailing delimiter because otherwise the engine will assume the last delimiter exists already.

jacque wrote: I don't know, but possibly to keep the list in more natural format. It allows the list to be placed in a field without trailing punctuation, which is what I think most people expect. Since working with the resulting list still produces an accurate item count, a missing trailing delimiter isn't an issue. The engine assumes one if it isn't already there.

I don't see any inconsistencies in the engine's approach if you think of delimiters as "belonging" to the item it follows. Mark Waddingham outlined only two rules that govern lists; the first is that trailing delimiters must be preserved. If the script doesn't do that, and there is data in the last item, the engine adds the delimiter internally. If the script produces an empty last item, then the script itself needs to preserve the trailing delimiter because otherwise the engine will assume the last delimiter exists already.

Jacque, Thank you. I have spent the last hour putting together a long post about how this can be detrimental to data integrity, and writing code experiments to demonstrate. However in the end I only managed to prove to myself that, once again, you are correct. It really does not matter. The only thing I was able to break, was referencing a value as "the last item of x", which I now see as bad form. It seemed that a value was being lost, like a variable ceasing to exist when it is empty, or a box disappearing when it's contents are gone. I see now that it was just a matter of perception and that a variable does cease to exist when it is empty. It just seems to remain because referencing it in any way recreates it. I learn new things about LC and programming in general daily, but, as simple a concept as this is, it goes down as one of those "click" moments that make learning fun. Thank you again.

dave.kilroy wrote:Actually I'm hoping that they will at the very least tweak the SQLite db externals long before Open Language is completed!

FourthWorld wrote:and a rewrite of the DB externals is on the Road Map for after the Open Language projects is completed

See http://quality.runrev.com/show_bug.cgi?id=14295

Just a quick follow-up for Dave and any others who've been following this SQLite issue: if you check the bug report link above you'll see Hanson has now confirmed that the pull request for this fix has been submitted, so we can expect to see that fixed in the next build.

Thanks Richard - looking good that soon we'll have 64-bit builds for OS X that also work with SQLite

It seemed that a value was being lost, like a variable ceasing to exist when it is empty, or a box disappearing when it's contents are gone. I see now that it was just a matter of perception and that a variable does cease to exist when it is empty. It just seems to remain because referencing it in any way recreates it.

I'm probably misunderstanding, but variables can be empty and don't disappear just because they have no content, just as a field can still exist even when it has no text. The delimiter issue only applies to lists, not the variables that contain them. But maybe that's what you meant.

My mental model of how item counts work goes something like this:

Engine looks at the list to see if there is a delimiter at the end.
If no delimiter is at the end, it adds one internally.
Now the engine counts the delimiters, which is equal to the number of items.

An empty last item, being empty, doesn't have a value so the engine sees the last character in the list as the delimiter and skips the second step above.

jacque wrote: I'm probably misunderstanding, but variables can be empty and don't disappear just because they have no content, just as a field can still exist even when it has no text. The delimiter issue only applies to lists, not the variables that contain them. But maybe that's what you meant.

I guess in my excitement I didn't explain myself very well. I should not have said "variable" since an array is the actual variable and it does still exist I should have said "Array element". I was referring to the fact that an array that has a empty value in the last item, once combined looses it's final acknowledgement that an array element was there. (no trailing comma) This can be demonstrated by splitting that variable back into an array. Since there is no trailing comma, the final array element from the original array doesn't exist. But none of it matters because referencing it gives you the value "empty" which is what it should be anyway. It all comes down to a semi-ocd need to feel like the value holder of the empty value still in some way exists after splitting. The take away is that it just doesn't matter and that helps me get passed the OCD .

You're exactly right, I thought I'd probably misinterpreted what you meant. And being excited is very cool. Wear your geek badge with pride.

Separator...

Magice wrote:

I have always thought of the delimiter as a separation rather than a termination, ...

This is what Mikey "sees", that a trailing comma implies a further trailing item, albeit empty if it has no content. I "see" it that way as well, always did. But I have, since 1987, simply learned to accept strings as they are, rather than how I "see" them.

The word "separator" is the semantic root cause of this ongoing issue. There is nothing on the back side of a trailing delimiter (see my post about fifteen back), so that delimiters do not "separate" items, they terminate them.

Craig