is ASCII operator

[LCMark]

hmm... well in this case I branched of master... so do I branch off develop to create the docs or what?

Yes this is another (small) interim period where things are a little more fiddly than I'd like - sorry about that. We're about to freeze 6.1 for release (branching for regression fixes on a release-6.1 branch) so the 'is ascii' operator you've done will merge into the next release... Therefore, there's no harm in you merging develop into your branch as it stands now as that will be 'master' within a week or so (all being well).

Edit: I'll try and squeeze it into 6.1 if you don't mind getting a doc/release note added asap

[monte]

Hmm... there could still be some implementation issues... at the moment it's evaluating to false if it contains null... because that suited me but that's probably not correct for ASCII... The other thing is what should it return if the string is empty?

[LCMark]

Hmm... there could still be some implementation issues... at the moment it's evaluating to false if it contains null... because that suited me but that's probably not correct for ASCII... The other thing is what should it return if the string is empty?

Okay cool - let's take a little more time over it and not rush to put it in before all the i's have been dotted and t's crossed (i.e. aim for the next release after 6.1).

Technically, NUL is part of ASCII, so 'is an ascii string' should return true for a string containing it... I take it the JSON library you are using uses c-strings, but will appropriately escape all other control chars?

In terms of what is should return in terms of if the value is empty then the 'is a' operators are essentially 'try to convert to the given type, and if successful return true'. As empty converts to a string (the empty string), 'empty' is an ascii string too.

[monte]

BTW it doesn't make sense to me that is a and is not a is two separate documents... Is it possible to combine them and still have both of them in the index?

[monte]

OK, I can fix the null thing and it's already doing that for empty. Just doing docs now.

[DarScott]

Just because this operator is a good example of a small language addition...

It seems that a merge containing such a change should contain either the dictionary db, or information that would eventually flow naturally to the dictionary.

[LCMark]

OK, I can fix the null thing and it's already doing that for empty. Just doing docs now.

Should be there in 6.1-rc-1

It seems that a merge containing such a change should contain either the dictionary db, or information that would eventually flow naturally to the dictionary.

During the 6.1 dev cycle we integrated both the dictionary source files and a release notes system into the livecode repo. Thus we are starting to ask contributors to provide both release notes and changes/additions to the dictionary when they submit pull requests. Hopefully this will mean we won't 'lose' things, and everything will be documented over time

[DarScott]

I think an empty string is an ASCII string. An empty string might be any kind of string except something that can't be empty such as a string with a BOM prefix whatever that might be called.

That is, being an ASCII string means every character is an ASCII character, and "every" over an empty set is true.

[monte]

It seems that a merge containing such a change should contain either the dictionary db, or information that would eventually flow naturally to the dictionary.

It would have been good if I hadn't missed adding my untracked release note in my last commit then causing @runrevmark to need to write one... woops.