In article ,
Hans Bezemer wrote:
>On 27-04-2025 14:02, albert@spenarnc.xs4all.nl wrote:
>> In article ,
>> Hans Bezemer wrote:
>>> On 27-04-2025 08:21, dxf wrote:
>>>> On 26/04/2025 9:07 pm, albert@spenarnc.xs4all.nl wrote:
>>>>> In article ,
>>>>> dxf wrote:
>>>>>> On 26/04/2025 2:34 am, Hans Bezemer wrote:
>>>>>>> ...
>>>>>>> Yeah, I have helped to make a proposal for PLACE and +PLACE - which
never even made it to the voting stage.
>>>>>>
>>>>>> It's a nice symmetry. OTOH the remaining vendors use APPEND and why
should they change?
>>>>>>
>>>>>
>>>>> $+! was even earlier. It predates the IBM PC XT.
>>>>> (Osborne, CP/M)
>>>>
>>>> Even PLACE was new back then!
>>>>
>>>> String stacks often had $+ or equiv. Somehow I never took to them.
>>>> Not enough applications that warranted the effort?
>>>
>>> Let's face it - the string support was notoriously bad in Forth. People
>>> openly complained about that.
>>
>> You must get rid of two ideas that are in the basic/lisp/c world.
>>
>> 1. You don't need dynamic strings. Just keep track of where you left them.
>> [ If you really need them, don't do circular buffer or string stacks.
>> Interface to the memory wordset (ALLOCATE c.s). ]
>>
>> 2. Zero ended strings is a stupid 60's c-cludge. Copying that into Forth is
>> beyond .. . They can't accomodate zero byte in strings, They cannot
>> accomodate multiple byte characters.
>>
>> If you fetch a string, you have a "c-addr count". Forth can have 2 items
>> on the stack you know.
>>
>> So In my CP/M day I get by with $! $@ $+! and $C+! .
>> I made a program playing a text adventure game with that.
>>
>> Groetjes Albert
>>
>>
>>
>>>
>>> Hans Bezemer
>
>
>-- 2. Zero ended strings is a stupid 60's c-cludge. Copying that into
>Forth is beyond .. . They can't accomodate zero byte in strings, They
>cannot accomodate multiple byte characters.
>
>Well, the "club" has killed that one, so it bears no longer any
>significance. FYI: I was not in favor of this proposition, it reeked
>extremely Forth-83:
>
>"Since then, in 2016 the Forth-200x committee in favour of eliminating
>ambiguous conditions has decided to require “1 CHARS = 1” thus making
>systems that have other character sizes than on not compliant to
>_future_ Forth-200x standards [2][3]. Requesting standard systems to
>have byte size characters limit counted strings to the known maximal
>length of 255 characters."
No. That applies to a string stored in memory.
A beneficial principle is to disambiguate the type of parameters
passed around.
So `WORD requiring a byte count in front of the characters in memory is
a mistake. So in my core strings are exclusively passed as (addr length)
and length can be 63 bit. So a I have `GET-FILE:
(sc -- addr len) Get the content of file name sc (string constant).
Errors are thrown.
Also in my core dictionary entries are identified as one address called
"dea".
No "name token", because it may not have a name filled in.
Not "execution token", because the execution behaviour can be changed
by changing the code field content.
Not a "word" because what is a word without a name?
[This was triggered by the horror of n fields in transputer Forth and
n*n conversions between these fields. (data field >>> forget field ...).
Never looked back.
Through jonesforth most Forth's created nowadays sport a uniform
dea (CDFLN) , because jones borrowed this compelling idea from ciforth,
and is hard to abandon, once it takes hold. ]
Groetjes Albert
>
>Hans Bezemer
>
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
