Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ruvim <ruvim.pinka@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: portable or not? Volatile strings
Date: Mon, 12 Aug 2024 15:00:53 +0400
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <v9cq17$364en$4@dont-email.me>
References: <nnd$3d18fe02$76aace5d@9eae9618ab09b239>
 <v9cfp9$364en$1@dont-email.me> <nnd$05375ad3$6e018fac@ef3f66902c87c893>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 Aug 2024 13:00:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f6b7ac0d41814a48556029f556ee937f";
	logging-data="3346903"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/XcUz2Tpu1EQe6Am3KRtQI"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:dCazgBbK4+YsXtFBCcARBpXrkpg=
In-Reply-To: <nnd$05375ad3$6e018fac@ef3f66902c87c893>
Content-Language: en-US
Bytes: 4262

On 2024-08-12 13:01, albert@spenarnc.xs4all.nl wrote:
> In article <v9cfp9$364en$1@dont-email.me>,
> Ruvim  <ruvim.pinka@gmail.com> wrote:
>> On 2024-08-11 17:35, albert@spenarnc.xs4all.nl wrote:
[...]
>>> I made S" " such that it ALLOT's the string at HERE, to
>>> prevent problems with going out of scope, even in interpret mode.
>>> (Only 256,000,000,000 -10 bytes left).
>>>
>>> This doesn't sit well with the definition of BRICK1 ,
>>> that sees its data area grabbed.
>>> You are probably not surprised that tetris doesn't work.
>>>
>>> The question is, is it legal to store these temporary strings
>>> in the dictionary in this way?
>>
>>
>> Strings that are stored relatively to the HERE address may become
>> invalid after:
>>      - a definition is created via a defining word;
>>      - definitions are compiled with : or :NONAME;
>>      - data space is allocated using ALLOT, `,` (comma),
>>        `C,` (c-comma), or ALIGN.
>> — as "3.3.3.6 Other transient regions"
> 
> Not relevant. My "transient" region is permanent. That I have
> permission to invalidate doesn't affect me.


Yes, this is not relevant to your case, but this is correct by itself.

Then I realized irrelevance and made another post.



> 
>> <https://forth-standard.org/standard/usage#usage:transient> says.
>>
>> All affected transition regions shall be listed. If a region is not
>> listed as affected, than it is not affected by allocating data space memory.
> 
> My regions are not affected. So again this is not relevant.

There is no need to repeat this.

[...]

>> In the same time, a Forth system is allowed to limit the buffer
>> lifetime (for example, till the next memory allocation), and
>> document it as an environmental restriction.

[...]

> I can't make out what you think.

A possible implementation for the interpretation semantics for `S"` is 
to keep data somewhere in the memory region that returns by "here 
unused", and declare the lifetime restriction for the returned string.

For example:

   128 constant _sbufsize
   0 value _sn
   4 value _snlimit

   : _sbuf-next ( -- c-addr u )
     here aligned 4096 +  _sbufsize _sn * + _sbufsize
     ( c-addr.buf u.buf-len )
     2dup + here unused + u> if -8 throw then \ "dictionary overflow"
     _sn 1+ _snlimit mod to _sn
   ;
   : _memorize-string ( c-addr1 u -- c-addr2 u )
     >r _sbuf-next r@ u< ( c-addr c-addr.buf flag )
     if -18 throw then \ "parsed string overflow"
     r@ over >r chars move  r> r>
   ;

   : s" ( -- c-addr u | )
     '"' parse compilation if slit, exit then _memorize-string
   ; immediate


At first I thought you were asking about this approach.

This approach implies an environmental restriction.




> 
>>>
>>> [ It was sufficient to replace S" with S"' in order to make it run:
>>> : S"' &" PARSE ;
>>> ]
> 
> Okay let's say it out loud. Classic Forth is not fit for handling strings.
> A denotation that generates a constant string "blablabla" that has
> a status as a number is long overdue.
> The mindset of formulating standards is so 70's.
> 

Why not prepare a proposal?


--
Ruvim