Re: [Ql-Users] bug in String handling
Well, whatever you guys choose to believe, please no one try to "fix" it as this behaviour appears to be consistent across the board - at least as far as JS, Minerva and SMSQ/E are concerned. If programmers keep their indices in order the issue should never arise anyway. Per On 13/01/2024 13:42, Wolfgang Lenerz via Ql-Users wrote: Norman Dunbar wrote: I still think that returning "" for a specific string slice from (a to a-1) is a bug! I tend to agree. x$ (a to b) where b is smaller than a should rise an error.The only way that would make any kind of sense to me would be if this returned the array contents in the reverse order. Now THAT would be a cool feature! Bite me!!! ;-) I'd rather not... Wolfgang ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] bug in String handling
I wonder if part of the reason that this arose is that some BASICs from that era just returned a null string "" if string slicing errors arose, without an error message and people remembered that? While that was probably convenient for the casual programmer, it must have made debugging difficult if one of your slice variables went out of range. >> Bite me!!! ;-) > > I'd rather not... The mind boggles, Wolfgang ... Dilwyn On Sat, 13 Jan 2024 at 12:42, Wolfgang Lenerz via Ql-Users wrote: > > Norman Dunbar wrote: > > > > I still think that returning "" for a specific string slice from (a to > > a-1) is a bug! > > > I tend to agree. x$ (a to b) where b is smaller than a should rise an > error.The only way that would make any kind of sense to me would be if > this returned the array contents in the reverse order. Now THAT would be > a cool feature! > > > Bite me!!! ;-) > > I'd rather not... > > Wolfgang > ___ > QL-Users Mailing List ___ QL-Users Mailing List
[Ql-Users] bug in String handling
Norman Dunbar wrote: I still think that returning "" for a specific string slice from (a to a-1) is a bug! I tend to agree. x$ (a to b) where b is smaller than a should rise an error.The only way that would make any kind of sense to me would be if this returned the array contents in the reverse order. Now THAT would be a cool feature! Bite me!!! ;-) I'd rather not... Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] bug in String handling
Morning Jan, That matches with Jan Jones. Arrays index from zero, but simple strings from 1. Cheers, Norm. -- Author of "Arduino Software Internals" and "Arduino Interrupts". ___ QL-Users Mailing List
Re: [Ql-Users] bug in String handling
Could the reference be the SBASIC/SuperBASIC reference manual? That says When a string array is set up with DIM, each entry is set to a nul string (“”). The zero’th element of each string array contains the actual length of that string, for example: DIM a$(10,10): a$(1)='Hello': PRINT a$(1,0) will return the value 5, as will PRINT LEN(a$(1)). If a$ is undimensioned and a$=’Hello World’, PRINT a$(0) does not generally work and will result in an ‘Out of Range’ error, except under SMS v2.60+ and Minerva where PRINT a$(0) is the same as PRINT LEN(a$). John On Fri, 12 Jan 2024 at 17:04, Jan Bredenbeek via Ql-Users < ql-users@lists.q-v-d.com> wrote: > On 12-01-2024 16:20, Norman Dunbar via Ql-Users wrote: > > > > > If I remember correctly, all the way back to 1984-85, I'm almost > > certain that the supplied QL manual, in the large, heavy, A$ folder, > > mentioned that string lengths are indeed stored in a$(0)---or at > > least, can be accessed from there. > > > > Cheers, > > Norm. > > > > Page 46 of the Concepts section mentions that 'under certain > circumstances' it is possible to refer to more than one element in an > array (i.e. slice the array), and that the term 'array' in this context > can include a numerical array, a string array or a simple string. It > also mentions that the slice (0 TO) means the full range of elements. > > Whilst it is indeed possible to slice an array (which includes element > 0), this is not true for simple strings. Using slice (0 TO) of a simple > string always produces an 'out of range' error. > Under Minerva and SMSQ/E, a$(0) indeed returns the length of a$. At > least version JS returns an error when trying to access element 0 of a > simple string. > > -- > Jan Bredenbeek | Hilversum, NL | j...@bredenbeek.net > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] bug in String handling
On 12-01-2024 16:20, Norman Dunbar via Ql-Users wrote: If I remember correctly, all the way back to 1984-85, I'm almost certain that the supplied QL manual, in the large, heavy, A$ folder, mentioned that string lengths are indeed stored in a$(0)---or at least, can be accessed from there. Cheers, Norm. Page 46 of the Concepts section mentions that 'under certain circumstances' it is possible to refer to more than one element in an array (i.e. slice the array), and that the term 'array' in this context can include a numerical array, a string array or a simple string. It also mentions that the slice (0 TO) means the full range of elements. Whilst it is indeed possible to slice an array (which includes element 0), this is not true for simple strings. Using slice (0 TO) of a simple string always produces an 'out of range' error. Under Minerva and SMSQ/E, a$(0) indeed returns the length of a$. At least version JS returns an error when trying to access element 0 of a simple string. -- Jan Bredenbeek | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] bug in String handling
On 08/01/2024 18:46, pjw via Ql-Users wrote: > 100 a$ = "1234567890" > 105 b$ = a$(4 to 3): REMark This works > 110 REMark c$ = a$(4 to 2): REMark This fails with an error. > 115 c$ = a$( to 0) : REMark no error returned > 120 c$ = a$(0):: REMark no error returned BUT ERROR IF QLIBERATED > 125 pause:stop Line 105: The construct a$(n to n - 1) represents the empty string (even when n = 1). Since it is replicated in JS, Minerva and SMSQ/E Im assuming it is by design. If it's by design, it it actually documented anywhere? I do not recall it being in the QL Manual, as supplied with new QLs back in the day, and I don't recall Jan Jones mentioning it either. My QL Manual is packed away ready for a house move---which fell through---Just checked with Jan Jones (the QUANTA version), she doesn't mention how this works (or doesn't!) It also makes sense as there would be no other way to represent a string slice of null. I'm wondering though, why you would need to get a "string slice of null"? If I want to obtain a an empty string, just assigne on A$="" for example. To get a slice that is null, I need to determine that this is exactly what I need, and then make sure that my slicing parameters are specified with the end being exactly one less than the start? Too much faffing around, just assign an empty string (as above!) Line 115: I guess a$( to 0) is read as a$(1 to 0) which fits the criteria above. I agree with your observation. Jan Jones states that when slicing a string variable, the zeroth elephant cannot be accessed. (Page 28.) Line 120: a$(0) should be fine also. It represents the string length. Assignment to this location is also acceptable: Jan Jones documents this in her QL SuperBASIC Handbook, page 23. I still think that returning "" for a specific string slice from (a to a-1) is a bug! Bite me!!! ;-) Cheers, Norm. -- Norman Dunbar. ___ QL-Users Mailing List
Re: [Ql-Users] bug in String handling
On 08/01/2024 16:51, Wolfgang Lenerz via Ql-Users wrote: Line 120 is due to the fast that strings are not 0 based index. So what would a$(0) be? Under SMSQ/E at least, print a$(0) in the above example would give "10" - which is the length of the string... Since this seems to be an unorthodox behaviour, it's no wonder Qlib balks at it. If I remember correctly, all the way back to 1984-85, I'm almost certain that the supplied QL manual, in the large, heavy, A$ folder, mentioned that string lengths are indeed stored in a$(0)---or at least, can be accessed from there. Cheers, Norm. -- Norman Dunbar. ___ QL-Users Mailing List
Re: [Ql-Users] bug in String handling
Line 105: The construct a$(n to n - 1) represents the empty string (even when n = 1). Since it is replicated in JS, Minerva and SMSQ/E Im assuming it is by design. It also makes sense as there would be no other way to represent a string slice of null. Line 115: I guess a$( to 0) is read as a$(1 to 0) which fits the criteria above. Line 120: a$(0) should be fine also. It represents the string length. Assignment to this location is also acceptable: DIM a$(10): remark Define/Make space a$(0) = 10: remark Set size BGET#channel; a$(to 10): remark Get 10 bytes from channel This works with JS and Minerva (both with TK2 V3.32+), and SMSQ/E Line 110: This is clearly an error and is treated as such. Per On 08/01/2024 17:51, Wolfgang Lenerz via Ql-Users wrote: Hi, Line 120 is due to the fast that strings are not 0 based index. So what would a$(0) be? Under SMSQ/E at least, print a$(0) in the above example would give "10" - which is the length of the string... Since this seems to be an unorthodox behaviour, it's no wonder Qlib balks at it. Line 105 makes no sense to me, just what should one expect from that? (maybe the reversed string (2 to 4)???), this should probably raise an error, just like line 110 does. line 115 results in an empty strin,g - there is nothing before 0, so nothing can be obtained. Again, this should probably raise an error. Have fun WOlfgang Hi, Some other anomalies 100 a$ = "1234567890" 105 b$ = a$(4 to 3): REMark This works 110 REMark c$ = a$(4 to 2): REMark This fails with an error. 115 c$ = a$( to 0) : REMark no error returned 120 c$ = a$(0): : REMark no error returned BUT ERROR IF QLIBERATED 125 pause:stop The problem of slicing strings was already discused here many years ago. I think it was Marcel Kilgus who gave us some explanation. François Van Emelen ___ QL-Users Mailing List ___ QL-Users Mailing List ___ QL-Users Mailing List
[Ql-Users] bug in String handling
Hi, Line 120 is due to the fast that strings are not 0 based index. So what would a$(0) be? Under SMSQ/E at least, print a$(0) in the above example would give "10" - which is the length of the string... Since this seems to be an unorthodox behaviour, it's no wonder Qlib balks at it. Line 105 makes no sense to me, just what should one expect from that? (maybe the reversed string (2 to 4)???), this should probably raise an error, just like line 110 does. line 115 results in an empty strin,g - there is nothing before 0, so nothing can be obtained. Again, this should probably raise an error. Have fun WOlfgang Hi, Some other anomalies 100 a$ = "1234567890" 105 b$ = a$(4 to 3): REMark This works 110 REMark c$ = a$(4 to 2): REMark This fails with an error. 115 c$ = a$( to 0) : REMark no error returned 120 c$ = a$(0): : REMark no error returned BUT ERROR IF QLIBERATED 125 pause:stop The problem of slicing strings was already discused here many years ago. I think it was Marcel Kilgus who gave us some explanation. François Van Emelen ___ QL-Users Mailing List ___ QL-Users Mailing List
[Ql-Users] bug in String handling
Hi, Some other anomalies 100 a$ = "1234567890" 105 b$ = a$(4 to 3): REMark This works 110 REMark c$ = a$(4 to 2): REMark This fails with an error. 115 c$ = a$( to 0) : REMark no error returned 120 c$ = a$(0): : REMark no error returned BUT ERROR IF QLIBERATED 125 pause:stop The problem of slicing strings was already discused here many years ago. I think it was Marcel Kilgus who gave us some explanation. François Van Emelen ___ QL-Users Mailing List
