Forth support
Forth support
First of all, i registered for this forum last night as when i try to log in this morning my account is deleted. I have to try 5 or 6 times to get past the very badly implemented capcha when i create my account.
ok... BUGS...
Please add a way of specifying a BLANK and ONLY A BLANK as a word/number delimiter.
In each of the following the initial blank can be the start of the line instead of a blank...
A HEX number is any BLANK followed by a dollar sign, followed by [0-9/a-z] in any case, followed by a blank.
A binary number can be any blank followed by a % symbol followed by [0-1] followed by a blank
an octal number can be any blank followed by a \ followed by [0-7] followed by a blank
A word is any blank, followed by ANY characters followed by any blank. If the specified word does not represent a legal number then it is a word
$123foo is not a number
\ this is a line comment
\34 this is an octal number not a line comment
\this-is-not-a-comment-or-a-number
( this is a stack comment )
(this-is-not-a-stack-comment)
does> this is the word does> which is a keyword
123does> this is not the word does>
does>foo neither is this
if im getting my regular expressions right the following should be a legal representation for numbers.. .
(^| )+(($[09-A-Fa-f)+ +)|(\[0-7]+ +)|([0-9]+ +))
also need to be able to add ANY character what so ever (ither than a blank) to keywrod names
ALL of the following space delimited tokens are legal keywords
does> >r [compile] ." abort" abort '
does <-- this is NOT a forth keyword there is no > on it
ok... BUGS...
Please add a way of specifying a BLANK and ONLY A BLANK as a word/number delimiter.
In each of the following the initial blank can be the start of the line instead of a blank...
A HEX number is any BLANK followed by a dollar sign, followed by [0-9/a-z] in any case, followed by a blank.
A binary number can be any blank followed by a % symbol followed by [0-1] followed by a blank
an octal number can be any blank followed by a \ followed by [0-7] followed by a blank
A word is any blank, followed by ANY characters followed by any blank. If the specified word does not represent a legal number then it is a word
$123foo is not a number
\ this is a line comment
\34 this is an octal number not a line comment
\this-is-not-a-comment-or-a-number
( this is a stack comment )
(this-is-not-a-stack-comment)
does> this is the word does> which is a keyword
123does> this is not the word does>
does>foo neither is this
if im getting my regular expressions right the following should be a legal representation for numbers.. .
(^| )+(($[09-A-Fa-f)+ +)|(\[0-7]+ +)|([0-9]+ +))
also need to be able to add ANY character what so ever (ither than a blank) to keywrod names
ALL of the following space delimited tokens are legal keywords
does> >r [compile] ." abort" abort '
does <-- this is NOT a forth keyword there is no > on it
Thank you for your detailed post.Please add a way of specifying a BLANK and ONLY A BLANK as a word/number delimiter.
I can see Zeus needs a fair bit of work to make it work with Forth

I am happy enough to try to make whatever coding changes required provided you are happy enough to do the testing

This is a bug in the line commenting code that will need to be fixed.\34 this is an octal number not a line comment
(\$[0-9A-Fa-f]+ )A HEX number is any BLANK followed by a dollar sign, followed by [0-9/a-z] in any case, followed by a blank.
(\%[0-1]+ )A binary number can be any blank followed by a % symbol followed by [0-1] followed by a blank
(\\[0-7]+ )an octal number can be any blank followed by a \ followed by [0-7] followed by a blank
So I think this should work as the Numbers Regexp:
(\$[0-9A-Fa-f]+ )|(\%[0-1]+ )|(\\[0-7]+ )
But you will also need to change the Delimiters string to be:
?,:;<>{}[]*+/=|&!@.()!
This is where my very limited knowledge of forth is a problem.I also need to be able to add ANY character what so ever (either than a blank) to keyword names
Because I don't know Forth well enough I don't know how the code should look in terms of color

I think the following should fix this painting issue:ALL of the following space delimited tokens are legal keywords
does> >r [compile] ." abort" abort '
does <-- this is NOT a forth keyword there is no > on it
- Turn on the Keywords take precedence over delimiters option
- Delete the does keyword
- Delete the r keyword
- Add the >r keyword
- Add the does> keyword
Unfortunately, based on what you have told me it would appear that a lot of that definition is incorrect

So I suspect making lots of changes via the dialog box may become quite frustrating.
What I would suggest as a better alternative is to do the following:
- Export the keyword details using the Export button
- Start a second copy of Zeus
- Edit the export file in that copy of Zeus and save the file changes
- Go back to the first copy of Zeus an import the file
- As you apply the changes you should see the effect of the changes on the code
- Repeat as required
Cheers Jussi
This suggestion makes sense too.jussij wrote:What I would suggest as a better alternative is to do the following:I should have a fix for the line comment bug very shortly.
- Export the keyword details using the Export button
- Start a second copy of Zeus
- Edit the export file in that copy of Zeus and save the file changes
- Go back to the first copy of Zeus an import the file
- As you apply the changes you should see the effect of the changes on the code
- Repeat as required
There are MANY MANY MANY words that are part of the ans forth standard that I personally do not (WILL NOT) ever support (there are aesthetic AND logical reasons for this, not just pure hatred :) but which your users MIGHT want to have supported.
I cannot express enough how much I loathe the ans forth standard but it is what most people foolishly try to comply with when they create a forth compiler these days. To begin with what Ill do is create a list of all keywords in IsForth (at least core words) and get things working "FOR ME" and then work on making things for you and your other forth users (the insane ones) working as per the ans standard.
Its not very often you get direct replies from the author of the tools you download to try out... thats just one more +1 for you :)
< EDIT >
ok i guess im NUB at this whole BB thing, how do i make it not take both your posting and my replies to each point item as being a quote of you?
export doesnt seem to work
I exported the keywords as you suggested but while I see all the comment types config items and the numbers regular expression there are no actual keywords in the saved file... what did i do wrong?
Ok what i did was i copied the zki file for forth out of the examples directory, edited it and imported from that. i get zero keywords imported. either thers a bug with import or theres some other issue with forth that makes it difficult for zeus to properly interpret the file i have :)
might work best if i send you that file? (it IS very isforth specific though).
Ok what i did was i copied the zki file for forth out of the examples directory, edited it and imported from that. i get zero keywords imported. either thers a bug with import or theres some other issue with forth that makes it difficult for zeus to properly interpret the file i have :)
might work best if i send you that file? (it IS very isforth specific though).
I have created a new Zeus beta that should correctly handle Forth line comments.Please add a way of specifying a BLANK and ONLY A BLANK as a word/number delimiter.
It can be found here: http://www.zeusedit.com/z300/ze397i-beta.zip
This version lets you define the line comment string as: '\ '
The previous version would always convert '\ ' to '\' and hence break the line commenting.
The block comment issue still remains but that too should be fixed shortly.
I think you should should use this same approach for setting up Zeus for Forth.To begin with what I'll do is create a list of all keywords in IsForth (at least core words) and get things working "FOR ME" and then work on making things for you and your other forth users (the insane ones) working as per the ans standard.
I would suggest taking the keyword import template at the end of this posting and use it to create a new Forth.zki file.
Then add your list of keywords to the template (one keyword per line) in the [ReservedWords] section.
If you then import the file back into the Forth Document type it should hopefully highlight your code correctly.
Naturally if you find examples of Forth code that don't highlight properly just post a bug report

I find editing posts in the postage stamp edit box that BB offers is very hard.ok i guess im NUB at this whole BB thing, how do i make it not take both your posting and my replies to each point item as being a quote of you?
So what I do is select the text from inside the BB edit box, copy the text into Zeus and then craft my reply using Zeus.
Ony when I am ready to preview the reply do I paste it back only into the BB edit box.
I am always very grateful for feedback from users like yourself.Its not very often you get direct replies from the author of the tools you download to try out... thats just one more +1 for you
By design Zeus attempts to be language neutral with the hope that it can be used by programmers of any language and it is only feedback like this that makes it possible.
Try this:Ok what i did was i copied the zki file for forth out of the examples directory, edited it and imported from that.
- Create a c:\temp\forth.zki using the template below
- Open a Forth document
- Select the Options, Keywords Options menu
- Select the Import button and import the c:\temp\forth.zki file
- Apply the changes
;
; Zeus Forth Keyword Information File
; =========================================
;
[Syntax]
CommentStart01=(
CommentEnd01=)
NestsComments01=Yes
LineComment01=1:--
CommentStart02=
CommentEnd02=
NestsComments02=Yes
LineComment02=\
Delimiters=?,:;<>{}[]*+/=|&!@.()!
DelimitKeywords=Yes
IgnoreCase=Yes
Literal=
ManageComments=Yes
Numbers=(\$[0-9A-Fa-f]+)|(\%[0-1]+)|(\\[0-7]+)
Preprocessor=
Strings="'
TripleQuotes=No
[ReservedWords]
>r
does>
[ExReservedWords]
Pattern=
IsNested=No
[UserWords1]
[ExUserWords1]
Pattern=
IsNested=No
[UserWords2]
[ExUserWords2]
Pattern=
IsNested=No
[UserWords3]
[ExUserWords3]
Pattern=
IsNested=No
[UserWords4]
[ExUserWords4]
Pattern=
IsNested=No
[UserWords5]
[ExUserWords5]
Pattern=
IsNested=No
Also need a way to add blanks to the regular expressions for numbers. In a thoroughly butchered example of a close approximation of BNF...
:eol: = (\n|\r)
:blank: = (space|tab)
:hex: = ($[0-9a-fA_F]+(:blank:|:eol:))
:oct: = (\[0-7]+(:blank:|:eol:))
:dec: = ([0-9]+(:blank:|:eol:))
so the regular expression for a number would be....
(^|:blank:)((:hex:)|(:oct:)|(:dec:))
complificated aint it :)
currently working on an isforth specific keyword file... will get back to you. though i actually think your existing forth keyword file would be correct if it was imported right. the import seems to be stripping off the +-><!# etc etc characters from the word names... once the number representation, separators and commenting issues are resolve it looks like that should be a 99% working :)
:eol: = (\n|\r)
:blank: = (space|tab)
:hex: = ($[0-9a-fA_F]+(:blank:|:eol:))
:oct: = (\[0-7]+(:blank:|:eol:))
:dec: = ([0-9]+(:blank:|:eol:))
so the regular expression for a number would be....
(^|:blank:)((:hex:)|(:oct:)|(:dec:))
complificated aint it :)
currently working on an isforth specific keyword file... will get back to you. though i actually think your existing forth keyword file would be correct if it was imported right. the import seems to be stripping off the +-><!# etc etc characters from the word names... once the number representation, separators and commenting issues are resolve it looks like that should be a 99% working :)
A new Zeus beta that should handle Forth block comments a little better can be found here:
http://www.zeusedit.com/z300/ze397i-beta.zip
To make this work just define the block comment as follows:

So I think the complete Numbers Regexp would be:
(\$[0-9A-Fa-f]+[\t ]*)|(\%[0-1]+[\t ]*)|(\\[0-7]+[\t ]*)|([0-9]+[\t ]*)
Also I'm pretty sure the trailing whitespace is already handled by the Zeus generic parser so I think this reduced regexp will also work:
(\$[0-9A-Fa-f]+)|(\%[0-1]+)|(\\[0-7]+)|([0-9]+)

To test this I created a simplified test.zki file which defines the following short list of *imaginary* Forth keywords words:
Cheers Jussi
PS: If you are editing the import file in Zeus you will need to turn off the Trim line white space on save option found in the Options, Editor Option menu, General section.
http://www.zeusedit.com/z300/ze397i-beta.zip
To make this work just define the block comment as follows:
Code: Select all
Start: '( '
End: ' )'
Line: '/ '
NOTE: Don't add the quote characters. The quotes are only there to highlight the whitespace.
Complificated maybe, but I think it is still possiblecomplificated aint it

Code: Select all
Hex: (\$[0-9A-Fa-f]+[\t ]*)
Binary: (\%[0-1]+[\t ]*)
Octal: (\\[0-7]+[\t ]*)
Decimal: ([0-9]+[\t ]*)
(\$[0-9A-Fa-f]+[\t ]*)|(\%[0-1]+[\t ]*)|(\\[0-7]+[\t ]*)|([0-9]+[\t ]*)
Also I'm pretty sure the trailing whitespace is already handled by the Zeus generic parser so I think this reduced regexp will also work:
(\$[0-9A-Fa-f]+)|(\%[0-1]+)|(\\[0-7]+)|([0-9]+)
I'm not seeing thisthe import seems to be stripping off the +-><!# etc etc characters from the word names...

To test this I created a simplified test.zki file which defines the following short list of *imaginary* Forth keywords words:
After I import this file into the Forth document type the reserved section of the keywords dialog displays the expected set of keywords:[ReservedWords]
>r
does>
test+-><!#
test+
test-
test>
test<
test!
test#
and these keywords also paint correctly in a Forth document file.>r
does>
test+-><!#
test+
test-
test>
test<
test!
test#
Cheers Jussi
PS: If you are editing the import file in Zeus you will need to turn off the Trim line white space on save option found in the Options, Editor Option menu, General section.
might have just been a glitch
Im no longer seeing the non alphanumeric characters being stripped from the keyword lists now either but i am seeing that I cannot export. makes things difficult because im running this editor inside a Linux virtual machine running under windows 7. pretty much every dialog/edit/box etc is so small for me its almost unreadable and i think i just exported over the top of the file i had originall imported and blown it away lol. hopefully i has a copy somewhere
small request...
The functions list is showing as follows for me....
: word-name ( stack comment ) any code thats on this same source line
while i LOVE being able to see the stack comment next to the word name anything after that should be truncated away if possible... also... can we make the font these menu items are displayed in configurable. all my stack comments are aligned on column 17 in my editor and are all sqiggly aligned insode the functions list :) A proportional font would be nice :)
trying new version now, i went thataway -->
small request...
The functions list is showing as follows for me....
: word-name ( stack comment ) any code thats on this same source line
while i LOVE being able to see the stack comment next to the word name anything after that should be truncated away if possible... also... can we make the font these menu items are displayed in configurable. all my stack comments are aligned on column 17 in my editor and are all sqiggly aligned insode the functions list :) A proportional font would be nice :)
trying new version now, i went thataway -->
This might indeed be a bug in the export dialog and Windows 7but i am seeing that I cannot export. makes things difficult because im running this editor inside a Linux virtual machine running under windows 7.

I'm guessing the default folder that Zeus is picking for the export dialog is probably write protected under Windows 7

A simple work around would be to provide a fully qualified name inside the Export dialog, for example something like: c:\temp\Forth.zki
Another Zeus user also had issues Exporting on Windows 7 and he found this work around.
So the bug might be that the name Zeus is creating as a filename suggestion is not in fact a valid filenameIf I removed the spaces in the filename suggested by Zeus, navigated away from the suggested folder (e.g. to Desktop), and then clicked "Save"... it worked!

I'm running Windows XP so I am not seeing this, but I will do some testing on a Windows 7 machine and see if I can replicate the issue.
Zeus is showing it agepretty much every dialog/edit/box etc is so small for me its almost unreadable

Zeus started out life when screens where 640 x 480 and some of these dialogs where made to fit that screen size.
Later on the Zeus dialogs where re-worked when screens grew to 800 x 600 and 1024 x 768 but these days screens have once again grown much bigger than that.
The contents of the functions list come from two possible sources.The functions list is showing as follows for me....
: word-name ( stack comment ) any code thats on this same source line
If you have a workspace open, the function list will be loaded using the function information from the tag database for the currently active file.
If the currently active file is not in the workspace or no workspace is open then the functions list is loaded using the function regexp defined in the document type.
The function regexp found in the document type can be any regexp and any line that matches the regexp gets added added to the list.
This might be possible at least for the function regexp case. I will see what can be done.while i LOVE being able to see the stack comment next to the word name anything after that should be truncated away if possible...
I'll see what I can doalso... can we make the font these menu items are displayed in configurable.

Cheers Jussi
while i LOVE being able to see the stack comment next to the word name anything after that should be truncated away if possible...
A new Zeus beta found in the link below allows more control over the display of these function names:
http://www.zeusedit.com/z300/ze397i-beta.zip
To make it work go to the General section of the Forth document type and change the Function regexp to be:
(^:[ \t]*[a-zA-Z0-9\-\_]+[ \t]*[\(]*.*[\)]*)
Cheers Jussi
regular expressions..
The following is the regular expression i wrote to do function name recognition
^:[\s]+[[:graph:]]+[\s]+
This took me a LONG time to figure out and is still only an approximation of the way colon definitions can be expressed. theres no actual requirement for the : to be in column 1 though the norm is for it to be there.. however, some people have been known to do...
: foo ..... ; : bar ..... ;
...to define functions foo and bar on the same line. Im not worried about handling these cases, i consider it bad form to code this way :)
HOWEVER!!! Another problem is that wrapping things up inside ( ) pairs seems to confuse your expression parser so...
(^:[\s]+)([[:graph:]]+)([\s]+)
..for example does not work the same as the above expression (or is it ME thats confused?).
also. the \s should also be definable as [:space:] (the posix way of expressing blanks) but thats not recognized. also, some parsers recognize \W in place of [:graph:] but yours doesn't (thats not a bug, not everyone recognizes \W).
So anyway we now have a means of recognizing function names but no way to recognize variables and constants. codewrite allowed one to give a separate regular expression for variables/constants/functions :)
in 'standard' (sic) forth we can define..
0 constant foo
variable bar
isforth also defines var and const (ans forth has 'value' which is the same as my var but i consider the name value to be totally non descriptive of its purpose).
0 const blah
10 var ten
in all of the above examples the variable/constant is NOT in column 1 though it can be. I prefer to indent them personally but most people dont. also, var, const and constant all have a value expressed FIRST. the value is not part of the name so can be ignored .
[\s]*variable[\s]+[[:graph:]]+[\s]+
[\s]*constant[\s]+[[:graph:]]+[\s]+
[\s]*var[\s]+[[:graph:]]+[\s]+
[\s]*const[\s]+[[:graph:]]+[\s]+
If i could do (variable|constant|var|const) i could express it in one line.
[\s]*(variable|constant|var|const)[\s]+[[:graph:]]+[\s]+
but as stated above i seem to be having issues with ()
^:[\s]+[[:graph:]]+[\s]+
This took me a LONG time to figure out and is still only an approximation of the way colon definitions can be expressed. theres no actual requirement for the : to be in column 1 though the norm is for it to be there.. however, some people have been known to do...
: foo ..... ; : bar ..... ;
...to define functions foo and bar on the same line. Im not worried about handling these cases, i consider it bad form to code this way :)
HOWEVER!!! Another problem is that wrapping things up inside ( ) pairs seems to confuse your expression parser so...
(^:[\s]+)([[:graph:]]+)([\s]+)
..for example does not work the same as the above expression (or is it ME thats confused?).
also. the \s should also be definable as [:space:] (the posix way of expressing blanks) but thats not recognized. also, some parsers recognize \W in place of [:graph:] but yours doesn't (thats not a bug, not everyone recognizes \W).
So anyway we now have a means of recognizing function names but no way to recognize variables and constants. codewrite allowed one to give a separate regular expression for variables/constants/functions :)
in 'standard' (sic) forth we can define..
0 constant foo
variable bar
isforth also defines var and const (ans forth has 'value' which is the same as my var but i consider the name value to be totally non descriptive of its purpose).
0 const blah
10 var ten
in all of the above examples the variable/constant is NOT in column 1 though it can be. I prefer to indent them personally but most people dont. also, var, const and constant all have a value expressed FIRST. the value is not part of the name so can be ignored .
[\s]*variable[\s]+[[:graph:]]+[\s]+
[\s]*constant[\s]+[[:graph:]]+[\s]+
[\s]*var[\s]+[[:graph:]]+[\s]+
[\s]*const[\s]+[[:graph:]]+[\s]+
If i could do (variable|constant|var|const) i could express it in one line.
[\s]*(variable|constant|var|const)[\s]+[[:graph:]]+[\s]+
but as stated above i seem to be having issues with ()
The function regexp dates back to the very early days of Zeus.So anyway we now have a means of recognizing function names but no way to recognize variables and constants.
The preferred method is to use a workspace and have ctags identify these types of constructs.
For example, if you create a workspace and add your Forth code to that workspace you should see these types of constructs displayed in the Classes panel.
Now it might be you don't see these items displayed, but that just means the ctags support for Forth is not complete or incorrect.
Code: Select all
[\s]*variable[\s]+[[:graph:]]+[\s]+
[\s]*constant[\s]+[[:graph:]]+[\s]+
[\s]*var[\s]+[[:graph:]]+[\s]+
[\s]*const[\s]+[[:graph:]]+[\s]+
But one issue you may run into is the fact that the ctags regexp engine is differenct to the one in Zeus so you may have to tweak these expressions to get them to work with ctags.
I will take a look at this.but as stated above i seem to be having issues with ()
Cheers Jussi
I have created a new Zeus beta that has a new Index entry field in the Document Type that defines which sub-expression is to be used as the result.
It can be found here: http://www.zeusedit.com/z300/ze397i-beta.zip
To test this new version I created a Forth file with the following code:
I then defined the function regexp to be as follows and set the sub-expression index value to two:
NOTE: This is slightly different to your original regexp: [\s]*(variable|constant|var|const)[\s]+[[:graph:]]+[\s]+
The function panel now displays the variable and constant names as expected:
Alternatively if you use the following function regexp and set the sub-expression index value to one the displayed results would also include the contant and variable details:
Cheers Jussi
It can be found here: http://www.zeusedit.com/z300/ze397i-beta.zip
To test this new version I created a Forth file with the following code:
Code: Select all
0 constant foo
variable
0 const blah
10 var ten
0 constant foo1
variable bar1
0 const blah1
10 var ten1
Code: Select all
[\s]*(variable|constant|var|const)[\s]+([[:graph:]]+)[\s]*
The function panel now displays the variable and constant names as expected:
Code: Select all
foo
blah
ten
foo1
bar1
blah1
ten1
Code: Select all
[\s]*((variable|constant|var|const)[\s]+([[:graph:]]+))[\s]*
the \s should also be definable as [:space:] (the posix way of expressing blanks) but thats not recognized.
I thought [:space:] was supported by Zeus

These are the POSIX expressions that are supported:
Code: Select all
alpha Any alphabetical character ("[A-Za-z]")
alnum Any alphanumeric character. ("[A-Za-z0-9]")
ascii Any character in the ASCII character set
blank A GNU extension, equal to a space or a horizontal tab ("\t")
cntrl Any control character
digit Any decimal digit ("[0-9]"), equivalent to "\d"
graph Any printable character, excluding a space
print Any printable character, including a space
punct Any graphical character excluding "word" characters
space Any whitespace character. "\s" plus the vertical tab ("\cK")
word A Perl extension ("[A-Za-z0-9_]"), equivalent to "\w"
xdigit Any hexadecimal digit ("[0-9a-fA-F]").
Code: Select all
lower Any lowercase character ("[a-z]")
upper Any uppercase character ("[A-Z]")
Zeus interprets the and \s \S \w \W as follows:some parsers recognize \W in place of [:graph:] but yours doesn't (thats not a bug, not everyone recognizes \W).
Code: Select all
\w Match a "word" character ("[A-Za-z0-9_]")
\W Match a non-"word" character ("[^A-Za-z0-9_]"
\s Match a whitespace character
\S Match a non-whitespace character