none) (albert
2023-01-12 11:53:15 UTC
There is an effort underway to collect valuable snippets of
Forth, https://github.com/project-forth-works/
I have regular expression package that I used (i.a.) to transform
the fifth chapter of "thinking forth" from xml to tex and the
manx music score that went through half a dozen different notations.
I have recently used it to convert ARM assembler
language to risc-V language. Regular expression without the
facility to transform texts is a joke.
The program doesn't comply to ISO, so I thought an elaborate
rationale is in order. If you consider the rationale unconvincing,
I will not bother to upload the package.
"
Why ciforthisms?
In short, I could never manage to write the regular expression
package with ciforthism.
Note that to have recently used it to convert ARM assembler
language to risc-V language. Regular expression without the
facility to transform texts is a joke.
****************** STRINGS **********************
A regular expression package handles strings. Any attempt to handle
strings portably in Forth sucks.
1. String denotations.
Strings defined by S" are unacceptable:
the S leads to confusion
Much less visible is the problem that S" AAP" is 3 characters
and S" AAP" is 4, I guess?. In ciforth there is a normal string
denotation:
"AAP" is three chars
" AAP" is four chars
" AAP" is five chars
2.
Strings with escapes are unacceptable:
They conflict with the escapes needed in this package.
There is one exception, the double quote convention.
In order to have a double quote &" in a string you have
to double it like so `` "" ''.
In ciforth you can have strings that span multiple lines,
albeit only in a program.
3. Character denotations, function denotations.
We use &A and for a good reason.
CHAR [CHAR] are verbose and cumbersome.
Moreover the notation 'x' for the character x overloads the tick
too much, because in ciforth ' is reserved to denote dea's.
Functions in a regular expression are passed around as executions tokens
like so 'ADVANCE+ , using a single tick, without square brackets
around it.
POSTPONE 'ADVANCE+
fails because "'ADVANCE+" is not in the dictionary, which is just
as well. ( "ADVANCE+" is present, of course).
4. Low level abstraction fails.
COUNT -TRAILING S" C" WORD PLACE form a non-unified conglomerate
of handling strings.
You need : $! $@ $+! C+$ and $/
Get familiar with these. They are easy, because they use
the underlying buffers explicitly. Any half-assed attempt to
use string-stacks and more poorly conceived abstractions
adds to the problem not the solution.
************************** The library *************************
I use WANT. All words following are supposed to be available.
You can load them, or give an error are they not present.
The library contains tools, notably the SET and BAG tools.
It is not good to have them as part of the package.
First get familiar to the tools, then attempt to read the
package. You have lifted yourself to a higher plane.
That is needed for regular expressions, they are not easy.
Anytime you encounter WANT you have to get familiar to the
tools wanted. In ciforth they are mostly Forth words that
are present in fat Forth's, so there in lies no problem.
****************** USABILITY ******************************
Using Forth programs sucks. Mostly you must have the particular
Forth installed in your computer. Then the invocations leave
much to be desired.
The best one come up with is
<forth> <somesource>
but the question is "where do the parameters go
-- in particular filenames -- ? "
ciforth solves this in four ways, each of those are
preferable in some situations.
1. interactive, you start forth then you load your program
2. scripting, the forth is in the first line of the script
Parameters are passed naturally to the script.
The forth must load the regular expression module first
3. scripting, the regular expressions library is compiled into
an enhanced forth. In the script you specify the the particular
expressions you want changed.
Parameters are passed naturally to the script.
Note that you don't need a Forth installed. The scripting
program is enough. You can send it as an attachment and
it will run on the same Operating System.
4. Compiled. Now the transformations you want to do are
burned into the executable.
Parameters are passed naturally to the script.
Note that you don't need a Forth installed. The scripting
program is enough. You can send it as an attachment and
it will run on the same Operating System.
This sounds a lot of hype. Therefore I have supplied a
simple practical examples, in several circumstances and operating
systems.
"
Groetjes Albert
Forth, https://github.com/project-forth-works/
I have regular expression package that I used (i.a.) to transform
the fifth chapter of "thinking forth" from xml to tex and the
manx music score that went through half a dozen different notations.
I have recently used it to convert ARM assembler
language to risc-V language. Regular expression without the
facility to transform texts is a joke.
The program doesn't comply to ISO, so I thought an elaborate
rationale is in order. If you consider the rationale unconvincing,
I will not bother to upload the package.
"
Why ciforthisms?
In short, I could never manage to write the regular expression
package with ciforthism.
Note that to have recently used it to convert ARM assembler
language to risc-V language. Regular expression without the
facility to transform texts is a joke.
****************** STRINGS **********************
A regular expression package handles strings. Any attempt to handle
strings portably in Forth sucks.
1. String denotations.
Strings defined by S" are unacceptable:
the S leads to confusion
Much less visible is the problem that S" AAP" is 3 characters
and S" AAP" is 4, I guess?. In ciforth there is a normal string
denotation:
"AAP" is three chars
" AAP" is four chars
" AAP" is five chars
2.
Strings with escapes are unacceptable:
They conflict with the escapes needed in this package.
There is one exception, the double quote convention.
In order to have a double quote &" in a string you have
to double it like so `` "" ''.
In ciforth you can have strings that span multiple lines,
albeit only in a program.
3. Character denotations, function denotations.
We use &A and for a good reason.
CHAR [CHAR] are verbose and cumbersome.
Moreover the notation 'x' for the character x overloads the tick
too much, because in ciforth ' is reserved to denote dea's.
Functions in a regular expression are passed around as executions tokens
like so 'ADVANCE+ , using a single tick, without square brackets
around it.
POSTPONE 'ADVANCE+
fails because "'ADVANCE+" is not in the dictionary, which is just
as well. ( "ADVANCE+" is present, of course).
4. Low level abstraction fails.
COUNT -TRAILING S" C" WORD PLACE form a non-unified conglomerate
of handling strings.
You need : $! $@ $+! C+$ and $/
Get familiar with these. They are easy, because they use
the underlying buffers explicitly. Any half-assed attempt to
use string-stacks and more poorly conceived abstractions
adds to the problem not the solution.
************************** The library *************************
I use WANT. All words following are supposed to be available.
You can load them, or give an error are they not present.
The library contains tools, notably the SET and BAG tools.
It is not good to have them as part of the package.
First get familiar to the tools, then attempt to read the
package. You have lifted yourself to a higher plane.
That is needed for regular expressions, they are not easy.
Anytime you encounter WANT you have to get familiar to the
tools wanted. In ciforth they are mostly Forth words that
are present in fat Forth's, so there in lies no problem.
****************** USABILITY ******************************
Using Forth programs sucks. Mostly you must have the particular
Forth installed in your computer. Then the invocations leave
much to be desired.
The best one come up with is
<forth> <somesource>
but the question is "where do the parameters go
-- in particular filenames -- ? "
ciforth solves this in four ways, each of those are
preferable in some situations.
1. interactive, you start forth then you load your program
2. scripting, the forth is in the first line of the script
Parameters are passed naturally to the script.
The forth must load the regular expression module first
3. scripting, the regular expressions library is compiled into
an enhanced forth. In the script you specify the the particular
expressions you want changed.
Parameters are passed naturally to the script.
Note that you don't need a Forth installed. The scripting
program is enough. You can send it as an attachment and
it will run on the same Operating System.
4. Compiled. Now the transformations you want to do are
burned into the executable.
Parameters are passed naturally to the script.
Note that you don't need a Forth installed. The scripting
program is enough. You can send it as an attachment and
it will run on the same Operating System.
This sounds a lot of hype. Therefore I have supplied a
simple practical examples, in several circumstances and operating
systems.
"
Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make
spring. You must not say "hey" before you have crossed the bridge.
Don't sell the hide of the bear until you shot it. Better one bird in
the hand than ten in the air. - the Wise from Antrim -
Don't praise the day before the evening. One swallow doesn't make
spring. You must not say "hey" before you have crossed the bridge.
Don't sell the hide of the bear until you shot it. Better one bird in
the hand than ten in the air. - the Wise from Antrim -