Nickolay Kolchin <nbkolchin@gmail.com> writes:
>- lxf and gforth accept the source but silently truncate length. They shoul=
>d throw=20
>exception if line is too big for `C"`.

Somehow I doubt that anybody has used longer C" strings in production
code, but anyway, fixed in Gforth in

http://git.savannah.gnu.org/cgit/gforth.git/commit/?id=ad3e1bc66df8fc68eb2a4878981e5123afd7f0cf

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Nickolay Kolchin <nbkolchin@gmail.com> writes:
>Actually F79 used correct naming "packed" and F83 started using
>misleading term "counted".

Forth-79 uses "packed string" only in WORD. COUNT does not mention
either "counted string" or "packed string", but the "character count".

>IMHO, 255 bytes limitation is "blast from past" and should be lifted
>nowadays...

From <https://forth-standard.org/standard/rationale#rat:cstring>:
|Forth 94 moved toward the consistent use of the "c-addr u"
|representation of strings on the stack. The use of the alternate
|"address of counted string" stack representation is discouraged.

There is no 255-byte limitation for c-addr u strings.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Ruvim <ruvim.pinka@gmail.com> writes:
>> IMHO, 255 bytes limitation is "blast from past" and should be lifted
>> nowadays...
>
>Forth-94 doesn't limit it by 255 bytes, it requires that this limit
>shall be *not less* than 255 bytes (i.e., the character size cannot be
>less than 8 bits).

No such limit for standard systems. But standard programs have to
obey the 255 char limit if they use counted strings.

And yes, counted strings are a blast from the past (and calling them
"packed strings" is a blast from an even earlier past).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Sunday, November 7, 2021 at 6:39:34 PM UTC+3, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
> >> IMHO, 255 bytes limitation is "blast from past" and should be lifted
> >> nowadays...
> >
> >Forth-94 doesn't limit it by 255 bytes, it requires that this limit
> >shall be *not less* than 255 bytes (i.e., the character size cannot be
> >less than 8 bits).
> No such limit for standard systems. But standard programs have to
> obey the 255 char limit if they use counted strings.
>

So, this is not portable after all?

here 2 c, 13 c, 10 c, count 2constant aaa
> And yes, counted strings are a blast from the past (and calling them
> "packed strings" is a blast from an even earlier past).

Yeh, I'm ancient.

Nickolay Kolchin <nbkolchin@gmail.com> writes:
>So, this is not portable after all?
>
>here 2 c, 13 c, 10 c, count 2constant aaa

Why would you think so? AFAICS, this is standard code and portable to
standard systems. As someone else has pointed out, it's needlessly
complex and can be replaced with

here 2 13 c, 10 c, 2constant aaa

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Sunday, November 7, 2021 at 9:38:02 PM UTC+3, Anton Ertl wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> >So, this is not portable after all?
> >
> >here 2 c, 13 c, 10 c, count 2constant aaa
> Why would you think so? AFAICS, this is standard code and portable to
> standard systems. As someone else has pointed out, it's needlessly
> complex and can be replaced with
>
> here 2 13 c, 10 c, 2constant aaa

So `COUNT` can handle 255 chars max?

On 2021-11-07 18:24, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>>> IMHO, 255 bytes limitation is "blast from past" and should be lifted
>>> nowadays...
>>
>> Forth-94 doesn't limit it by 255 bytes, it requires that this limit
>> shall be *not less* than 255 bytes (i.e., the character size cannot be
>> less than 8 bits).
>
> No such limit for standard systems.

The standard establishes a requirement for minimum characters size.

3.1.2
| Characters shall [...] contain at least eight bits

3.1.3.4
| The maximum length of a counted string shall be at least 255.

They are requirements for the standard systems.

> But standard programs have to
> obey the 255 char limit if they use counted strings.

Yes. It's a consequence.

--
Ruvim

On 2021-11-07 21:44, Nickolay Kolchin wrote:
> On Sunday, November 7, 2021 at 9:38:02 PM UTC+3, Anton Ertl wrote:
>> Nickolay Kolchin <nbko...@gmail.com> writes:
>>> So, this is not portable after all?
>>>
>>> here 2 c, 13 c, 10 c, count 2constant aaa
>> Why would you think so? AFAICS, this is standard code and portable to
>> standard systems. As someone else has pointed out, it's needlessly
>> complex and can be replaced with
>>
>> here 2 13 c, 10 c, 2constant aaa
>
> So `COUNT` can handle 255 chars max?
>

COUNT always handles the same that C@ handles, i.e., a character.

Its max value isn't always 255. For example, in some plausible system it
can be 2^32-1.

In a standard system the character size shall be at least 8 bits (see
3.1.2 Character types).

Hence, a standard program can only rely on 8 bit characters, regardless
what their actual limit (that can be greater).

A standard program with environmental dependencies may require other
minimal character size (to handle counted strings having length greater
than 255). Although, it's more portable for such a program to use just
own implementation for "packed strings" (or alike).

--
Ruvim

On 8/11/2021 00:08, Marcel Hendrix wrote:
> On Sunday, November 7, 2021 at 5:00:11 AM UTC+1, dxforth wrote:
> [..]
>> Humans still only have two eyes and limited visual comprehension.
>> The less information presented them at once, the better. A computer
>> needs to read text only to the extent humans need to read it. When
>> a 255 char quoted string is already beyond human comprehension,
>> suggesting a computer could handle more becomes rather academic.
>
> More (than 255 chars) is needed when cutting and pasting between
> programs.

My screen editor does that. What has it to do with quoted strings?

On 8/11/2021 08:35, Ruvim wrote:
> On 2021-11-07 21:44, Nickolay Kolchin wrote:
>> On Sunday, November 7, 2021 at 9:38:02 PM UTC+3, Anton Ertl wrote:
>>> Nickolay Kolchin <nbko...@gmail.com> writes:
>>>> So, this is not portable after all?
>>>>
>>>> here 2 c, 13 c, 10 c, count 2constant aaa
>>> Why would you think so? AFAICS, this is standard code and portable to
>>> standard systems. As someone else has pointed out, it's needlessly
>>> complex and can be replaced with
>>>
>>> here 2 13 c, 10 c, 2constant aaa
>>
>> So `COUNT` can handle 255 chars max?
>>
>
> COUNT always handles the same that C@ handles, i.e., a character.
>
> Its max value isn't always 255. For example, in some plausible system it
> can be 2^32-1.

But not particularly useful. Same with quotes about ANS' 'addr len'
strings which ignores the whole issue of string variables. What's
significant IMO is that counted strings as an encoding method has
remained the de-facto standard for Forth and still popularly used
despite all the whinging about a "255 char limit". Perhaps Moore
wasn't quite the fool today's forthers would have him be :)

On 8/11/2021 05:31, Anton Ertl wrote:
> Nickolay Kolchin <nbkolchin@gmail.com> writes:
>>So, this is not portable after all?
>>
>>here 2 c, 13 c, 10 c, count 2constant aaa
>
> Why would you think so? AFAICS, this is standard code and portable to
> standard systems. As someone else has pointed out, it's needlessly
> complex and can be replaced with
>
> here 2 13 c, 10 c, 2constant aaa

My preference would have been:

' count build aaa 2 c, 13 c, 10 c,

as it's shorter for DTC. For lengthy data where counting is more
trouble than worth, I've grown fond of:

here

comma'd data

here over - ( 1 cells / ) 2constant bbb

Each case on its merits.

dxforth <dxforth@gmail.com> writes:
>What's
>significant IMO is that counted strings as an encoding method has
>remained the de-facto standard for Forth

Reality check: Uses of:

gforth SwiftForth
C" 0 26
S" 334 151
S\" 9 1

Measured with, e.g.:

gforth -e 'where s\" bye'|wc -l
sf 'where s\" bye'|grep "|"|wc -l

The output of the line for SwiftForth includes the definition, so I
subtracted 1.

Forth Gforth it's the current development version, for SwiftForth it's
3.11.0.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 2021-11-08 02:55, dxforth wrote:
> On 8/11/2021 08:35, Ruvim wrote:
>> On 2021-11-07 21:44, Nickolay Kolchin wrote:

>>> So `COUNT` can handle 255 chars max?
>>>
>>
>> COUNT always handles the same that C@ handles, i.e., a character.
>>
>> Its max value isn't always 255. For example, in some plausible system it
>> can be 2^32-1.
>
> But not particularly useful.

If you mean to reserve space for max length of counted strings — of
course, it would be inefficient.

> Same with quotes about ANS' 'addr len'
> strings which ignores the whole issue of string variables.

The problem of string variables is connected with the problem of memory
management.

> What's
> significant IMO is that counted strings as an encoding method has
> remained the de-facto standard for Forth and still popularly used
> despite all the whinging about a "255 char limit".

Yes, they are usually used internally by Forth systems, for example to
store name of definitions. Or for internal representations of constant
strings.

But they are rare in programs. By statistics in the SP-Forth repository,
'S"' is used 4855 times, 'C"' is used 95 times, that is 50 times rarer.

Actually, you can use counted strings until you face silent truncation
of a long string to 255 characters in a production. After that you
rewrite all code fragments that use counted strings and forget them for
ever.

--
Ruvim

On 8/11/2021 19:01, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>What's
>>significant IMO is that counted strings as an encoding method has
>>remained the de-facto standard for Forth
>
> Reality check: Uses of:
>
> gforth SwiftForth
> C" 0 26
> S" 334 151
> S\" 9 1
>

SwiftForth is whom I had in mind. It encodes all its quoted string constants
as counted strings (including Z"). Its APPEND (string concatenate) assumes a
counted string destination; used 41 times. So too its circular buffer >QPAD.

On 8/11/2021 20:11, Ruvim wrote:
> On 2021-11-08 02:55, dxforth wrote:
>
>> What's
>> significant IMO is that counted strings as an encoding method has
>> remained the de-facto standard for Forth and still popularly used
>> despite all the whinging about a "255 char limit".
>
> Yes, they are usually used internally by Forth systems, for example to
> store name of definitions. Or for internal representations of constant
> strings.
>
> But they are rare in programs. By statistics in the SP-Forth repository,
> 'S"' is used 4855 times, 'C"' is used 95 times, that is 50 times rarer.

Use of S" tells one nothing. The better question is how many times
S" has been used to hold strings greater than 255 characters. In the
case of SwiftForth (and presumably its users) the answer would appear
to be zero.

On 2021-11-08 13:34, dxforth wrote:
> On 8/11/2021 20:11, Ruvim wrote:
>> On 2021-11-08 02:55, dxforth wrote:
>>
>>> What's
>>> significant IMO is that counted strings as an encoding method has
>>> remained the de-facto standard for Forth and still popularly used
>>> despite all the whinging about a "255 char limit".
>>
>> Yes, they are usually used internally by Forth systems, for example to
>> store name of definitions. Or for internal representations of constant
>> strings.
>>
>> But they are rare in programs. By statistics in the SP-Forth repository,
>> 'S"' is used 4855 times, 'C"' is used 95 times, that is 50 times rarer.

Just for reference, the commands for gather these statistics are:

ag -c ' S" ' | cut -d ':' -f2 | dc -e '0 0 [+?z1<m]dsmxp'
ag -c ' C" ' | cut -d ':' -f2 | dc -e '0 0 [+?z1<m]dsmxp'

(add '-i' option to 'ag' or use lower case to match case-insensitively)

>
> Use of S" tells one nothing.  The better question is how many times
> S" has been used to hold strings greater than 255 characters.

This question doesn't make any sense. In standard programs 'S"' cannot
be used for string literals having more than ~ 120 characters, due to
limitation of a line length in source files. And it's quite rare when
you need so long string literal.

Also, replacing
S" X"
by
C" X" COUNT
doesn't make any sense.

'S"' is used instead of 'C"' not due to an internal representation, but
since many other words consume character strings represented by (c-addr
u). In their turn, they consume (c-addr u) to don't limit the string
length by 255 characters.

--
Ruvim

On 8/11/2021 22:31, Ruvim wrote:
> On 2021-11-08 13:34, dxforth wrote:
>>
>> Use of S" tells one nothing.  The better question is how many times
>> S" has been used to hold strings greater than 255 characters.
>
> This question doesn't make any sense. In standard programs 'S"' cannot
> be used for string literals having more than ~ 120 characters, due to
> limitation of a line length in source files.

Use of S" isn't restricted to standard programs. The question stands.

> 'S"' is used instead of 'C"' not due to an internal representation, but
> since many other words consume character strings represented by (c-addr
> u). In their turn, they consume (c-addr u) to don't limit the string
> length by 255 characters.

That's not the reason ANS gave (A.6.1.2165). However there definitely
exists a prejudice against the '255 char limit'. Does your S" have
such a limit?

On 9/11/2021 00:14, dxforth wrote:
> On 8/11/2021 22:31, Ruvim wrote:
>> On 2021-11-08 13:34, dxforth wrote:
>>>
>>> Use of S" tells one nothing.  The better question is how many times
>>> S" has been used to hold strings greater than 255 characters.
>>
>> This question doesn't make any sense. In standard programs 'S"' cannot
>> be used for string literals having more than ~ 120 characters, due to
>> limitation of a line length in source files.
>
> Use of S" isn't restricted to standard programs. The question stands.

This test should work on any system:

here 500 dup allot 2constant foo : bar [ foo ] sliteral nip . ; bar

If the result is something other than 500 then it's likely the system
uses counted strings for storage, irrespective of external representation.
Mine returned 255 as expected.

On 08/11/2021 16:17, dxforth wrote:
> On 9/11/2021 00:14, dxforth wrote:
>> On 8/11/2021 22:31, Ruvim wrote:
>>> On 2021-11-08 13:34, dxforth wrote:
>>>>
>>>> Use of S" tells one nothing.  The better question is how many times
>>>> S" has been used to hold strings greater than 255 characters.
>>>
>>> This question doesn't make any sense. In standard programs 'S"' cannot
>>> be used for string literals having more than ~ 120 characters, due to
>>> limitation of a line length in source files.
>>
>> Use of S" isn't restricted to standard programs.  The question stands.
>
> This test should work on any system:
>
>  here 500 dup allot 2constant foo : bar [ foo ] sliteral nip . ; bar
>
> If the result is something other than 500 then it's likely the system
> uses counted strings for storage, irrespective of external representation.
> Mine returned 255 as expected.

That's interesting. Given the following code (there's probably a simpler
way to demonstrate the issue but this suffices)

: a 128 32 do i c, loop ;
: b 3 0 do a loop ;
0. 2value c
here 128 32 - 3 * to c
b : d [ c ] sliteral cr type ;

If the following two lines in a Forth system don't display the same long
string that system is not compliant with ANS/Forth2012.

c cr type
d

Gforth, my system and Alex McDonald's wf32 all worked correctly.
VFX Forth hung when executing d
SwiftForth fails to compile d

Of course in practice this is unlikely to cause a problem.

--
Gerry

On Monday, November 8, 2021 at 6:39:54 PM UTC+1, Gerry Jackson wrote:
> On 08/11/2021 16:17, dxforth wrote:
> > On 9/11/2021 00:14, dxforth wrote:
> >> On 8/11/2021 22:31, Ruvim wrote:
> >>> On 2021-11-08 13:34, dxforth wrote:
> >>>>
[..]
> That's interesting. Given the following code (there's probably a simpler
> way to demonstrate the issue but this suffices)
>
> : a 128 32 do i c, loop ;
> : b 3 0 do a loop ;
> 0. 2value c
> here 128 32 - 3 * to c
> b
> : d [ c ] sliteral cr type ;
>
> If the following two lines in a Forth system don't display the same long
> string that system is not compliant with ANS/Forth2012.
>
> c cr type
> d

FORTH> : a 128 32 do i c, loop ; ok
FORTH> : b 3 0 do a loop ; ok
FORTH> 0. dvalue c ok
FORTH> here 128 32 - 3 * to c ok
FORTH> b ok
FORTH> : d [ c ] sliteral cr type ;
Error -64
quoted string should be less than 256 characters ?
FORTH> c .s
Data: 20176896 288 ---
System: ---
Float: --- ok

A bug. Thanks.

-marcel

On 9/11/2021 04:39, Gerry Jackson wrote:
> On 08/11/2021 16:17, dxforth wrote:
>> On 9/11/2021 00:14, dxforth wrote:
>>> On 8/11/2021 22:31, Ruvim wrote:
>>>> On 2021-11-08 13:34, dxforth wrote:
>>>>>
>>>>> Use of S" tells one nothing.  The better question is how many times
>>>>> S" has been used to hold strings greater than 255 characters.
>>>>
>>>> This question doesn't make any sense. In standard programs 'S"' cannot
>>>> be used for string literals having more than ~ 120 characters, due to
>>>> limitation of a line length in source files.
>>>
>>> Use of S" isn't restricted to standard programs.  The question stands.
>>
>> This test should work on any system:
>>
>>  here 500 dup allot 2constant foo : bar [ foo ] sliteral nip . ; bar
>>
>> If the result is something other than 500 then it's likely the system
>> uses counted strings for storage, irrespective of external representation.
>> Mine returned 255 as expected.
>
> That's interesting. Given the following code (there's probably a simpler
> way to demonstrate the issue but this suffices)
>
> : a 128 32 do i c, loop ;
> : b 3 0 do a loop ;
> 0. 2value c
> here 128 32 - 3 * to c
> b
> : d [ c ] sliteral cr type ;
>
> If the following two lines in a Forth system don't display the same long
> string that system is not compliant with ANS/Forth2012.
>
> c cr type
> d

I'd be surprised if SLITERAL didn't factor in counted strings that's how
many/most forth systems worked internally at the time and still do.

>
> Gforth, my system and Alex McDonald's wf32 all worked correctly.
> VFX Forth hung when executing d
> SwiftForth fails to compile d

Why SLITERAL should include a 255 UMIN or THROW if it's going to store
as a counted string.

>
> Of course in practice this is unlikely to cause a problem.
>

Just unanticipated. Folks forgive their own stupidity but not that of
others :)

On 9/11/2021 09:30, Marcel Hendrix wrote:
> On Monday, November 8, 2021 at 6:39:54 PM UTC+1, Gerry Jackson wrote:
>> On 08/11/2021 16:17, dxforth wrote:
>> > On 9/11/2021 00:14, dxforth wrote:
>> >> On 8/11/2021 22:31, Ruvim wrote:
>> >>> On 2021-11-08 13:34, dxforth wrote:
>> >>>>
> [..]
>> That's interesting. Given the following code (there's probably a simpler
>> way to demonstrate the issue but this suffices)
>>
>> : a 128 32 do i c, loop ;
>> : b 3 0 do a loop ;
>> 0. 2value c
>> here 128 32 - 3 * to c
>> b
>> : d [ c ] sliteral cr type ;
>>
>> If the following two lines in a Forth system don't display the same long
>> string that system is not compliant with ANS/Forth2012.
>>
>> c cr type
>> d
>
> FORTH> : a 128 32 do i c, loop ; ok
> FORTH> : b 3 0 do a loop ; ok
> FORTH> 0. dvalue c ok
> FORTH> here 128 32 - 3 * to c ok
> FORTH> b ok
> FORTH> : d [ c ] sliteral cr type ;
> Error -64
> quoted string should be less than 256 characters ?
> FORTH> c .s
> Data: 20176896 288 ---
> System: ---
> Float: --- ok
>
> A bug. Thanks.

Looks fine to me.

On 09/11/2021 01:54, dxforth wrote:
> On 9/11/2021 09:30, Marcel Hendrix wrote:
>> On Monday, November 8, 2021 at 6:39:54 PM UTC+1, Gerry Jackson wrote:
>>> On 08/11/2021 16:17, dxforth wrote: > On 9/11/2021 00:14, dxforth
>>> wrote: >> On 8/11/2021 22:31, Ruvim wrote: >>> On 2021-11-08 13:34,
>>> dxforth wrote: >>>>
>> [..]
>>> That's interesting. Given the following code (there's probably a
>>> simpler way to demonstrate the issue but this suffices)
>>> : a 128 32 do i c, loop ; : b 3 0 do a loop ; 0. 2value c here 128 32
>>> - 3 * to c b : d [ c ] sliteral cr type ;
>>> If the following two lines in a Forth system don't display the same
>>> long string that system is not compliant with ANS/Forth2012.
>>> c cr type d
>>
>> FORTH> : a 128 32 do i c, loop ;  ok
>> FORTH> : b 3 0 do a loop ;  ok
>> FORTH> 0. dvalue c  ok
>> FORTH> here 128 32 - 3 * to c  ok
>> FORTH> b  ok
>> FORTH> : d [ c ] sliteral cr type ;
>> Error -64
>> quoted string should be less than 256 characters ?
>> FORTH> c .s
>>    Data: 20176896 288 ---
>> System: ---
>>   Float: --- ok
>>
>> A bug. Thanks.
>
> Looks fine to me.

A warning would be better than a misleading error message given that
it is perfectly valid ANS Forth

--
Gerry

On 9/11/2021 19:05, Gerry Jackson wrote:
> On 09/11/2021 01:54, dxforth wrote:
>> On 9/11/2021 09:30, Marcel Hendrix wrote:
>>> On Monday, November 8, 2021 at 6:39:54 PM UTC+1, Gerry Jackson wrote:
>>>> On 08/11/2021 16:17, dxforth wrote: > On 9/11/2021 00:14, dxforth
>>>> wrote: >> On 8/11/2021 22:31, Ruvim wrote: >>> On 2021-11-08 13:34,
>>>> dxforth wrote: >>>>
>>> [..]
>>>> That's interesting. Given the following code (there's probably a
>>>> simpler way to demonstrate the issue but this suffices)
>>>> : a 128 32 do i c, loop ; : b 3 0 do a loop ; 0. 2value c here 128 32
>>>> - 3 * to c b : d [ c ] sliteral cr type ;
>>>> If the following two lines in a Forth system don't display the same
>>>> long string that system is not compliant with ANS/Forth2012.
>>>> c cr type d
>>>
>>> FORTH> : a 128 32 do i c, loop ;  ok
>>> FORTH> : b 3 0 do a loop ;  ok
>>> FORTH> 0. dvalue c  ok
>>> FORTH> here 128 32 - 3 * to c  ok
>>> FORTH> b  ok
>>> FORTH> : d [ c ] sliteral cr type ;
>>> Error -64
>>> quoted string should be less than 256 characters ?
>>> FORTH> c .s
>>>    Data: 20176896 288 ---
>>> System: ---
>>>   Float: --- ok
>>>
>>> A bug. Thanks.
>>
>> Looks fine to me.
>
> A warning would be better than a misleading error message given that
> it is perfectly valid ANS Forth
>

The '-64 error' is confusing and I'd leave out 'quoted'.
I would hope it's valid ANS but couldn't find an SLITERAL length limit
in the spec or I missed it.

On 09/11/2021 08:59, dxforth wrote:
> On 9/11/2021 19:05, Gerry Jackson wrote:
>> On 09/11/2021 01:54, dxforth wrote:
>>> On 9/11/2021 09:30, Marcel Hendrix wrote:
>>>> On Monday, November 8, 2021 at 6:39:54 PM UTC+1, Gerry Jackson wrote:
>>>>> On 08/11/2021 16:17, dxforth wrote: > On 9/11/2021 00:14, dxforth
>>>>> wrote: >> On 8/11/2021 22:31, Ruvim wrote: >>> On 2021-11-08 13:34,
>>>>> dxforth wrote: >>>>
>>>> [..]
>>>>> That's interesting. Given the following code (there's probably a
>>>>> simpler way to demonstrate the issue but this suffices)
>>>>> : a 128 32 do i c, loop ; : b 3 0 do a loop ; 0. 2value c here 128
>>>>> 32 - 3 * to c b : d [ c ] sliteral cr type ;
>>>>> If the following two lines in a Forth system don't display the same
>>>>> long string that system is not compliant with ANS/Forth2012.
>>>>> c cr type d
>>>>
>>>> FORTH> : a 128 32 do i c, loop ;  ok
>>>> FORTH> : b 3 0 do a loop ;  ok
>>>> FORTH> 0. dvalue c  ok
>>>> FORTH> here 128 32 - 3 * to c  ok
>>>> FORTH> b  ok
>>>> FORTH> : d [ c ] sliteral cr type ;
>>>> Error -64
>>>> quoted string should be less than 256 characters ?
>>>> FORTH> c .s
>>>>    Data: 20176896 288 ---
>>>> System: ---
>>>>   Float: --- ok
>>>>
>>>> A bug. Thanks.
>>>
>>> Looks fine to me.
>>
>>    A warning would be better than a misleading error message given that
>> it is perfectly valid ANS Forth
>>
>
> The '-64 error' is confusing and I'd leave out 'quoted'.

Yes, in Forth 2012 -64 is the exception code for DELETE-FILE

> I would hope it's valid ANS but couldn't find an SLITERAL length limit
> in the spec or I missed it.

I don't think there is any limit specified for SLITERAL

--
Gerry