Forth support

If reporting a bug with the Zeus IDE please post the details here. Please do not post questions here.
Post Reply
mark4th
Posts: 11
Joined: Mon Feb 13, 2012 3:32 pm

Forth support

Post by mark4th »

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
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

Please add a way of specifying a BLANK and ONLY A BLANK as a word/number delimiter.
Thank you for your detailed post.

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 ;)
\34 this is an octal number not a line comment
This is a bug in the line commenting code that will need to be fixed.
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-9A-Fa-f]+ )
A binary number can be any blank followed by a % symbol followed by [0-1] followed by a blank
(\%[0-1]+ )
an octal number can be any blank followed by a \ followed by [0-7] followed by a blank
(\\[0-7]+ )

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:

?,:;<>{}[]*+/=|&!@.()!
I also need to be able to add ANY character what so ever (either than a blank) to keyword names
This is where my very limited knowledge of forth is a problem.

Because I don't know Forth well enough I don't know how the code should look in terms of color :(
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
I think the following should fix this painting issue:
  1. Turn on the Keywords take precedence over delimiters option
  2. Delete the does keyword
  3. Delete the r keyword
  4. Add the >r keyword
  5. Add the does> keyword
The Forth document type was created using an import of a Textpad Forth definition file.

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:
  1. Export the keyword details using the Export button
  2. Start a second copy of Zeus
  3. Edit the export file in that copy of Zeus and save the file changes
  4. Go back to the first copy of Zeus an import the file
  5. As you apply the changes you should see the effect of the changes on the code
  6. Repeat as required
I should have a fix for the line comment bug very shortly.

Cheers Jussi
mark4th
Posts: 11
Joined: Mon Feb 13, 2012 3:32 pm

Post by mark4th »

jussij wrote:What I would suggest as a better alternative is to do the following:
  1. Export the keyword details using the Export button
  2. Start a second copy of Zeus
  3. Edit the export file in that copy of Zeus and save the file changes
  4. Go back to the first copy of Zeus an import the file
  5. As you apply the changes you should see the effect of the changes on the code
  6. Repeat as required
I should have a fix for the line comment bug very shortly.
This suggestion makes sense too.

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?
mark4th
Posts: 11
Joined: Mon Feb 13, 2012 3:32 pm

export doesnt seem to work

Post by mark4th »

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).
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

Please add a way of specifying a BLANK and ONLY A BLANK as a word/number delimiter.
I have created a new Zeus beta that should correctly handle Forth line comments.

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.
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 think you should should use this same approach for setting up Zeus for Forth.

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 ;)
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?
I find editing posts in the postage stamp edit box that BB offers is very hard.

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.
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 :)
I am always very grateful for feedback from users like yourself.

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.
Ok what i did was i copied the zki file for forth out of the examples directory, edited it and imported from that.
Try this:
  1. Create a c:\temp\forth.zki using the template below
  2. Open a Forth document
  3. Select the Options, Keywords Options menu
  4. Select the Import button and import the c:\temp\forth.zki file
  5. Apply the changes
Cheers Jussi
;
; 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
mark4th
Posts: 11
Joined: Mon Feb 13, 2012 3:32 pm

Post by mark4th »

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 :)
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

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:

Code: Select all

Start:   '( '
  End:   ' )'
 Line:   '/ '
NOTE: Don't add the quote characters. The quotes are only there to highlight the whitespace.
complificated aint it :)
Complificated maybe, but I think it is still possible ;)

Code: Select all

    Hex: (\$[0-9A-Fa-f]+[\t ]*)
 Binary: (\%[0-1]+[\t ]*)
  Octal: (\\[0-7]+[\t ]*)
Decimal: ([0-9]+[\t ]*)
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]+)
the import seems to be stripping off the +-><!# etc etc characters from the word names...
I'm not seeing this :(

To test this I created a simplified test.zki file which defines the following short list of *imaginary* Forth keywords words:
[ReservedWords]
>r
does>
test+-><!#
test+
test-
test>
test<
test!
test#
After I import this file into the Forth document type the reserved section of the keywords dialog displays the expected set of keywords:
>r
does>
test+-><!#
test+
test-
test>
test<
test!
test#
and these keywords also paint correctly in a Forth document file.

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.
mark4th
Posts: 11
Joined: Mon Feb 13, 2012 3:32 pm

might have just been a glitch

Post by mark4th »

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 -->
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

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.
This might indeed be a bug in the export dialog and 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.
If 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!
So the bug might be that the name Zeus is creating as a filename suggestion is not in fact a valid filename :!:

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.
pretty much every dialog/edit/box etc is so small for me its almost unreadable
Zeus is showing it age :)

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 functions list is showing as follows for me....

: word-name ( stack comment ) any code thats on this same source line
The contents of the functions list come from two possible sources.

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.
while i LOVE being able to see the stack comment next to the word name anything after that should be truncated away if possible...
This might be possible at least for the function regexp case. I will see what can be done.
also... can we make the font these menu items are displayed in configurable.
I'll see what I can do ;)

Cheers Jussi
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

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
mark4th
Posts: 11
Joined: Mon Feb 13, 2012 3:32 pm

regular expressions..

Post by mark4th »

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 ()
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

So anyway we now have a means of recognizing function names but no way to recognize variables and constants.
The function regexp dates back to the very early days of Zeus.

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]+
You should be able to use these regexp to configure ctags: http://www.zeusedit.com/zforum/viewtopic.php?t=3367

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.
but as stated above i seem to be having issues with ()
I will take a look at this.

Cheers Jussi
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

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:

Code: Select all

0 constant foo
variable

0 const blah
10 var ten

    0 constant foo1
    variable bar1

    0 const blah1
    10 var ten1
I then defined the function regexp to be as follows and set the sub-expression index value to two:

Code: Select all

[\s]*(variable|constant|var|const)[\s]+([[:graph:]]+)[\s]*
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:

Code: Select all

foo
blah
ten  
foo1
bar1
blah1
ten1
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:

Code: Select all

[\s]*((variable|constant|var|const)[\s]+([[:graph:]]+))[\s]*
Cheers Jussi
jussij
Site Admin
Posts: 2650
Joined: Fri Aug 13, 2004 5:10 pm

Post by jussij »

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]").
The following POSIX extensions are also supported but for these to work as expected the Match case sensitivity option must also be checked.

Code: Select all

lower  Any lowercase character ("[a-z]")
upper  Any uppercase character ("[A-Z]")
some parsers recognize \W in place of [:graph:] but yours doesn't (thats not a bug, not everyone recognizes \W).
Zeus interprets the and \s \S \w \W as follows:

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
Cheers Jussi
Post Reply