flat assembler
Message board for the users of flat assembler.

Index > MenuetOS > Safety Forth features

Author
Thread Post new topic Reply to topic
Hugh-Aguilar



Joined: 26 May 2020
Posts: 55
Hugh-Aguilar 11 Sep 2020, 04:42
I started a new thread to discuss what Safety Forth is for.

Previously I said this:
Hugh-Aguilar wrote:

[Safety Forth]would allow people to distribute closed-source programs and not worry about anybody slapping a copyright notice on it. At the same time, it would allow users to download programs and run them without worrying that the programs are malware. This is essentially the same idea that inspired Java.

I have heard a lot of bad things about the Java language (that it is similar to COBOL in bloat, lack of features and general mentality) --- I don't have any interest in learning Java --- I am primarily interested in Forth that is very lightweight.

Ville wrote:
Currently Menuet is the only OS written 100% in assembly with modern feature-set and it took us some time to realize this goal. This is also an easily identifiable place in the computing world.

Maybe Safety Forth is a bad fit for Menuet --- you want to stick to 100% assembly-language.

If Safety Forth does get developed, there would definitely be a two-tier system of Menuet users: the elite who program in FASM, and the plebeian who program in Safety Forth.
I don't see a problem with this. A lot of mundane programs don't require elite super-programmers to write them. Execution speed is not very important.
Getting the program written in a few hours (rather than several days), and getting it written at low cost by an apprentice programmer is important.

For text processing, I have my STRING-STACK.4TH that is currently written in ANS-Forth. This provides a lot of support for pattern-matching and substring-extraction. Here is an example:
Code:
: replace$ ( -- change? )                                       \ string: a targ repl -- a | b      \ replace a TARG in A with REPL to return B
    -rot$  ddup$                                                \ string: -- repl a a targ
    infix$ if                                                   \ string: -- repl a infix
        extract$                                                \ string: -- repl prefix suffix
        rot$ swap$                                              \ string: -- prefix repl suffix
        +$ +$  true
    else                                                        \ string: -- repl a a
        drop$ nip$                                              \ string: -- a
        false  then ;

: replaces$ { | change? -- change? }                            \ string: a targ repl -- a | b      \ replace all TARGs in A with REPL to return B
    begin
        swap$ ruck$  swap$ ruck$                                \ string: targ repl str targ repl
        replace$ while                                          \ string: targ repl str
            true to change?  -rot$  repeat    
    nip$ nip$  change? ;
    

I also have case-insensitive versions. Here is a test:
Code:
s" Gerry is the um greatest um most loyal um ANS-Forth um programmer ever!" mut>$  s" um" mut>$  s" ahh" mut>$  ok
replaces$ . -1  ok
.$ Gerry is the ahh greatest ahh most loyal ahh ANS-Forth ahh programmer ever! ok
    

The other innovation I have is that numbers would be defined as 64-bit fixed-point with unity=2^32. This is as compared to ANS-Forth in which numbers are 16-bit, 32-bit or 64-bit (the size is ambiguous) and unity=1.

My "pseudo-floats" allow about 9 digits on either side of the decimal point. This is adequate for quite a lot of applications, including CAM (generating gcode for CNC machines) which is my own interest. This should be about twice as fast as using double-precision IEEE-754 floats on the x87 (I do internally convert to x87 for SIN COS etc., then convert back again).

The Forth is 64-bit, but addresses are 32-bit (the integer part of the pseudo-float). The threaded code is 32-bit, so it is about half the size of 64-bit threaded code.

So, there you go! Cool You get text processing (there is no regexp though) and numerical programming (fast, but with limited precision and range).
I would consider this to be useful in Menuet for mundane programs.
This is not for elite programmers though --- if all Menuet programmers are elite, then this would be a bad fit --- I'm not elite by any standard, so I would be a bad fit too.

P.S. A regexp package is possible. This has already been done in ANS-Forth, although I would write my own because I never use other people's code. I don't actually like regexp, which is why I haven't done so --- I like my STRING-STACK.4TH for pattern-matching and substring-extraction --- regexp expressions are a lot more concise than my code, but I find them to be difficult to read and difficult to debug (everyone else in the world seems to like them though).

_________________
When all else fails, write the source.
Post 11 Sep 2020, 04:42
View user's profile Send private message Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 55
Hugh-Aguilar 12 Sep 2020, 19:36
Hugh-Aguilar wrote:

For text processing, I have my STRING-STACK.4TH that is currently written in ANS-Forth. This provides a lot of support for pattern-matching and substring-extraction.

I'll provide the documentation for STRING-STACK.4TH in case anybody is interested.

Nobody in the ANS-Forth cult liked my STRING-STACK.4TH. Elizabeth Rather of Forth Inc. provided PAD in ANS-Forth for the purpose of temporarily holding strings. Also, Wil Baden (Forth Inc. employee) implemented a string-stack back in the 1980s, which they believe covers the subject completely. To a large extent, being an ANS-Forth programmer just means supporting Forth Inc.. PAD is in the standard, and Wil Baden's string-stack is a de facto standard. They don't appreciate new code written outside of Forth Inc..

My STRING-STACK.4TH is a little different. I store the strings on the heap, and they can be any size. I have "unique" strings on the heap, and "derivative" strings that contain only a pointer into a unique or constant string. This means that when strings are juggled on the stack, it is not necessary to move entire strings around. Only the pointer and the char-count is in the stack element. I have COW (Copy-On-Write), so it is possible to work with derivative strings. The derivatives only get converted into uniques if they are being modified to or the unique that they are derived from is being modified. In practice, most of the strings on the string-stack are derivatives. This is because the primary purpose is pattern-matching, and the patterns are typically constants, so they are represented as derivatives on the string-stack. Working with strings is very fast because only pointers and counts are being used, and it is rare to need to allocate memory on the heap for a string and copy the string to that memory. Uniques get deallocated when they are consumed, but derivatives are faster because they don't have to be deallocated. The distinction between uniques and derivatives is internal --- the user just programs as if everything were a unique, and he doesn't need to know which strings are unique and which are derivative.

My STRING-STACK.4TH can be the basis for a programming language, similar to how regular expressions are the basis for Perl. I need to find a home for this language though. Windows is a problem because anti-virus systems will red-flag it, and I don't want to pay for a certificate because I consider that to be extortion. Linux is a problem because software is required to be open-source.

It seems obvious that Menuet needs a safe language for working with text. Safety Forth is a possibility. The Menuet developers may want to go with Perl or Java instead --- I wouldn't be involved in Menuet in either of these cases.


Description: documentation for STRING-STACK.4TH
Download
Filename: string-stack.txt
Filesize: 30.98 KB
Downloaded: 758 Time(s)


_________________
When all else fails, write the source.
Post 12 Sep 2020, 19:36
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.