Request for Discussion -- (( and multiline comments

58 views
Skip to first unread message

J Thomas

unread,
Jan 30, 2007, 4:50:56 PM1/30/07
to
RfD -- ((

January 29, 2007
* Second Draft *

Rationale
=========

Problem
-------
Most Forth users find it useful to have a block comment -- a comment
command that covers multiple lines. There are many names for this
because there is no standard.

Names include (( (* /* ( etc.

One standard portable approach is 0 [IF] ..... [THEN] This works on
every standard Forth that implements [IF] [THEN] but it is ugly. It's
easy to rename 0 [IF] to, say, [DOCUMENTATION] and still end with
[THEN] . This solution is not generally accepted as shown by the
existence and use of so many alternatives.


Current Practice
----------------

Many Forth systems provide this capability. I am not yet aware of two
that use the same name.


Solution
--------

Agree on a common name. The more Forth systems that provide a standard
name, the more code will use it and the less trouble it will be
porting that code. Code that uses some other name will still run on
every system that supports it and software can be easily written to
support it elsewhere, but to the extent we use a standard name that
bother can be avoided. All that is needed is that we agree on the
name.


Proposal
========

15.6.2.xxxs (( "comments" TOOLS EXT

Compilation: Perform the execution semantics given below.

Execution: ( "ccc" -- )

Parse text until the word
))
is found or until the current parse area cannot be refilled.
Discard the found )) string. (( is an immediate word.

An ambiguous condition exists if the word )) is not found and the
parse area cannot be refilled.


Typical use
-----------

(( This is a comment, it requires supporting statements.
These statements can go on their own lines.
There might be lots of them. ))

(( ---------------------------------------------------------------
People have lots of styles for comenting.
They like to make their comments stand out as obvious comments.
--------------------------------------------------------------- ))

( ----------------------------------------------------------------)
( They could do that with just ( as traditionally defined. )
( But usually they don't. )
( ----------------------------------------------------------------)


Reference Implementation
------------------------

: MAYBE-REFILL ( S: -- flag ) \ refill if at end of line, 0 if
can't
SOURCE NIP >IN @ > DUP 0= IF DROP REFILL THEN ;

: (( ( S: -- ) \ multi-line comment, ended by ))
BEGIN
[CHAR] ) PARSE 2DROP BL WORD COUNT S" )" COMPARE WHILE
MAYBE-REFILL WHILE
REPEAT
." Multiline comment needed )) and never found it -- ambiguous
condition."
CR ." Your system can do anything at this point and still be a
standard system."
THEN ; IMMEDIATE

WORD can be replaced by PARSE-NAME when the time comes.

It would not be difficult to make a CREATE DOES> word which defines
new words like (( with new ending strings different from )) . I may do
that.


Test Cases
----------

(( 123 . )) 456 .

(( 123 .
456 .
789 . )) .( aaa )

: foo (( 123 .
456 . )) 789 . ;
foo


Remarks
-------

I don't care what name we use provided we can agree on one.
I dislike using /* because there might be some use for files where
Forth code is in C comments and vice versa.


/*

Forth code here

((
*/

C code here

/*
))

More Forth code here

Etc.

That isn't a major concern but /* isn't my top choice.

I don't like to just extend ( ) . One typo in the wrong place with a
looming deadline and you could spend 5 minutes tearing your hair out
figuring out what happened. Also, your multiline comment can't include
a ) which greatly reduces its value.

I kind of like Marcel Hendrix's (* . It encourages intense visuals.

(* ******************************************
* This is a bold comment! *
****************************************** *)

(( )) seems bland and inoffensive, something we could all agree on.
If you prefer something else that's fine.


Mishaps
-------

My first day using APL, somebody came by my keyboard while I was
getting a drink of water, and they started the command that gets a
user string. When I came back nothing I did could get the computer to
notice me. I tried to logout. I tried everything I could think of. I
was stuck. Then somebody suggested I end the string.

Extended comments in files or EVALUATE strings are self-limiting. But
not at the keyboard. If you accidentally get into a comment and the
system seems to be frozen, how long will it take for you to remember
to try )) ? Does your system provide another way to get out of that?
Should and could there be a standard way out?

If there is no obvious way out on your system, a word very similar to
(( could become a password. Type LOCK and when you get a drink of
water the system will ignore all keyboard input until you type XLERB
or whatever you choose for a password. Could that be used maliciously?
Could someone sneak in a bit of Forth code that gets executed during
keyboard entry, and your keyboard freezes until you guess the password
or you abort the Forth?

What if input is redirected to some other source, a streaming source,
and somehow it all gets commented out. All input from that source will
be ignored until it sends the end-comment signal or until you break
the connection. The foreign source can't even tell you that they're
done. Your Forth system hears them but it isn't listening. Is this a
problem?

Bruce McFarling

unread,
Jan 30, 2007, 7:30:51 PM1/30/07
to
I already have ---[ and will keep on using it, but of the namings, I
prefer (*

And I would very much appreciate not having it named /( or, indeed,
anything else beginning with forward-slash.

J Thomas

unread,
Jan 30, 2007, 10:14:17 PM1/30/07
to
On Jan 30, 7:30 pm, "Bruce McFarling" <agil...@netscape.net> wrote:
> I already have ---[ and will keep on using it, but of the namings, I
> prefer (*

I was trying to rewrite some code to make it more portable. It had
multiline comments. I wrote a quick routine to handle them. No big
deal, just one more routine cluttering up the files and the system, so
you can use multiline comments that are basicly just like everybody
else's multiline comments but with a different name.

It looked like a good thing to standardise, not any big deal but it
saves time whenever you start to port a file and it doesn't have yet
another brand new name for multiline comments.

> I already have ---[ and will keep on using it

Maybe I should get to work on that CREATE DOES> routine to make new
multiline comments with a single short line of code. Thank you for
being frank about it.

werty

unread,
Jan 30, 2007, 11:08:41 PM1/30/07
to

If you want it to be specific , youll
argue it forever !

Forth is capable of keying on
2 or more spaces and
other non sense stuff , to key on
comments .

[ B_Register45_99 should be zero ]
/ Comments

Notice how i can use [/] for "line above"


Forth parses spaces and that by itself
is a comment , then sees "and ", and its final !
The solution to stop this debate , is to stop
making precise rules and forcing them on
your opponent !
There is no need to keep Forth parsing
so stupid .

Forth only parses TIB when interacting
with humans , not at run time .
Stop killing Forth with rules ...
A programmer makes his own rules
as he writes .

________________________________________

David N. Williams

unread,
Jan 30, 2007, 11:20:27 PM1/30/07
to
J Thomas wrote:
> RfD -- ((
> [...]

Here's how I do it in my string parsing library, parsing.fs:

: s-input-after ( s -- flag )
(
Advance the input stream to just after the next occurrence of
the string across lines, and leave true if found. If the string
is not found before the end of the file, leave the input stream
positioned there with false. Based on the $> reference in
PARSE-AREA@.
)
( s) 2>r
BEGIN
parse-area@ 2r@ ( area.s s)
search ( area.s false | &found #rem true)
0= WHILE \ not found
( area.s) 2drop
refill 0= IF \ end of file
( s) 2r> 2drop false EXIT THEN
REPEAT \ found
( &found #rem) 2r> ( s) nip /string parse-area! true ;

: (( ( -- ) s" ))" s-input-after drop ; immediate

I've tried a lot of names for a multiline comment word, and
didn't find many of them very aesthetic. My current favorite
is

: --- ( -- ) s" ---" s-input-after drop ; immediate

Here's an example of its use:

: next-input-name ( "<name>" -- word.s ) \ Wil Baden's NEXT-WORD
---
Parse the next word from the input stream across lines. If
word.s is empty, at most whitespace was found. A parsing
implementation of Wil Baden's NEXT-WORD.

NOTE: The implementation does not echo CR's when the lines
in question are being entered interactively at the terminal.
---
BEGIN parse-name dup IF EXIT THEN refill
WHILE 2drop REPEAT ;

I would not vote against (( if there's substantial support for
it.

-- David

Bruce McFarling

unread,
Jan 31, 2007, 1:37:45 AM1/31/07
to

Note that ---[ is a different approach ... that each line is a comment
until an explicit \ comment line indicates that Forth code has
restarted. It is essentially for Forth code embedded in text
commentary, rather than for commentary embedded in Forth code.

m-coughlin

unread,
Jan 31, 2007, 1:38:47 PM1/31/07
to
J Thomas wrote:
[snip]

> Most Forth users find it useful to have a block comment
> -- a comment command that covers multiple lines. There are
> many names for this because there is no standard.
>
> Names include (( (* /* ( etc.
>
> One standard portable approach is 0 [IF] ..... [THEN]
> This works on every standard Forth that implements [IF] [THEN]
> but it is ugly.

Extremely ugly.

> It's easy to rename 0 [IF] to, say,
> [DOCUMENTATION] and still end with [THEN] . This solution
> is not generally accepted as shown by the existence and use
> of so many alternatives.

The situation has not been properly factored. There does not
need to be a new block comment word. There needs to be a word to
tell the system to start interpreting or compiling Forth code
and when to tell it to stop. Everything outside these limits
will be comments. This will allow whatever is needed to print a
Forth program as a document with diagrams, mathematical symbols,
and even as a foreign language that does not use the ASCII Latin alphabet.

--
Michael Coughlin m-cou...@comcast.net Cambridge, MA USA

J Thomas

unread,
Jan 31, 2007, 2:11:17 PM1/31/07
to
On Jan 31, 1:38 pm, m-coughlin <m-cough...@comcast.net> wrote:

> The situation has not been properly factored. There does not
> need to be a new block comment word. There needs to be a word to
> tell the system to start interpreting or compiling Forth code
> and when to tell it to stop. Everything outside these limits
> will be comments. This will allow whatever is needed to print a
> Forth program as a document with diagrams, mathematical symbols,
> and even as a foreign language that does not use the ASCII Latin alphabet.

To do that without anything new, you could take your block comment
command and simply start parsing the file with it. Then when you're
ready to comple code you back out of the block comment until you're
ready to comment again.

If you want you could make a word similar to INCLUDED which starts out
in comment mode. That looks extremely easy to me too, the only concern
being that some rare source code might actually start out with code.

So if we have a standard syntax, then it makes sense for files to
start out with the command that starts a block comment, and it makes
sense for file interpreters to start out in comment mode.

What is the difference between what you want and what I want?

Bruce McFarling

unread,
Jan 31, 2007, 3:43:22 PM1/31/07
to
---[ On Jan 31, 2:11 pm, "J Thomas" ]----

> To do that without anything new, you could take your block comment
> command and simply start parsing the file with it. Then when you're
> ready to comple code you back out of the block comment until you're
> ready to comment again.

I find it more natural to have a word that fits into the context of
the non-Forth text.

The difference between text/forth mixing words and block-comment words
is essentially one of the extent of non-interpreted that we have in
mind. A block comment word is trying to embed a comment block in Forth
source ... so it is reasonable to think of the beginning of the block
to be somewhere in view, and even, as with the (* *) naming that I
prefer, with the comment block looking like

(* *****************************
* * If this was a real comment block,
* * this would say something useful
* *)

And note here that in this text/forth mixing style, it is possible to
quote a comment block without confusing anything ... or even code, if
you block indent the code.

> If you want you could make a word similar to INCLUDED which starts out
> in comment mode. That looks extremely easy to me too, the only concern
> being that some rare source code might actually start out with code.

I'm happy with the source starting with the word that is intended to
put it into literate mode ... whether ---[ or <HTML>

OTOH, there is no need to standardise either ---[ or <HTML> ... a
collection of texts that use that can easily include those in its core
toolkit.

Marcel Hendrix

unread,
Jan 31, 2007, 3:52:39 PM1/31/07
to
"J Thomas" <jeth...@gmail.com> wrote Re: Request for Discussion -- (( and multiline comments
[..]
> Proposal
> ========

> 15.6.2.xxxs (( "comments" TOOLS EXT

[..]

"((" was used in F-PC for something slightly different. AFAIR, it
switched between comments and compiling, and "))" was a word.

The current Win32Forth has "((" like you propose, so that's a plus.

iForth has inherited (( and )) from FysForth, where it is used
as a method to catapult TO for array indexing.
E.g. 12 TO (( 3 )) mydata puts 12 into mydata[3] . I myself do
not object to ignoring this use of (( )) because it is better to
promote the FSL array / matrix notation.

I must point out that your reference implementation does not seem
to allow for nested comments, which can be useful to block out
larger parts of source code (which [if] [then] supports).

Win32Forth has a problem there too:

(( this should (( work )) ))
^^
Error(-13): )) is undefined

BTW: so does iForth :-(

-marcel

J Thomas

unread,
Jan 31, 2007, 6:59:40 PM1/31/07
to
On Jan 31, 3:43 pm, "Bruce McFarling" <agil...@netscape.net> wrote:

> I find it more natural to have a word that fits into the context of
> the non-Forth text.

I may be missing something here. It sounds like you're talking about
an esthetic thing, about the form of the word that switches between
text and Forth. We're talking about the exact same functionality and
the difference is a psychological one, something to do with how we
choose to look at it?

> I'm happy with the source starting with the word that is intended to
> put it into literate mode ... whether ---[ or <HTML>
>
> OTOH, there is no need to standardise either ---[ or <HTML> ... a
> collection of texts that use that can easily include those in its core
> toolkit.

I see a big variety of names for something that's essentially the same
functionality. If some name gets declared standard and more people use
it, that reduces the work of porting code.

It isn't necessary that everybody use the same name, but to the extent
that people do settle on one name it makes things a little easier for
porting.

J Thomas

unread,
Jan 31, 2007, 7:02:06 PM1/31/07
to
On Jan 31, 3:52 pm, m...@iae.nl (Marcel Hendrix) wrote:

> I must point out that your reference implementation does not seem
> to allow for nested comments, which can be useful to block out
> larger parts of source code (which [if] [then] supports).

Someone else commented on that too. Thank you. I'll fix it.

Ed

unread,
Jan 31, 2007, 9:17:55 PM1/31/07
to

"J Thomas" <jeth...@gmail.com> wrote in message news:1170193856.6...@h3g2000cwc.googlegroups.com...
> ...

> I don't care what name we use provided we can agree on one.
> I dislike using /* because there might be some use for files where
> Forth code is in C comments and vice versa.

Too similar to the forth operator */

Anything more than 2 characters becomes a nuisance. Alphabetic
characters raise issues of case. Using the same character e.g. (( is
prone to mistyping as well as not standing out enough.

Of the one's proposed (* is perhaps most recognizable even by
those that don't use Pascal. In forth, it could be said to build upon
the other comment character (

werty

unread,
Jan 31, 2007, 10:29:06 PM1/31/07
to

Thats why i improved Forth to be always
in the RUN mode and never in a COMPILE
mode . It is impossible to crash .
It allowed me to toss [State] and
many other DEFERED Words .
You DO NOT TELL Forth to
1) stop
2) slow down
3) defer
4) change the order of a DoCol
5 ) [ Compile]
6) use stack to "compile" Words

No matter what keys or Forth commands
you type , it wont lock up , even if you're
testing code !

Testing code uses the assembler
to create the OpCodes , so if you misspell
a nuemonic , it will assemble the closest
Match and start traceing code .
At High level , you dont know you are
using an assembler !

No excuses ...


m-coughlin

unread,
Jan 31, 2007, 11:01:36 PM1/31/07
to

Comments are more important than code. This is an idea that
Forth programmers cannot grasp. I know since I try to explain
this all the time and get nowhere.

Now that we have more powerful computers, we can write
program source that is meant to be understood by human beings
and the computing system can quickly skip thru it to execute the
computer code. Doing this when programs were written on punch
cards was very inconvenient. It made the source decks too big to
handle.

Bruce McFarling

unread,
Feb 1, 2007, 12:34:23 AM2/1/07
to
---[ On Jan 31, 6:59 pm, "J Thomas" <jethom...@gmail.com> wrote: ]---

> I may be missing something here. It sounds like you're talking about
> an esthetic thing, about the form of the word that switches between
> text and Forth. We're talking about the exact same functionality and
> the difference is a psychological one, something to do with how we
> choose to look at it?

(* and <HTML> do not have exactly the same functionality ... <HTML>
with friends allows you to view the same file as an html text that you
load as a Forth source.

(* and ---[ do not have exactly the same functionality ... ---[ allows
you to quote any snippet of Forth code in the text description, with
restriction on the contents of the code, simply by block indenting. (*
is always sensitive to *)

On the other hand, I'm a big fan of commenting, and if (* *)
encourages more commenting, I'm all for it.

David N. Williams

unread,
Feb 1, 2007, 7:52:21 AM2/1/07
to
Bruce McFarling wrote:
> [...]

>
> On the other hand, I'm a big fan of commenting, and if (* *)
> encourages more commenting, I'm all for it.

I much prefer (* *) over (( )).

-- David

J Thomas

unread,
Feb 1, 2007, 9:02:58 AM2/1/07
to
On Jan 31, 11:01 pm, m-coughlin <m-cough...@comcast.net> wrote:
> J Thomas wrote:

> > What is the difference between what you want and what I want?
>
> Comments are more important than code. This is an idea that
> Forth programmers cannot grasp. I know since I try to explain
> this all the time and get nowhere.
>
> Now that we have more powerful computers, we can write
> program source that is meant to be understood by human beings
> and the computing system can quickly skip thru it to execute the
> computer code. Doing this when programs were written on punch
> cards was very inconvenient. It made the source decks too big to
> handle.

I see a deep philosophical meaning here. But what operational
difference does it make in the routine to switch between comments and
code?

Jorge Acereda

unread,
Feb 1, 2007, 10:12:55 AM2/1/07
to Ed, comp.la...@ada-france.org
On 2/1/07, Ed <nos...@invalid.com> wrote:
>
> "J Thomas" <jeth...@gmail.com> wrote in message news:1170193856.6...@h3g2000cwc.googlegroups.com...
> > ...
> > I don't care what name we use provided we can agree on one.
> > I dislike using /* because there might be some use for files where
> > Forth code is in C comments and vice versa.
>
> Too similar to the forth operator */
>
> Anything more than 2 characters becomes a nuisance. Alphabetic

Not if those characters are the same. For me it's easier to type ((( than (*,
which in fact seems to be tailor-made for american keyboard layouts.

Bruce McFarling

unread,
Feb 1, 2007, 12:15:29 PM2/1/07
to
On Feb 1, 9:02 am, "J Thomas" <jethom...@gmail.com> wrote:
> I see a deep philosophical meaning here. But what operational
> difference does it make in the routine to switch between comments and
> code?

The main point of literate programming is that you never have to look
for the documentation of a source file ... its in the source file
itself.

With many languages, that requires special tools to mix and unmix the
documentation and the code, but defining a literate programming
wordset that allows Forth code to be embedded in its own documentation
is a one-screener.

Now, if the code is embedded in the documentation, then you do not
want to have the start of the Forth segment determined by some two-
character sequence defined in terms of the name of a block comment
word that will often lay pages further up in the file.

So the literate programming "skip the next stuff" words are not
defined as "opening and close delimiters". If you choose to make
<code> the "start interpreting" token, then you can simply define:

\ Skip interpreting until <code>
: </code> ( --- ) <HTML>

and in a case-sensitive forth implementation, you define:
\ the <html> tag is case insensitive
: <HTML> <html> ;

And with the "section title" word, ---[, if you want to have a
"chapter title" and "subsection title" to support automatic conversion
of the plaintext-layout file into html, then you define:

: ----[ ---[ ; \ chapter title
: --[ ---[ ; \ subsection title

The switching into Forth interpretation mode would always be when
there is a "\" comment starting in the first position of the line, and
the name of the section title word doing the work (when INCLUDED) of
passing over the documentation until the Forth code is found does not
matter. That means that the name of that Forth word is able to be
something that is useful for the documentation.

On the other hand, an *actual* comment block really is embedded in the
Forth code, and the definition of the word with a matching "reversed
delimiter" is a clear, intuitive way to show where the block ends.

werty

unread,
Feb 1, 2007, 3:15:31 PM2/1/07
to

NO ! NO ! No ! Do not agree on common
names , force them to use your No-Text G.U.I.

If they hack your code , it behoves them to
create new icons , as they are hacking !

The Paradigm , is they can't go back to text !

Impossible ! Try it you'll see what i mean .


You CAN argue English ,
but who argues the Textless ,
wavy line on a traffic sign :
~~~~~~~
( dangerous curve ahead )

everyone , even C prgrammers , slow
down and turn the wheel left , as they should .

My Forth has no text , expecially not Buzz Word
Text .


Ed Beroset

unread,
Feb 1, 2007, 4:14:28 PM2/1/07
to

I agree, not least because I'm entirely likely to include mathematical
expressions in code comments:

(( This word implements the function
f = (a+b)(c*(d+e))
for positive integer values of a,b,c,d,e
))

Ed

Bruce McFarling

unread,
Feb 1, 2007, 5:22:43 PM2/1/07
to
On Feb 1, 10:12 am, "Jorge Acereda" <jacer...@gmail.com> wrote:
> > Anything more than 2 characters becomes a nuisance. Alphabetic

> Not if those characters are the same. For me it's easier to type ((( than (*,
> which in fact seems to be tailor-made for american keyboard layouts.

But refer to Ed Beroset's comment on the particular pitfalls of
multiple ))'s, for those of us poor souls who may be commenting a
formula.


Bruce McFarling

unread,
Feb 1, 2007, 6:36:29 PM2/1/07
to
On Feb 1, 3:15 pm, "werty" <w...@swissinfo.org> wrote:
> Try it you'll see what i mean .

Sure. Where's the URL?

Though I admit, I have trouble coming up with names sometimes ...
designing an icon for each new word I define is a bit daunting.

werty

unread,
Feb 1, 2007, 8:12:09 PM2/1/07
to

-------------------------------------------------

No ,because you allready have an image

in your brain , of the code frag .

That image cant be shown here , nor

can it be "posted" , because would necessarily

be translated to your left brain , and that

would take 14 pages , and certainly be buggier

than 1 line of C code .


DONT translate it , just start doodling
with a pencil . draw images .

I must warn you ! You will fail , time
and time again , because your Left side
will fight you , like a

Trade Unionist !

Are you following this ?

we humans instinctively , MUST have
everything avail' quickly , in the Left
side , so we can speak it .
that means every intellegent thought
must allready be in the Left side , where
there is insuff' ability to DESCRIBE !!
Because it cant handle value judgements !

Your right side is the only productive
part of your brain , and if you train it,
you will become rich and enjoy a much
higher "peer" group .

Your left side is only trying to figure
how to SPEAK , what the Right side has
accurately mapped out .

Ill make it easy for you ,
lets redefine chars , but not even close
to what they are now , and the rule
is they must be very general VERBS .

> does NOT mean LT , we cant use
it because it would confuse ,
so instead , lets do

/ means the line above or
something above and NOT this line .
\ lower line or lower something ..
! caution , an error , store a number
# a structure a pattern , a array .


The objective is to redfine , so ppl
will NOT struggle nor argue on
the redefine . I dont want them
to stop for 1 milisecond , trying to
decipher it , so it must be totaly
new definition .

Example , if i used ^ to mean [UP]
what would i use for [down] !

No good ...

General , so one can suffix to
narrow the "range"

[ / line 32 ]

noice how this takes the burden
off the Left side , it must read , present
line to figure if line 32 is
ABOVE or is BELOW the present line .

This is how you learn to program ,
with your right side , by turning OFF
or preventing the left side from
"calculating" anything .

Left side is your worst enemy , it wants
to become a college proff and make $28,000
a year , while your
Right side "see's" a picture of people making $$ ,
this image has linking to show you all the closed
doors , in making that $$ .

Thus all successful ppl , use their R side .
and the left side can "explain" why he
can't get a job .
R side has NO excuses, only plans

I am a Rich E.E., programmer ,
developer , cause i trained
my R side to toss excuses .

Wanna join a "no-excuses" peer
group ?


Stephen Pelc

unread,
Feb 2, 2007, 6:02:04 AM2/2/07
to
On 30 Jan 2007 13:50:56 -0800, "J Thomas" <jeth...@gmail.com> wrote:

>15.6.2.xxxs (( "comments" TOOLS EXT
>
> Compilation: Perform the execution semantics given below.
>
> Execution: ( "ccc" -- )
>
> Parse text until the word ))
> is found or until the current parse area cannot be refilled.
> Discard the found )) string. (( is an immediate word.
>
> An ambiguous condition exists if the word )) is not found and the
>parse area cannot be refilled.

I presume that the phrase "the word ))" means that it is white-space
delimited. This matches the MPE implementation, which has 15-20 years
of history.

Stephen


--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Stephen Pelc

unread,
Feb 2, 2007, 6:05:44 AM2/2/07
to

Don't bother. Non-nestable supports 95+% of the problem.
"0 [if] ... [then]" fixes the rest.

Stephen Pelc

unread,
Feb 2, 2007, 6:07:33 AM2/2/07
to
On 1 Feb 2007 14:22:43 -0800, "Bruce McFarling" <agi...@netscape.net>
wrote:

Please note that by convention the )) is white space delimited,
which is rare in formulae.

J Thomas

unread,
Feb 2, 2007, 7:57:07 AM2/2/07
to
On Feb 2, 6:07 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On 1 Feb 2007 14:22:43 -0800, "Bruce McFarling" <agil...@netscape.net>

> wrote:
>
> >On Feb 1, 10:12 am, "Jorge Acereda" <jacer...@gmail.com> wrote:
> >> > Anything more than 2 characters becomes a nuisance. Alphabetic
>
> >> Not if those characters are the same. For me it's easier to type ((( than (*,
> >> which in fact seems to be tailor-made for american keyboard layouts.
>
> >But refer to Ed Beroset's comment on the particular pitfalls of
> >multiple ))'s, for those of us poor souls who may be commenting a
> >formula.
>
> Please note that by convention the )) is white space delimited,
> which is rare in formulae.

By "whitespace" do you mean blank or blank|tab|cr|control-character|
etc?

It isn't that rare for a commented formula to end with )) or ))) etc.

For that matter I sometimes include blanks in commented formulas
because that makes them easier ofr me to read.

J Thomas

unread,
Feb 2, 2007, 7:59:22 AM2/2/07
to
On Feb 2, 6:05 am, stephen...@mpeforth.com (Stephen Pelc) wrote:

> On 31 Jan 2007 16:02:06 -0800, "J Thomas" <jethom...@gmail.com> wrote:
>
> >On Jan 31, 3:52 pm, m...@iae.nl (Marcel Hendrix) wrote:
>
> >> I must point out that your reference implementation does not seem
> >> to allow for nested comments, which can be useful to block out
> >> larger parts of source code (which [if] [then] supports).
>
> >Someone else commented on that too. Thank you. I'll fix it.
>
> Don't bother. Non-nestable supports 95+% of the problem.
> "0 [if] ... [then]" fixes the rest.

You have lots of code with (( and changing its meaning on you might
break some of it.

So if we wind up with a standard nestable multiline comment it should
have a different name.

Andreas Kochenburger

unread,
Feb 2, 2007, 8:05:09 AM2/2/07
to
"J Thomas" <jeth...@gmail.com> schrieb im Newsbeitrag
news:1170421162.4...@m58g2000cwm.googlegroups.com...

> So if we wind up with a standard nestable multiline comment it should
> have a different name.

(* .. *)
or
\\ .. \\ (as a personal matter of taste I like this one more)

would be fine with me


David N. Williams

unread,
Feb 2, 2007, 9:42:47 AM2/2/07
to

Without too much thought, probably okay with me, too.

How about leaving it up to the user, and proposing instead a
defining word (maybe JET already has a DOES> reference version?)
that would be some variation on

: comment: ( "introducer.name" terminator.s -- )
(
Define a word named by the next word in the parse area, which
skips text across lines, and leaves the input stream positioned
just after the ANS Forth string terminator.s, or at the end of
the file if terminator.s is not found.
)
... ;

Syntax example:

s" ))" comment: ((

Or make it an entirely nonparsing word with syntax:
s" ((" s" ))" comment

Or one with entirely parsing syntax:

comment: (( ))
comment: \\ \\

I personally prefer the entirely parsing version, with the
entirely nonparsing version as runner-up.

Then it would be easy to have multiple comment delimiters in the
same document. I don't know what would be the best name for
COMMENT: or COMMENT ...

-- David

Stephen Pelc

unread,
Feb 2, 2007, 10:04:33 AM2/2/07
to
On 2 Feb 2007 04:57:07 -0800, "J Thomas" <jeth...@gmail.com> wrote:

>By "whitespace" do you mean blank or blank|tab|cr|control-character|
>etc?

blank|tab|cr|control-character|...

Bernd Paysan

unread,
Feb 2, 2007, 10:13:55 AM2/2/07
to
Stephen Pelc wrote:
> I presume that the phrase "the word ))" means that it is white-space
> delimited. This matches the MPE implementation, which has 15-20 years
> of history.

I won't have a problem with nesting, white-space delimited
multiline-comments, but my implementation is different, and doesn't need
white space delimiters (however, it also doesn't nest, similar to C's /*
*/). I have three *-containing multiline comments, (* *), /* */ and \* *\

: ?refill source nip >in @ = IF refill 0= ELSE false THEN ;
: parse* parse + source + over <> swap 1- c@ '* = ;
: _*) BEGIN ') parse* and ?EXIT ?refill UNTIL ;
: _*/ BEGIN '/ parse* and ?EXIT ?refill UNTIL ;
: _*\ BEGIN '\ parse* and ?EXIT ?refill UNTIL ;
: Com: Create ' A, immediate DOES> perform ;
Com: (* _*) Com: /* _*/ Com: \* _*\

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

J Thomas

unread,
Feb 2, 2007, 10:20:17 AM2/2/07
to
On Feb 2, 9:42 am, "David N. Williams" <willi...@umich.edu> wrote:

> How about leaving it up to the user, and proposing instead a
> defining word (maybe JET already has a DOES> reference version?)
> that would be some variation on
>
> : comment: ( "introducer.name" terminator.s -- )

We could do that. And it needs no standardisation whatsoever.

The advantage I see to a standard version is that to the extent people
use it, the code will port without having to be touched at all. It's
one less thing to worry about.

But with a defining word for multiline comments it would at least be
easy to deal with idiosyncratic commenting.

> Or make it an entirely nonparsing word with syntax:
> s" ((" s" ))" comment
>
> Or one with entirely parsing syntax:
>
> comment: (( ))
> comment: \\ \\
>
> I personally prefer the entirely parsing version, with the
> entirely nonparsing version as runner-up.

If it's a tool to deal with the crazy things other people do, I'd
rather the ending part at least be parsed first. Just in case they
want to have spaces in it. I can have it last and parse to the end of
the line, but there's always the chance I'll need to use a text editor
that lets me have spaces at the end of the line.

These are all minor rare aggravations, though, and for code that isn't
standardised but available to anybody to modify as they see fit it
doesn't matter much.

Again though, when multiline comments follow some standard format they
don't cause any aggravation at all. It's one less thing to deal with.

J Thomas

unread,
Feb 2, 2007, 11:36:35 AM2/2/07
to
RfD -- ((

February 2, 2007
* Third Draft *

Significant Differences from 2nd Version
============================
Name change from (( to (*

Nesting, (* (* *) *) works.

Rationale
=========

Problem
-------
Most Forth users find it useful to have a block comment -- a comment
command that covers multiple lines. There are many names for this
because there is no standard.

Names include (( (* /* ( etc.

One standard portable approach is 0 [IF] ..... [THEN] This works on
every standard Forth that implements [IF] [THEN] but it is ugly. It's
easy to rename 0 [IF] to, say, [DOCUMENTATION] and still end with
[THEN] . This solution is not generally accepted as shown by the
existence and use of so many alternatives.


Current Practice
----------------

Many Forth systems provide this capability. MPE's Forths, Win32Forth,
and FPC have used the name (( for a version that does not nest, but
several commenters prefer a standard commenting command that does
nest.


Solution
--------

Agree on a common name. The more Forth systems that provide a standard
name, the more code will use it and the less trouble it will be
porting that code. Code that uses some other name will still run on
every system that supports it and software can be easily written to
support it elsewhere, but to the extent we use a standard name that
bother can be avoided.


Proposal
========

15.6.2.xxxs (* "comments" TOOLS EXT

Compilation: Perform the execution semantics given below.

Execution: ( "ccc" -- )

Parse text until the whitespace-delimited string
*)


is found or until the current parse area cannot be refilled.

Discard the found *) string. (* commands are nestable.
(* is an immediate word.

An ambiguous condition exists if the word *) is not found and the


parse area cannot be refilled.


Typical use
-----------

(* This is a comment, it requires supporting statements.
These statements can go on their own lines.
There might be lots of them. *)

(* ***************************************************************
People have lots of styles for comenting.
They like to make their comments stand out as obvious comments.
*************************************************************** *)

(* Sometimes people want to increase the range of their comments.

: BUGGY-CODE 0 >R ;
(* What was I thinking when I wrote this? *)

: MORE-BUGGY-CODE DO :
(* What a headache. I must have been having fun, why can't I remember?
*)

Better comment out this whole section. *)


Reference Implementation
------------------------

: MAYBE-REFILL ( S: -- flag ) \ refill if at end of line, 0 if
can't
SOURCE NIP >IN @ > DUP 0= IF DROP REFILL THEN ;

: (* ( S: -- ) \ multi-line comment, ended by *)
BEGIN
BL WORD COUNT 2DUP S" *)" COMPARE WHILE
S" (*" COMPARE 0= IF RECURSE THEN
MAYBE-REFILL WHILE
REPEAT
0 0 CR ." Your system can do anything at this point and still be
a standard system."
THEN 2DROP ; IMMEDIATE

BL WORD COUNT can be replaced by PARSE-NAME when the time comes.

It would not be difficult to make a CREATE DOES> word which defines
new words like (* with new ending strings different from *) . I may do
that.


Test Cases
----------

(* CR .( Don't print this.) *) CR .( Print first comment )

(* CR .( Don't print this either. )
CR .( And don't print this. ) *) CR .( Print second comment )

: foo (* CR .( Don't print while compiling )
CR .( Or the second line. ) *) CR ." Print third comment " ;
foo
(* CR .( Don't print another ) (*
CR .( Don't print nested. )
*) CR .( Still don't print ) *) CR .( Print fourth and last comment )

Remarks
-------

I don't care what name we use provided we can agree on one.
I dislike using /* because there might be some use for files where

Forth code is in C comments and vice versa. Also */ is a Forth word.

(( has been in use for many years by MPE and by Win32Forth as a non-
nestable multiline comment. A nestable version should have a different
name. Also, (( is used in iForth for something completely different.

Other suggestions for names: \\ --- ( in both cases, the next
instance toggles rather than nests)

Thanks
------
Thanks to Robert Epprecht, George Hubert, Michael Hore, Bruce
McFarling, David N. Williams, Marcel Hendrix, Ed Beroset, Stephen
Pelc, and Michael Coughlin..

Comments
========

Coos Haak

unread,
Feb 2, 2007, 12:29:51 PM2/2/07
to
Op Fri, 02 Feb 2007 14:42:47 GMT schreef David N. Williams:

<snip>


> Or make it an entirely nonparsing word with syntax:
> s" ((" s" ))" comment

Won't always work, there are (still ?) ISO Forths that provide only one
location to hold S"-strings in interpret state ;-(

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

rickman

unread,
Feb 2, 2007, 12:43:56 PM2/2/07
to
On Feb 2, 11:36 am, "J Thomas" <jethom...@gmail.com> wrote:
> RfD -- ((
>
> February 2, 2007
> * Third Draft *
>
> Significant Differences from 2nd Version
> ============================
> Name change from (( to (*
>
> Nesting, (* (* *) *) works.
...snip...
> Comments
> ========

One post here mentioned internesting of Forth comments and C comments
so that both languages can exist within the other's comment fields.
Using *) for a closing delimiter in Forth might create problems with C
conventions such as (int *) other_var. Perhaps another pair of
delimiters should be used. I don't know that this is a *major*
concern regarding block comments, but I think it is worth
consideration.

I have two thoughts on the matter. One is that block comment
delimiters don't have to be all that short considering that they are
not typed on every line. So a longer delimiter such as ----{ }----
or whatever had been suggested should not be very onerous and should
help to prevent any overlap with constructs not yet devised or from
other languages.

The other is do we even need block comment delimiters? One of the
things I have given some thought to as I learn about forth is how Jeff
Fox has explained some of the advanced work they have done. When they
come across something that cam be moved from run time to compile time
or from compile time to edit time, they do it. There are not many
editors that are not capabile of using line comment delimiters to
comment out a block of text. I use this myself and have not found it
to be a burden. So why are these words needed? If you add them, make
sure they don't do any harm (such as making it hard to embed C source
in a Forth file or vice versa).

BTW, I do think that if you add block comments, it is important to
make them nestable. The main reason I have used block comments in the
past is to take out sections of code. If they aren't nestable and the
code is already using these, it don't work!

Marcel Hendrix

unread,
Feb 2, 2007, 12:15:57 PM2/2/07
to
"J Thomas" <jeth...@gmail.com> writes Re: Request for Discussion -- (( and multiline comments

> On Feb 2, 9:42 am, "David N. Williams" <willi...@umich.edu> wrote:

[..]


> Again though, when multiline comments follow some standard format they
> don't cause any aggravation at all. It's one less thing to deal with.

Exactly. Please don't give up now. Standardization is never easy.

You wouldn't have started this thread if it was *really* completely
stress-free to port multiline comments.

-marcel

Marcel Hendrix

unread,
Feb 2, 2007, 12:28:56 PM2/2/07
to
Coos Haak <chf...@hccnet.nl> writes Re: Request for Discussion -- (( and multiline comments

> Op Fri, 02 Feb 2007 14:42:47 GMT schreef David N. Williams:

> <snip>
>> Or make it an entirely nonparsing word with syntax:
>> s" ((" s" ))" comment

> Won't always work, there are (still ?) ISO Forths that provide only one
> location to hold S"-strings in interpret state ;-(

RENAME-FILE FILE EXT
( c-addr1 u1 c-addr2 u2 -- ior )
Rename the file named by the first character string specified by c-addr1
u1 to the name in the second character string. ior is the
implementation-defined I/O result code.

An ISO Forth that doesn't implement RENAME-FILE , or only with
compiled strings? That way one can't debug from the command line.

I guess that 'feature' isn't too loudly advertized, then :-)

-marcel

J Thomas

unread,
Feb 2, 2007, 2:33:11 PM2/2/07
to
On Feb 2, 12:43 pm, "rickman" <gnu...@gmail.com> wrote:

> One post here mentioned internesting of Forth comments and C comments
> so that both languages can exist within the other's comment fields.
> Using *) for a closing delimiter in Forth might create problems with C
> conventions such as (int *) other_var. Perhaps another pair of
> delimiters should be used. I don't know that this is a *major*
> concern regarding block comments, but I think it is worth
> consideration.

Good idea. (* is the name that's gotten the most support so far, but
it's still only a few people. You coudl suggest another name.

> I have two thoughts on the matter. One is that block comment
> delimiters don't have to be all that short considering that they are
> not typed on every line. So a longer delimiter such as ----{ }----
> or whatever had been suggested should not be very onerous and should
> help to prevent any overlap with constructs not yet devised or from
> other languages.

That's true. I didn't want ----[ because Bruce said it has other side
effects that I'm not proposing. Of course, we could propose to add
those effects....

> The other is do we even need block comment delimiters?

My concern is that I see code that does use block comments, and code
from different people uses different delimiters. It's an irritant,
though not a giant one. To the extent that people agree on a single
delimiter (or a short list) that irritant is removed.

If you're right that we don't need block comments at all, and if we
have a standard block comment command that can be written in standard
Forth, then programmers can simply not use it. Then implementors will
be stuck putting a feature in their languages that nobody uses, a bad
thing. Only, they can have standard systems if they do as little as
put the code for the multiline-comment command in their documentation!
It isn't a giant imposition on them, either.

It might be that this proposal wastes my time and the time of people
who read and comment about it. But I don't think the drawbacks go much
beyond that. In the best case we get one less little glitch when we
port code from other people. In the worst case nothing happens and we
waste the time of a few people who thought that something might
happen.

> BTW, I do think that if you add block comments, it is important to
> make them nestable. The main reason I have used block comments in the
> past is to take out sections of code. If they aren't nestable and the
> code is already using these, it don't work!

Agreed. The proposal now reflects that, and if someone wants to argue
that they shouldn't be nestable then we can argue it out.

Bruce McFarling

unread,
Feb 2, 2007, 2:44:04 PM2/2/07
to
On Feb 2, 12:28 pm, m...@iae.nl (Marcel Hendrix) wrote:
> RENAME-FILE FILE EXT
> ( c-addr1 u1 c-addr2 u2 -- ior )
> Rename the file named by the first character string specified by c-addr1
> u1 to the name in the second character string. ior is the
> implementation-defined I/O result code.

> An ISO Forth that doesn't implement RENAME-FILE , or only with
> compiled strings? That way one can't debug from the command line.

> I guess that 'feature' isn't too loudly advertized, then :-)

Of course you can debug from the command line, you just have to use an
implementation-specific way to do it. T" ..." or " ..." or whatever.

And in normal use the existing file name is stored somewhere, so S" is
not needed to name it.


Bruce McFarling

unread,
Feb 2, 2007, 2:48:00 PM2/2/07
to
On Feb 2, 7:59 am, "J Thomas" <jethom...@gmail.com> wrote:
> So if we wind up with a standard nestable multiline comment it should
> have a different name.

(* *)

If someone wants to start a section of forth code with a a block
comment that intersperses the block comments used below and more
commentary on how they fit together ... why, I'm perfectly happy if my
preferred block comment naming supports that.

Bruce McFarling

unread,
Feb 2, 2007, 2:56:22 PM2/2/07
to
On Feb 2, 6:07 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> Please note that by convention the )) is white space delimited,
> which is rare in formulae.

But the )) in JETs code did not seem to be ... parse for a ")", then
check if it is followed by ") "

... and if there is ANY implementation of (( ... )) that permits it to
not be white space delimited, in a closer analogue to ( ...), then
standardizing that )) *must* be white space delimited is breaking some
existing code somewhere.

I see a nestable (* *) as being a loop of PARSE-WORD's which then test
the word found for being *), in which case EXIT, or (*, in which case
RECURSE. So that would be naturally a white-space delimited *) as a
delimiter.


Bruce McFarling

unread,
Feb 2, 2007, 3:09:26 PM2/2/07
to
On Feb 2, 2:33 pm, "J Thomas" <jethom...@gmail.com> wrote:
> That's true. I didn't want ----[ because Bruce said it has other side
> effects that I'm not proposing. Of course, we could propose to add
> those effects....

That should not be a reason not to use it if people wanted to ... I
just like the way that:

---[ The Display Subsystem ]--------------------[ 17May2007 ]---

looks ... where, obviously, ]--- is where the header line ends, and
where the rest of the block comment starts! I am experimenting with
plaintext layout that converts easily to html (and, with restrictions
on the html, conversely), I prefer to have the plaintext layout be
something that I like the look of.

But its not in any published code yet, so I can easily switch to
something else.

Just please don't use /( because I still hope to get back around to
SLIDERS and I really like that way that looks for starting a substring
match inside a string match.

If *) is problematic for interspersing C and Forth (not something I
would do, but still ...), then

(-- and --) would give an alternative style of "box drawing".

Indeed, it would be even cleared for interspersing C and Forth, with
------- being box drawing for a Forth comment and ******* being box
drawing for a C comment.


rickman

unread,
Feb 2, 2007, 3:43:01 PM2/2/07
to

That is on the right track, but has a similar problem, "--)" can
occur in C as part of (foo--). I don't see "**" anywhere in the C
reference. How about (** and **)? Or maybe (== and ==)? Would -
{ and }- make people happy.

Actually the idea of mixing Forth and C in one file that can be used
under either langage is **very** appealing to me. It is a good way to
be able to move between the two languages using one as a rapid
prototyping tool and the other as the formal software deliverable...
which do you think would be which? ;^)

Anyone see a problem with -{ and }- other than the fact that you have
to use the SHIFT key? I guess C can be written without an intervening
space which means }- could occur?


Bruce McFarling

unread,
Feb 2, 2007, 5:33:28 PM2/2/07
to
On Feb 2, 3:43 pm, "rickman" <gnu...@gmail.com> wrote:
> That is on the right track, but has a similar problem, "--)" can
> occur in C as part of (foo--). I don't see "**" anywhere in the C
> reference. How about (** and **)? Or maybe (== and ==)? Would -
> { and }- make people happy.

** looks like a pointer to a pointer to me, but I don't recall whether
that is just in use, or whether you can do that in a declaration with
*(*) ... its been a long time since I did any C-coding.

==) should be safe ... its a binary operator, so its defined so that
there must be something between a == and a )

(== ==) inherits the same argument as (-- --) in terms of comment
boxing.

/* *********************************
* Obviously this is a C block comment
* ...
* ...
********************************* */

(== ===================
|| Obviously this is a Forth block comment
|| (== with a nested comment ==)
|| ...
================== ==)

Indeed, one who wanted to intersperse Pascal and Forth or Modula-2 and
Forth might not want (* *) either!

> Anyone see a problem with -{ and }- other than the fact that you have
> to use the SHIFT key? I guess C can be written without an intervening
> space which means }- could occur?

That would be the problem ... better to use a binary operator like ==
so you know that something has to lay between it and ( or ).

With { is used in locals and } is a common operator in arrays, I'd
rather leave { } alone.

I still prefer (* *), but the (-- --) or (== ==) is also OK by me.


rickman

unread,
Feb 2, 2007, 7:25:04 PM2/2/07
to
On Feb 2, 5:33 pm, "Bruce McFarling" <agil...@netscape.net> wrote:
> (== ==) inherits the same argument as (-- --) in terms of comment
> boxing.
>
> /* *********************************
> * Obviously this is a C block comment
> * ...
> * ...
> ********************************* */
>
> (== ===================
> || Obviously this is a Forth block comment
> || (== with a nested comment ==)
> || ...
> ================== ==)
>
> That would be the problem ... better to use a binary operator like ==
> so you know that something has to lay between it and ( or ).
>
> With { is used in locals and } is a common operator in arrays, I'd
> rather leave { } alone.

How is } used in arrays? I know { and } are used for blocks, but what
else?

> I still prefer (* *), but the (-- --) or (== ==) is also OK by me.


Yeah, I like (== and ==). In mixed mode it would be


/* (== **************************************************** ==)
Forth code goes here,
forth would also have to define "/*" to be a no-op.
(== **********************************************************/

C code goes here

/********************************************************** ==)

More forth code

(== **********************************************************/

More C code

/* The end of the final forth comment would be the EOF */

Not as pretty as I would like, but it would work.

Ed

unread,
Feb 2, 2007, 9:40:32 PM2/2/07
to

"J Thomas" <jeth...@gmail.com> wrote in message news:1170444791.9...@l53g2000cwa.googlegroups.com...

> On Feb 2, 12:43 pm, "rickman" <gnu...@gmail.com> wrote:
>
> > One post here mentioned internesting of Forth comments and C comments
> > so that both languages can exist within the other's comment fields.
> > Using *) for a closing delimiter in Forth might create problems with C
> > conventions such as (int *) other_var. Perhaps another pair of
> > delimiters should be used. I don't know that this is a *major*
> > concern regarding block comments, but I think it is worth
> > consideration.
>
> Good idea. (* is the name that's gotten the most support so far, but
> it's still only a few people. You coudl suggest another name.

IMO it's better to choose a name one likes and works well in the
Forth environment rather than avoiding all possible conflict.
The few percent of cases where conflict arises can be worked
around with \ or 0 [IF]..[THEN].

I imagine that C and Pascal had to make similar compromises.
It's also a good idea to rank one's conflicts. Which are you
more likely to use in comments - math, C, Pascal, other etc

Bruce McFarling

unread,
Feb 2, 2007, 11:19:01 PM2/2/07
to
On Feb 2, 7:25 pm, "rickman" <gnu...@gmail.com> wrote:
> > With { is used in locals and } is a common operator in arrays, I'd
> > rather leave { } alone.

> How is } used in arrays? I know { and } are used for blocks, but what
> else?

Dereference. } vector dereference, }} rectangular matrix dereference.

And then things that take the same stack input as } are by convention
given names starting with }, and those with the same stack input as }}
are by convention given names starting with }}.

The reason it doesn't conflict with { } for locals is that there is no
{ array word, just the convention of ending the name of an vector as,
eg, Y{ and a two-dimensional matric as, eg, IO{{


> > I still prefer (* *), but the (-- --) or (== ==) is also OK by me.
>
> Yeah, I like (== and ==). In mixed mode it would be
>
> /* (== **************************************************** ==)

: /* (== ;

and then every switch can be

/* ********************************************************* ==)

and

(== **********************************************************/

or even:

/* *** TO FORTH ********************************************** ==)

Forth code

(== ** TO C **************************************************/

C code

/* *** TO FORTH ********************************************** ==)

Adam Warner

unread,
Feb 3, 2007, 4:51:27 AM2/3/07
to
On Fri, 02 Feb 2007 09:43:56 -0800, rickman wrote:

> On Feb 2, 11:36 am, "J Thomas" <jethom...@gmail.com> wrote:
>> RfD -- ((
>>
>> February 2, 2007
>> * Third Draft *
>>
>> Significant Differences from 2nd Version
>> ============================
>> Name change from (( to (*
>>
>> Nesting, (* (* *) *) works.
> ...snip...
>> Comments
>> ========
>
> One post here mentioned internesting of Forth comments and C comments
> so that both languages can exist within the other's comment fields.
> Using *) for a closing delimiter in Forth might create problems with C
> conventions such as (int *) other_var. Perhaps another pair of
> delimiters should be used. I don't know that this is a *major*
> concern regarding block comments, but I think it is worth
> consideration.

(Just raising an idea that came to me while lurking in c.l.f.)

Here's a potential solution that preserves the new syntax: The number of
starting comment asterisks must match the number of ending comment
asterisks.

So while "typical use" still applies:

(* This is a comment, it requires supporting statements.
These statements can go on their own lines.
There might be lots of them. *)

(* ***************************************************************
People have lots of styles for commenting.


They like to make their comments stand out as obvious comments.
*************************************************************** *)

The last comment could be rewritten as:

(*****************************************************************
People have lots of styles for commenting.


They like to make their comments stand out as obvious comments.

*****************************************************************)

Only the sequence
*****************************************************************)
will terminate the comment. In particular, neither (int *) other_var nor
(int ****************************************************************)
other_var will end the block comment.

(Relurking)

Regards,
Adam

Anton Ertl

unread,
Feb 3, 2007, 7:46:00 AM2/3/07
to
"J Thomas" <jeth...@gmail.com> writes:
>Proposal
>========
>
>15.6.2.xxxs (* "comments" TOOLS EXT
>
> Compilation: Perform the execution semantics given below.
>
> Execution: ( "ccc" -- )
>
> Parse text until the whitespace-delimited string
> *)
> is found or until the current parse area cannot be refilled.
> Discard the found *) string.

That describes a non-nesting (* comment syntax. iForth implements
that. BTW, maybe you should also change the Subject of the postings
to reflect the word name change.

> (* commands are nestable.

That is in contradiction to the description above. It is also quite
imprecise; e.g., is there any requirement on delimiters around "(*"?

BTW, for those people worrying about nesting C, Forth or other languages:

char *a="consider that any string can occur in C";
s" and in Forth as well, without respect for nesting: (* */ (( etc."

>BL WORD COUNT can be replaced by PARSE-NAME when the time comes.

The time is already here.

>It would not be difficult to make a CREATE DOES> word which defines
>new words like (* with new ending strings different from *) . I may do
>that.

IMO (* is already unnecessary: I use \ instead, and we have ( ...) and
0 [IF}...[THEN] as well. A word for defining custom comment
delimiters seems excessive, and the main effect would be to reduce
readability.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
Forth-Tagung 2007: http://www.complang.tuwien.ac.at/anton/forth-tagung07/
EuroForth 2007: September 13-16, 2007

Stephan Becher

unread,
Feb 3, 2007, 9:35:47 AM2/3/07
to

"Bruce McFarling" <agi...@netscape.net> schrieb im Newsbeitrag
news:1170445444.7...@q2g2000cwa.googlegroups.com...

pad s" old.txt" tuck pad swap cmove s" new.txt" rename-file

is a pretty awful workaround, but it works on all ANS systems with the
file-access word set. I guess almost everyone falls at least once into the
trap of using

s" old.txt" s" new.txt" rename-file

on systems that provide only one location for interpreter strings. It might
be worth considering changing the standard to require at least two
locations.

Regards,
Stephan


Bruce McFarling

unread,
Feb 3, 2007, 10:12:28 AM2/3/07
to
On Feb 2, 7:25 pm, "rickman" <gnu...@gmail.com> wrote:
> Yeah, I like (== and ==). In mixed mode it would be

What I said before was daft. Its

: /*** ;
: ***/ ;

Start of file: /*** (== ***/
End of file: /*** ==) ***/

/***************************************************************
* ... C block comment, creation date, dependencies ... all the normal
stuff
* ...
* ...
***************************************************************/
... C code here if desired
/********************************************************* ==)
... Forth code
(== ****************************************************/
... C code
/********************************************************* ==)
... (and so on)

... Forth code
(== ****************************************************/
... C code here if desired
/*** ==) ***/

No dangling block comment at the EOF.

Doug Hoffman

unread,
Feb 3, 2007, 10:21:03 AM2/3/07
to
On Feb 3, 7:46 am, a...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> BTW, for those people worrying about nesting C, Forth or other languages:
>
> char *a="consider that any string can occur in C";
> s" and in Forth as well, without respect for nesting: (* */ (( etc."

Yes. I believe that worrying about compatibility with other
programming languages might best be a low priority.


> IMO (* is already unnecessary: I use \ instead, and we have ( ...) and
> 0 [IF}...[THEN] as well.

\ only works for one line. So using \ for long blocks of text require
the text processor to behave in a certain way. Not all of them do.

One advantage of block comment words like (* ... *) over 0 [if] ...
[then] is when doing a LOCATE. Not all Forths store the file offsets
of each definition. So when performing a LOCATE without an offset
(i.e., search from the beginning of the file) it is much easier to
skip over (* ... *) than 0 [if] or 0 [if] to avoid hits on
comments.

I observe that several Forths already use (* ... *): Win32Forth,
Carbon MacForth, and PowerMops. There may be more. Other Forths use
the equivalent of (* .. *), e.g., (( ... )). Apparently there are
plenty of people that find these words useful. I am one of them.
Besides, I'd much rather type (* ... *) than 0 [if] ... [then]

Bruce McFarling

unread,
Feb 3, 2007, 10:22:58 AM2/3/07
to
On Feb 3, 9:35 am, "Stephan Becher" <stephan.remove-this.bec...@t-
online.de> wrote:

> pad s" old.txt" tuck pad swap cmove s" new.txt" rename-file

> is a pretty awful workaround.

So you are saying that PAD" is:

: PAD" ( IN: text" | -- ) PAD S" TUCK PAD SWAP CMOVE ;

Why is PAD" a pretty awful workaround? Seems perfectly reasonable to
me.

PAD" old.txt" S" new.txt" RENAME-FILE

But having a second string buffer handy is one reason that I've always
defined T" as a "write-over" stack using an explicit TDUP.

m-coughlin

unread,
Feb 3, 2007, 11:17:48 AM2/3/07
to
Bruce McFarling wrote:
>
> On Feb 1, 9:02 am, "J Thomas" <jethom...@gmail.com> wrote:
> > I see a deep philosophical meaning here. But what operational
> > difference does it make in the routine to switch between
> > comments and code?
>
> The main point of literate programming is that you never have
> to look for the documentation of a source file ... its in the
> source file itself.
>
> With many languages, that requires special tools to mix and
> unmix the documentation and the code, but defining a literate
> programming wordset that allows Forth code to be embedded in
> its own documentation is a one-screener.

Literate programming? Phooie! What does that mean? Start out
thinking that source code needs to be read by human beings. Then
the first lines of a program will always be plain text telling
you what the program is supposed to do. After you've explained
yourself you can switch to Forth code. So you need a Forth word
to start interpreting/compiling Forth code the same way you need
a Forth word to switch to a Forth machine code assembler.

When the system starts reading Forth source, it interprets
it as Forth words. This is the wrong way to start. I'm
contending a Forth system should start reading the source as
being comments until told otherwise. Since I have never used a
system that acted that way I don't know what the disadvantages
might be.

> Now, if the code is embedded in the documentation, then you
> do not want to have the start of the Forth segment determined
> by some two-character sequence defined in terms of the name
> of a word that will often lay pages further up
> in the file.
>
> Now, if the code is embedded in the documentation, then you
> do not want to have the start of the Forth segment determined
> by some two-character sequence defined in terms of the name
> of a block comment word that will often lay pages further up
> in the file.

Right. A two-character sequence will not indicate that you
are using modern Forth which has turned into a programming
language that is easy to read. But what is this business about
"block comment" and "pages further up in the file"? Are you
thinking of Forth block code that loads numbered screens? That
is the spaghetti screen problem. Bad style. A problem that needs
further research to solve.

> So the literate programming "skip the next stuff" words are
> not defined as "opening and close delimiters". If you choose
> to make <code> the "start interpreting" token, then you can
> simply define:
>
> \ Skip interpreting until <code>
> : </code> ( --- ) <HTML>
>
> and in a case-sensitive forth implementation, you define:
> \ the <html> tag is case insensitive
> : <HTML> <html> ;
>
[snip]

Now you've lost me. A discussion of how to write program
code clearly should be clearly written. The subject is a matter
of style, the sort of thing English teachers and editors
complain about. Its not something you can solve by making up
rules or making more new Forth words. Forth is about using few
words. Unfortunately this style of writing cannot be applied in
the same way to writing documentation.

--
Michael Coughlin m-cou...@comcast.net Cambridge, MA USA

Bruce McFarling

unread,
Feb 3, 2007, 11:37:39 AM2/3/07
to
On Feb 3, 11:17 am, m-coughlin <m-cough...@comcast.net> wrote:
> Bruce McFarling wrote:

> > The main point of literate programming is that you never have
> > to look for the documentation of a source file ... its in the
> > source file itself.

> Literate programming? Phooie! What does that mean? Start out


> thinking that source code needs to be read by human beings. Then
> the first lines of a program will always be plain text telling
> you what the program is supposed to do. After you've explained
> yourself you can switch to Forth code. So you need a Forth word
> to start interpreting/compiling Forth code the same way you need
> a Forth word to switch to a Forth machine code assembler.

How does a Forth word to start interpreting/compiling every get
interpreted, if you are not interpreting when you start? How does it
execute? You haven't started interpreting/compiling yet.

Literate programming means that the source intended to be shared by
the computer system and human beings, and so the beginning of the file
*is* plain text explaining what the program is supposed to do.

The computer doesn't need to see that, so an executable word that
says, "ignore this stuff until I start talking Forth" is all that is
required. However, it is preferable if it is an integral part of the
text layout.

> > Now, if the code is embedded in the documentation, then you
> > do not want to have the start of the Forth segment determined
> > by some two-character sequence defined in terms of the name
> > of a block comment word that will often lay pages further up
> > in the file.

> Right. A two-character sequence will not indicate that you
> are using modern Forth which has turned into a programming
> language that is easy to read. But what is this business about
> "block comment" and "pages further up in the file"? Are you
> thinking of Forth block code that loads numbered screens? That
> is the spaghetti screen problem. Bad style. A problem that needs
> further research to solve.

Pages, as in, "page up", as in, "read this and see what you think". By
pages up I mean pages up. If I said "pages up" with respect to a
novel, you'd understand it ... same thing. "back there somewhere out
of sight".

> Now you've lost me. A discussion of how to write program
> code clearly should be clearly written. The subject is a matter
> of style, the sort of thing English teachers and editors
> complain about. Its not something you can solve by making up
> rules or making more new Forth words. Forth is about using few
> words. Unfortunately this style of writing cannot be applied in
> the same way to writing documentation.

The omitted text wasn't a discussion of who to write program code, it
was a discussion of the code from the perspective of the Forth
compiler. "Ignore this stuff" is all that is required from the side of
the Forth compiler.

As to the matter of style, I would expect that if I published code
using these tools, I would be more on the receiving side of style
advice than the delivery side.


Bruce McFarling

unread,
Feb 3, 2007, 11:39:30 AM2/3/07
to
On Feb 3, 10:21 am, "Doug Hoffman" <dhoff...@talkamerica.net> wrote:
> I observe that several Forths already use (* ... *): Win32Forth,
> Carbon MacForth, and PowerMops.

Are they nesting or non-nesting?


Doug Hoffman

unread,
Feb 3, 2007, 12:04:35 PM2/3/07
to

In PowerMops they are definitely nesting. In Win23Forth and Carbon
MacForth they appear to be not nesting (I could be wrong here if there
is a user settable switch). Regardless, at least two ways of readily
making them nesting have been demonstrated, which of course would be
backwardly compatible.

Bruce McFarling

unread,
Feb 3, 2007, 1:13:42 PM2/3/07
to
On Feb 3, 12:04 pm, "Doug Hoffman" <dhoff...@talkamerica.net> wrote:
...

> In PowerMops they are definitely nesting. In Win23Forth and Carbon
> MacForth they appear to be not nesting (I could be wrong here if there
> is a user settable switch). Regardless, at least two ways of readily
> making them nesting have been demonstrated, which of course would be
> backwardly compatible.

Oh right ... I was thinking the other direction, but as long as its
backwardly compatible, then a prelude file for Win32Forth and
CarbonMacForth could redefine (* *) without worrying about breaking
any existing code written specifically for those implementations.

That would suggest that if (* *) is standardized, it *ought* to be
nesting, because otherwise could interfere with the native PowerMops
(* *)


Anton Ertl

unread,
Feb 3, 2007, 11:46:03 AM2/3/07