Aliasing multiline-comments: ( and )
stavrogin
"alias" word is inadequate for this task.
Running test code below results in: "warning: ')' missing"
The problem seems to be that the "(" word contains both "("
and ")" in its definition, so it can't simply be aliased.
Is there an easy solution to this problem? I am just starting to learn
Forth, so I can't even understand, much less modify the definitions of
"(" and ")" myself.
===================================================
Test code:
#! /usr/bin/gforth
' ( alias foo
' ) alias bar
foo
test
bar
bye
===================================================
% ./test.4th
warning: ')' missing
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
===================================================
% gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
see (
: (
loadfile @ 0=
IF POSTPONE ( EXIT
THEN
BEGIN >in @ 41 parse nip >in @ rot - =
WHILE refill 0=
WHILE warnings @
WHILE .\" warning: ')' missing" cr
THEN
EXIT
THEN
REPEAT ; immediate ok
see )
: )
compile-sourcepos 139985085037408 compile, ; immediate ok
===================================================
Elizabeth D Rather
> I would like to alias "(" and ")" to "foo" and "bar", but the usual
> "alias" word is inadequate for this task.
>
> Running test code below results in: "warning: ')' missing"
>
> The problem seems to be that the "(" word contains both "("
> and ")" in its definition, so it can't simply be aliased.
>
> Is there an easy solution to this problem? I am just starting to learn
> Forth, so I can't even understand, much less modify the definitions of
> "(" and ")" myself.
>
> ===================================================
>
> Test code:
>
> #! /usr/bin/gforth
>
> ' ( alias foo
> ' ) alias bar
>
> foo
>
> test
>
> bar
>
> bye
>
>
In the first place, ")" isn't a definition, it's a delimiter. So, when
you executed foo it was looking for that delimiter, not a word to be
executed.
In the second place, I'm not sure why you're messing with alias, which
isn't really in the important beginner's tool chest. If you want to put
( in a definition, though, it's tricky, since ( is "immediate" (meaning
it will be executed if encountered in a colon definition), so you would
have to do this:
: foo ( -- ) POSTPONE ( ;
That way, the execution of ( will be "postponed" to occur when you
execute foo. It'll still look for that delimiter, though.
Other words that are immediate include structure words, such as IF ...
ELSE ... THEN, BEGIN ... UNTIL, DO ... LOOP, and similar words. The
reason ( is immediate is so you can put a comment in a definition, which
is often helpful.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
stavrogin
>
> In the first place, ")" isn't a definition, it's a delimiter.
Is there any way to tell whether a given set of characters is a word or a
delimiter?
> So, when you executed foo it was looking for that delimiter, not
> a word to be executed.
Can delimiters be aliased (not necessarily with the "alias" word, but by
any method)?
> In the second place, I'm not sure why you're messing with alias, which
> isn't really in the important beginner's tool chest.
My goal is to be able to use POD (perl's Plain Old Documentation format)
in Forth source code. That way I can use a variety of commonly available
tools to generate and format the documentation that's in the source.
And it seems that all that's stopping me from doing that right now is the
ability to define my own multiline-comments. I thought the "alias" word
was the right way to do this. But apparently not.
> If you want to put ( in a definition, though, it's tricky, since ( is
> "immediate" (meaning it will be executed if encountered in a colon
> definition), so you would have to do this:
>
> : foo ( -- ) POSTPONE ( ;
>
> That way, the execution of ( will be "postponed" to occur when you
> execute foo. It'll still look for that delimiter, though.
Hmm.. yes, it seems this doesn't really get me to my goal, which is to
define my own multiline-comment words (or delimiters, as long as they
work and can be made up of an arbitrary series of characters of my
choosing).
When I use that definition in my code, I still get the warning about the
missing ')'.
> Other words that are immediate include structure words, such as IF ...
> ELSE ... THEN, BEGIN ... UNTIL, DO ... LOOP, and similar words. The
> reason ( is immediate is so you can put a comment in a definition, which
> is often helpful.
I wouldn't need that ability for the multiline-comments that I'm looking
to create.
Thank you for your help.
BruceMcF
wrote:
> Is there any way to tell whether a given set of characters
> is a word or a delimiter?
It ought to be stated in the definition of the word. eg:
_____________________
6.1.0080 (
paren CORE
Compilation: Perform the execution semantics given below.
Execution: ( "ccc<paren>" -- )
Parse ccc delimited by ) (right parenthesis). ( is an immediate word.
The number of characters in ccc may be zero to the number of
characters in the parse area.
__________________________
this is from the standard, so its more awkward than an implementation
glossary ought to be ~ but the "compilation" section says its
immediate.
the easiest way to do a multiline comment that can include ( ) is to
use the [IF] word
0 [IF] =====================
This is a multiline comment
(and ")" does not break it).
[THEN]
stavrogin
> On Jun 2, 5:37 pm, stavrogin <usenet.20.blacksil...@spamgourmet.com>
wrote:
> >
> > Is there any way to tell whether a given set of characters is a word
> > or a delimiter?
>
> It ought to be stated in the definition of the word. eg:
>
> _____________________
> 6.1.0080 (
> paren CORE
>
> Compilation: Perform the execution semantics given below.
>
> Execution: ( "ccc<paren>" -- )
>
> Parse ccc delimited by ) (right parenthesis). ( is an immediate word.
>
> The number of characters in ccc may be zero to the number of characters
> in the parse area.
> __________________________
>
> this is from the standard, so its more awkward than an implementation
> glossary ought to be ~ but the "compilation" section says its immediate.
It does say '(' is immediate, but it doesn't say it's a delimiter.
Though it does seem to imply that ')' is a delimiter [since the standard
does say the 'ccc' are "delimited by )"].
> the easiest way to do a multiline comment that can include ( ) is to use
> the [IF] word
>
> 0 [IF] =====================
> This is a multiline comment
> (and ")" does not break it).
> [THEN]
It's not so much that I want to include ( ) but that I want to use a
series of characters of my own choosing as the multiline-comments
themselves. Here's an example from the POD documentation:
=pod
Remember to check its return value, as in:
stuff() || die "Couldn't do stuff!";
=cut
Here the '=pod' acts like Forth's '(' and the '=cut' acts like ')'.
Everything in between "=pod" and "=cut" is a block comment.
This is the sort of thing I'd like to implement in Forth, if possible.
Mark Wills
wrote:
Maybe something like this would work (may need a little alteration for
ANS):
Using C's comment delimeters as an example:
: /* ; ( just an empty definition, we need to tick this)
: */ BEGIN
BL WORD WHILE FIND DUP IF
['] /* = IF
FALSE
ELSE
TRUE
THEN
ELSE
TRUE
THEN
REPEAT
; IMMEDIATE
: TEST /* put stuff on stack: */ 1 2 3 /* and display it: /* . . . ;
Caviat: You need spaces after your opening and closing delimeters.
The theory is simple: /* is just another word, that when executed
"takes over" reading the input stream from the compiler. It reads a
word (delimited by a space) and then attempts to look it up in the
dictionary with FIND. If found, it compares the XT of the found word
with the XT of /* (the closing delimeter) and if they are equal, then
it knows it just found the end delimter (/*) and exits.
More caviats: I haven't tested the above, and WORD and FIND probably
work differently in ANS than what I'm used to. You get the idea
though.
ANS also has PARSE which may be useful.
Mark
Elizabeth D Rather
> On Thu, 02 Jun 2011 14:44:06 -0700, BruceMcF wrote:
>> On Jun 2, 5:37 pm, stavrogin<usenet.20.blacksil...@spamgourmet.com>
> wrote:
>>>
>>> Is there any way to tell whether a given set of characters is a word
>>> or a delimiter?
>>
>> It ought to be stated in the definition of the word. eg:
>>
>> _____________________
>> 6.1.0080 (
>> paren CORE
>>
>> Compilation: Perform the execution semantics given below.
>>
>> Execution: ( "ccc<paren>" -- )
>>
>> Parse ccc delimited by ) (right parenthesis). ( is an immediate word.
>>
>> The number of characters in ccc may be zero to the number of characters
>> in the parse area.
>> __________________________
>>
>> this is from the standard, so its more awkward than an implementation
>> glossary ought to be ~ but the "compilation" section says its immediate.
>
> It does say '(' is immediate, but it doesn't say it's a delimiter.
> Though it does seem to imply that ')' is a delimiter [since the standard
> does say the 'ccc' are "delimited by )"].
'(' is not a delimiter. It is a defined word, whose behavior is
described above. Words such as ." similarly take a delimiting "
according to their descriptions.
>> the easiest way to do a multiline comment that can include ( ) is to use
>> the [IF] word
>>
>> 0 [IF] =====================
>> This is a multiline comment
>> (and ")" does not break it).
>> [THEN]
>
> It's not so much that I want to include ( ) but that I want to use a
> series of characters of my own choosing as the multiline-comments
> themselves. Here's an example from the POD documentation:
>
> =pod
>
> Remember to check its return value, as in:
>
> stuff() || die "Couldn't do stuff!";
>
> =cut
>
> Here the '=pod' acts like Forth's '(' and the '=cut' acts like ')'.
> Everything in between "=pod" and "=cut" is a block comment.
>
> This is the sort of thing I'd like to implement in Forth, if possible.
If you had told us at the outset that what you're looking for is how to
do multiline comments, we could have answered more usefully. Virtually
all systems include some provision for multiline comments. Look at the
documentation for the system you're using, and look at the definition of
the word that starts the comment for suggestions as to how to write your
own.
stavrogin
>
> '(' is not a delimiter. It is a defined word, whose behavior is
> described above. Words such as ." similarly take a delimiting "
> according to their descriptions.
Oh, I see. So it's ')' which is the delimiter, and that's why trying to
alias it did not have the expected effect.
> If you had told us at the outset that what you're looking for is how to
> do multiline comments, we could have answered more usefully.
Sorry if my intention was not clear from the outset.
> Virtually all systems include some provision for multiline comments.
From what I understand, gforth's multiline-comments are made with ( and ),
which is why I asked about aliasing them.
> Look at the documentation for the system you're using,
Here are the only parts of the gforth manual I could find that reference
comments:
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Comments-
Tutorial.html
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Comments.html
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Stack_002dEffect-
Comments-Tutorial.html
From what I can see, nothing in there gets me any closer to solving this
problem, and nothing contradicts my impression that ( and ) are used by
gforth for multiline-comments.
Am I missing something?
> and look at the definition of the word that starts the comment for
> suggestions as to how to write your own.
That was the first thing I did, and I quoted the definition of '(' in my
first post to this newsgroup.
Unfortunately, I am too new to Forth to be able to understand, much less
successfully convert that definition to make it work for '=pod' and
'=cut' instead of '(' and ')'.
That's why I came here for help.
David N. Williams
> [...]
>
> It's not so much that I want to include ( ) but that I want to use a
> series of characters of my own choosing as the multiline-comments
> themselves. Here's an example from the POD documentation:
>
> =pod
>
> Remember to check its return value, as in:
>
> stuff() || die "Couldn't do stuff!";
>
> =cut
>
> Here the '=pod' acts like Forth's '(' and the '=cut' acts like ')'.
> Everything in between "=pod" and "=cut" is a block comment.
>
> This is the sort of thing I'd like to implement in Forth, if possible.
If you're willing to load my ANS forth parsing.fs library, it
would be like this, which works across lines:
: =pod
: =pod ( -- )
s" =cut" |s|-seek-instream
0= ABORT" ***Missing =cut terminator"; immediate
http://www.umich.edu/~williams/archive/forth/strings/parsing.fs
-- David
David N. Williams
> [...]
>
> : =pod
Oops! Delete the above extraneous line!
> : =pod ( -- )
> s" =cut" |s|-seek-instream
> 0= ABORT" ***Missing =cut terminator"; immediate
-- David
stavrogin
> If you're willing to load my ANS forth parsing.fs library, it would be
> like this, which works across lines:
>
> : =pod ( -- )
> s" =cut" |s|-seek-instream
> 0= ABORT" ***Missing =cut terminator"; immediate
>
> http://www.umich.edu/~williams/archive/forth/strings/parsing.fs
Thanks! This works great.
Elizabeth D Rather
> On Thu, 02 Jun 2011 14:32:08 -1000, Elizabeth D Rather wrote:
>> Virtually all systems include some provision for multiline comments.
>
> From what I understand, gforth's multiline-comments are made with ( and ),
> which is why I asked about aliasing them.
>
>> Look at the documentation for the system you're using,
>
> Here are the only parts of the gforth manual I could find that reference
> comments:
>
> http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Comments-
> Tutorial.html
>
> http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Comments.html
>
> http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Stack_002dEffect-
> Comments-Tutorial.html
>
> From what I can see, nothing in there gets me any closer to solving this
> problem, and nothing contradicts my impression that ( and ) are used by
> gforth for multiline-comments.
>
> Am I missing something?
>
>> and look at the definition of the word that starts the comment for
>> suggestions as to how to write your own.
>
> That was the first thing I did, and I quoted the definition of '(' in my
> first post to this newsgroup.
I am not terribly familiar with gforth. I do know that the team working
on revisions to the Forth Standard adopted a word for this purpose, and
if gforth doesn't have it, I'm sure someone here does. I think the
tutorial was primarily oriented at Standard Forth, but probably not
including recent additions.
> Unfortunately, I am too new to Forth to be able to understand, much less
> successfully convert that definition to make it work for '=pod' and
> '=cut' instead of '(' and ')'.
>
> That's why I came here for help.
I see that David Williams has provided some appropriate code.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
Albert van der Horst
stavrogin <usenet.20....@spamgourmet.com> wrote:
>I would like to alias "(" and ")" to "foo" and "bar", but the usual
>"alias" word is inadequate for this task.
>
>Running test code below results in: "warning: ')' missing"
>
>The problem seems to be that the "(" word contains both "("
>and ")" in its definition, so it can't simply be aliased.
>
>Is there an easy solution to this problem? I am just starting to learn
>Forth, so I can't even understand, much less modify the definitions of
>"(" and ")" myself.
You are better off looking at the definition of ( and steal
the source.
Assuming you have
NAME that leaves the next WORD addr,len from
the input
and
$= (addr,len, addr,len -- flag)
that tells whether two strings are equal
------------------ 8<---------------------
CREATE delimiter CHAR b C, CHAR a C, CHAR r C,
: foo BEGIN NAME delimiter 3 $= UNTIL ; IMMEDIATE
------------------ 8<---------------------
Will do the trick.
Of course NAME and $= still are to be defined, but you can either
program them or find a similar facility in your Forth.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Stephen Pelc
<markrob...@yahoo.co.uk> wrote:
> IF
> FALSE
> ELSE
> TRUE
> THEN
People have been sacked for less! Use 0= instead.
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
The Beez'
> <markrobertwi...@yahoo.co.uk> wrote:
> > IF
> > FALSE
> > ELSE
> > TRUE
> > THEN
>
> People have been sacked for less! Use 0= instead.
I've even seen "IF TRUE ELSE FALSE THEN", believe it or not. However,
I must add, this was due to a programmer simplifying a program, ending
up doing this and overlooking it.
Hans Bezemer
Mark Wills
> On Thu, 2 Jun 2011 16:17:34 -0700 (PDT), Mark Wills
>
> > IF
> > FALSE
> > ELSE
> > TRUE
> > THEN
>
> People have been sacked for less! Use 0= instead.
>
> Stephen
>
> --
> 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
Noted. <Hangs head in shame...>
Stephen Pelc
<markrob...@yahoo.co.uk> wrote:
>Noted. <Hangs head in shame...>
We've all done it ... and worse.
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
Albert van der Horst
The Beez' <han...@bigfoot.com> wrote:
>On 3 jun, 11:53, stephen...@mpeforth.com (Stephen Pelc) wrote:
>> <markrobertwi...@yahoo.co.uk> wrote:
>> > =A0 =A0 =A0 =A0 =A0 FALSE
>> > =A0 =A0 =A0 =A0 ELSE
>> > =A0 =A0 =A0 =A0 =A0 TRUE
>> > =A0 =A0 =A0 =A0 THEN
>>
>> People have been sacked for less! Use 0=3D instead.
>
>I've even seen "IF TRUE ELSE FALSE THEN", believe it or not. However,
>I must add, this was due to a programmer simplifying a program, ending
>up doing this and overlooking it.
This is not bad at all. `` 0= 0= '' is quite puzzling if you
don't know the idiom. (`` 0= INVERT '' isn't any better, and
quite long ).
Of course it is a shame that we can't do `` 0= NOT '', which
conveys the meaning precisely:
- test for zero, resulting in a boolean flag
- now reverse the meaning of the resulting boolean.
No, this was a real time bomb:
#define TRUE -1
(c-code written by a Pascal programmer)
>
>Hans Bezemer
Ed
> On Thu, 02 Jun 2011 14:32:08 -1000, Elizabeth D Rather wrote:
> >
> > '(' is not a delimiter. It is a defined word, whose behavior is
> > described above. Words such as ." similarly take a delimiting "
> > according to their descriptions.
>
> Oh, I see. So it's ')' which is the delimiter, and that's why trying to
> alias it did not have the expected effect.
>
> > If you had told us at the outset that what you're looking for is how to
> > do multiline comments, we could have answered more usefully.
>
> Sorry if my intention was not clear from the outset.
A multi-line comment definition from c.l.f. several years ago
\ Block comment (* ... *)
: (*
begin
>in @ source nip < if
bl word count s" *)" compare
else refill then 0=
until ; immediate
Ed
Optimizing forths should be able to optimize such sequences, right? :)
Stephen Pelc
>> I've even seen "IF TRUE ELSE FALSE THEN", believe it or not. However,
>> I must add, this was due to a programmer simplifying a program, ending
>> up doing this and overlooking it.
>
>Optimizing forths should be able to optimize such sequences, right? :)
At least for VFX, the code sequences for 0= and 0<> are much better.
The Beez'
> Optimizing forths should be able to optimize such sequences, right? :)
c**p of an incompetent programmer", yes it should - as long as you
think that a machine can outperform a human in that respect. If you
mean: "optimizing already good code", no I think it won't. ;-)
I go for the latter ;-)
Hans Bezemer
BruceMcF
: wordstream ( xt -- )
>R BEGIN BL WORD COUNT DUP IF
R@ EXECUTE
ELSE 2DROP REFILL
THEN 0= UNTIL
RDROP ;
... the idea is you hand it an xt of a word that is:
\ wordhandler ( ca u -- x ) \ x=0 means stop
So for foo/bar:
: bar? ( ca u -- <>bar? ) s" bar" COMPARE ;
: foo ['] bar? wordstream ;
Ed
The sequences in question are "already good code" (as boolean
statements go). It's just that Forth provides optimizing words
0= 0<> for forths without optimizers (or rather with human-
based optimizers).
If one has a machine-based optimizer why shouldn't it optimize
the same statements that a human would? Agreed, this would
disadvantage forths without a machine-optimizer but as the
saying goes "that's their problem" :)
Elizabeth D Rather
> The Beez' wrote:
>> On 4 jun, 03:59, "Ed"<nos...@invalid.com> wrote:
>>> Optimizing forths should be able to optimize such sequences, right? :)
>> Depends that you mean by "optimizing". If you mean: "cleaning up the
>> c**p of an incompetent programmer", yes it should - as long as you
>> think that a machine can outperform a human in that respect. If you
>> mean: "optimizing already good code", no I think it won't. ;-)
>>
>> I go for the latter ;-)
>
> The sequences in question are "already good code" (as boolean
> statements go). It's just that Forth provides optimizing words
> 0= 0<> for forths without optimizers (or rather with human-
> based optimizers).
Yes, 0= and 0<> are available, but 0<> is usually utterly unnecessary,
since IF does not require a well-formed flag. I think it is a flagrant
disservice to the Forth newbies here to present them with bad code
examples with the excuse that if they're lucky an optimizer will clean
up the mess.
Marcel Hendrix
>>> I've even seen "IF TRUE ELSE FALSE THEN", believe it or not. However,
>>> I must add, this was due to a programmer simplifying a program, ending
>>> up doing this and overlooking it.
>>Optimizing forths should be able to optimize such sequences, right? :)
> At least for VFX, the code sequences for 0= and 0<> are much better.
With iForth 0= isn't faster, but certainly shorter.
ANEW -badtest
: t1 IF TRUE ELSE FALSE THEN ;
: t2 0= ;
: t3 not ;
: test
CR ." t1 : " TIMER-RESET 0 #100000000 0 DO i t1 OR LOOP DEC. .ELAPSED
CR ." t2 : " TIMER-RESET 0 #100000000 0 DO i t2 OR LOOP DEC. .ELAPSED
CR ." t3 : " TIMER-RESET 0 #100000000 0 DO i t3 OR LOOP DEC. .ELAPSED ;
test
(Intel quad-core i7 920, 2.67 GHz, Windows 7 64-bit professional with 12 GB RAM)
t1 : -1 0.252 seconds elapsed.
t2 : -1 0.259 seconds elapsed.
t3 : -1 0.254 seconds elapsed.
t1 : -1 0.253 seconds elapsed.
t2 : -1 0.260 seconds elapsed.
t3 : -1 0.273 seconds elapsed.
t1 : -1 0.239 seconds elapsed.
t2 : -1 0.259 seconds elapsed.
t3 : -1 0.262 seconds elapsed.
\ The result is kept in rbx for all three
( t1 IF ELSE THEN)
mov rdi, [rbp 0 +] qword
cmp rdi, 0 b#
je $012456FB offset NEAR
push rbx
mov rbx, -1 d#
jmp $012456FF offset NEAR
push rbx
xor rbx, rbx
pop rdi
or rdi, rbx
mov rbx, rdi
( t2, 0=)
mov rdi, [rbp 0 +] qword
cmp rdi, 0 b#
sete cl
movzx rcx, cl
neg rcx
or rbx, rcx
( t3, NOT)
mov rdi, [rbp 0 +] qword
cmp rdi, 0 b#
sete cl
movzx rcx, cl
neg rcx
or rbx, rcx
-marcel
Paul Rubin
> Yes, 0= and 0<> are available, but 0<> is usually utterly unnecessary,
> since IF does not require a well-formed flag.
You might want to do arithmetic with the result of 0<> instead
of consuming it immediately with IF.
Ed
> On 6/4/11 6:05 PM, Ed wrote:
> > The Beez' wrote:
> >> On 4 jun, 03:59, "Ed"<nos...@invalid.com> wrote:
> >>> Optimizing forths should be able to optimize such sequences, right? :)
> >> Depends that you mean by "optimizing". If you mean: "cleaning up the
> >> c**p of an incompetent programmer", yes it should - as long as you
> >> think that a machine can outperform a human in that respect. If you
> >> mean: "optimizing already good code", no I think it won't. ;-)
> >>
> >> I go for the latter ;-)
> >
> > The sequences in question are "already good code" (as boolean
> > statements go). It's just that Forth provides optimizing words
> > 0= 0<> for forths without optimizers (or rather with human-
> > based optimizers).
>
> Yes, 0= and 0<> are available, but 0<> is usually utterly unnecessary,
> since IF does not require a well-formed flag. I think it is a flagrant
> disservice to the Forth newbies here to present them with bad code
> examples with the excuse that if they're lucky an optimizer will clean
> up the mess.
Very amusing.
... IF FALSE ELSE TRUE THEN ...
is neither bad code nor a mess. It is simply unoptimized forth code.
It's no more "bad code" than writing SWAP DROP in place of NIP .
That such sequences find their way into forth code is not unknown.
Likely we've all seen it, or done it ourselves. E.g. I can easily imagine
writing psuedo code, translating it into forth and missing out on any
number of optimizations. I see nothing objectionable in the machine
catching what humans may have missed.
Elizabeth D Rather
Sure, that's why it exists, but the context here involves IF.
The Beez'
> Yes, 0= and 0<> are available, but 0<> is usually utterly unnecessary,
> since IF does not require a well-formed flag. I think it is a flagrant
> disservice to the Forth newbies here to present them with bad code
> examples with the excuse that if they're lucky an optimizer will clean
> up the mess.
s" It" s" fails" >r over r> tuck and IF ." Both are not zero length"
ELSE ." At least one has zero length" then cr type cr type
In combination with OR or AND, 0= and 0<> are REALLY required. That's
why I think words like ANY (logical OR) and BOTH (logical AND) could
be real life savers. And yes, in this case we could largely discard 0=
and 0<>.
Hans Bezemer
Martin Krischik
> c**p of an incompetent programmer", yes it should - as long as you
> think that a machine can outperform a human in that respect. If you
There have been studies into that (Like can an Assembler programmer
outperform an optimizing C compiler). Result: Only about 10 percent of
programmers can outperform an optimizer. So yes, machine will outperform
most humans in that respect.
Martin
--
Martin Krischik
mailto://kris...@users.sourceforge.net
https://sourceforge.net/users/krischik
Anton Ertl
>In article <9fbb3064-0c0e-43fd...@d1g2000yqm.googlegroups.com>,
>The Beez' <han...@bigfoot.com> wrote:
>>I've even seen "IF TRUE ELSE FALSE THEN", believe it or not. However,
>>I must add, this was due to a programmer simplifying a program, ending
>>up doing this and overlooking it.
>
>This is not bad at all. `` 0= 0= '' is quite puzzling if you
>don't know the idiom.
Well, better learn the idiom, then. That's no good reason to use the
code shown above. Of course, I would use 0<> instead of 0= 0=.
- 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
EuroForth 2010: http://www.euroforth.org/ef10/
Anton Ertl
>The Beez' wrote:
>> I've even seen "IF TRUE ELSE FALSE THEN", believe it or not. However,
>> I must add, this was due to a programmer simplifying a program, ending
>> up doing this and overlooking it.
>
>Optimizing forths should be able to optimize such sequences, right? :)
I wouldn't expect it of them. It's something they would have to have
a separate analysis for (how slow do you want your compiler to
compile?), and that analysis probably does not help much code that
compilers encounter in the wild.
And as others mention, if there's a good reason for writing code this
way, there's a much better case for adding an optimization for it, but
in the present case it's just an oversight that should be better fixed
in the source.
Anton Ertl
>There have been studies into that (Like can an Assembler programmer
>outperform an optimizing C compiler). Result: Only about 10 percent of
>programmers can outperform an optimizer. So yes, machine will outperform
>most humans in that respect.
I have seen many such claims, but never a study on it. Can you give
me references for them?
Ed
> On 6/4/11 8:09 PM, Paul Rubin wrote:
> > Elizabeth D Rather<era...@forth.com> writes:
> >> Yes, 0= and 0<> are available, but 0<> is usually utterly unnecessary,
> >> since IF does not require a well-formed flag.
> >
> > You might want to do arithmetic with the result of 0<> instead
> > of consuming it immediately with IF.
>
>
> Sure, that's why it exists, but the context here involves IF.
>
0= 0<> are examples of single forth words designed to optimize.
Early forths didn't have optimizers and such words were the next
best thing. It also required the forth programmer to be "on the ball".
Found in the SwiftForth system source:
... WITHIN IF TRUE ELSE FALSE THEN ...
A sacking offence? Or just another c.l.f. beat-up that takes common
oversights and blows them out of proportion.
Ed
> ...
> And as others mention, if there's a good reason for writing code this
> way, there's a much better case for adding an optimization for it, but
> in the present case it's just an oversight that should be better fixed
> in the source.
Sure it's better to optimize in the source. The fact is humans don't
think in terms of optimized forth and oversights happen - quite often
as this thread demonstrates. And not just newbies - even Forth Inc
programmers do it.
If optimizers currently do:
swap drop substitute nip
swap over substitute tuck
over over substitute 2dup
rot rot substitute -rot
...
I see no logical reason to exclude others. It may be some optimizers
are incapable of complex substitutions but that's a technical matter.
Elizabeth D Rather
Definitely a knuckle-wrapping offense at the very least! ;-)
I maintain my position, that one should always strive to write efficient
code regardless of whether there's an optimizer underneath, because good
code is always easier to debug and maintain. And that we have a moral
obligation to the newbies on c.l.f to provide good examples where possible.
Marcel Hendrix
[..]
> 0= 0<> are examples of single forth words designed to optimize.
> Early forths didn't have optimizers and such words were the next
> best thing. It also required the forth programmer to be "on the ball".
> Found in the SwiftForth system source:
> ... WITHIN IF TRUE ELSE FALSE THEN ...
> A sacking offence? Or just another c.l.f. beat-up that takes common
> oversights and blows them out of proportion.
Without more context, neither. I found the next pattern in my own sources:
examples\misc\ctester.frt(534): :NONAME < IF TRUE ELSE FALSE ENDIF ; IS xt-dubious
It serves to test if an optimized sequence behaves properly.
-marcel
Anton Ertl
>If optimizers currently do:
>
> swap drop substitute nip
> swap over substitute tuck
> over over substitute 2dup
> rot rot substitute -rot
> ...
>
>I see no logical reason to exclude others.
Each optimization has costs: coding, testing, compilation speed, and
correctness. So it is prudent not to write optimizations that pay off
rarely and/or that should not occur in well-written code (how these
factors are weighted are the compiler writer's decision).
Andrew Haley
> "Ed" <nos...@invalid.com> writes:
>>If optimizers currently do:
>>
>> swap drop substitute nip
>> swap over substitute tuck
>> over over substitute 2dup
>> rot rot substitute -rot
>> ...
>>
>>I see no logical reason to exclude others.
>
> Each optimization has costs: coding, testing, compilation speed, and
> correctness. So it is prudent not to write optimizations that pay
> off rarely and/or that should not occur in well-written code (how
> these factors are weighted are the compiler writer's decision).
I agree. However, I think it's important to keep the Forth core
small: the core stack manipulation words are
DROP DUP OVER ROT SWAP 2DROP 2DUP 2OVER 2SWAP >R R> R@
and, IMO, Forth is a better language (i.e. easier to read and learn)
without a zoo of others that serve only to obfuscate. IMO, this small
vocabulary is a good thing from a cognitive point of view. For that
reason, I like Forths that don't care whether the programmer remembers
to use NIP TUCK, UNDER and so on; they generate the same code
regardless. FWIW, I still don't remember what UNDER is supposed to do.
Andrew.
Anton Ertl
>I agree. However, I think it's important to keep the Forth core
>small: the core stack manipulation words are
>
>DROP DUP OVER ROT SWAP 2DROP 2DUP 2OVER 2SWAP >R R> R@
>
>and, IMO, Forth is a better language (i.e. easier to read and learn)
>without a zoo of others that serve only to obfuscate. IMO, this small
>vocabulary is a good thing from a cognitive point of view. For that
>reason, I like Forths that don't care whether the programmer remembers
>to use NIP TUCK, UNDER and so on; they generate the same code
>regardless.
Well, if it's a compiler that models the stack, like VFX or iForth,
this happens automatically, no special optimization needed. But
that's not true for IF TRUE ELSE FALSE THEN. It does not fall out as
a result of something that any current compiler does anyway.
Hugh Aguilar
> On 6/2/11 12:57 PM, stavrogin wrote:
> > It's not so much that I want to include ( ) but that I want to use a
> > series of characters of my own choosing as the multiline-comments
> > themselves.
>
> If you had told us at the outset that what you're looking for is how to
> all systems include some provision for multiline comments. Look at the
> documentation for the system you're using, and look at the definition of
> the word that starts the comment for suggestions as to how to write your
> own.
It is a bad idea to use the multi-line facility provided in Forth
systems because you typically aren't provided with the source-code,
and if you are provided with source-code it likely isn't ANS-Forth
compatible. The result is that your program will become system-
dependent, and you will lose ANS-Forth compatibility.
Use COMMENT that is provided in my novice package:
http://www.forth.org/novice.html
It is written in ANS-Forth compliant code, as is everything in the
novice package.
It is an especially bad idea to use SwiftForth's multi-line facility,
because it is called { and uses a } delimiter. This presents a name-
clash with the typical { and } use, which is defining local variables
(this use was originally developed at John Hopkins). In my novice
package, I use { and } to define local variables compatible with the
usual John Hopkins implementation, and I use COMMENT for multi-line
comments. COMMENT can use any character as a delimiter; I usually use
& because it is pretty rare in Forth code, but you can use whatever
character that you want.
Elko T
> I would like to alias "(" and ")" to "foo" and "bar", but the usual
> "alias" word is inadequate for this task.
In case you want multi-line AND nestable comments, you can define
them similarly to what I have defined for myself in my utilities:
\ multi-line nestable comments
\
: (* ( -- )
BEGIN
in-word
WHILE \ while source
BL PARSE \ -- addr len
2DUP S" *)" COMPARE \ is it the closing brace?
WHILE \ no
S" (*" COMPARE 0= \ is it "(*" ?
IF \ yes
RECURSE \ if yes, nest one level
THEN
REPEAT \ otherwise, it's consumed
2DROP EXIT \ closing, unnest
THEN
; IMMEDIATE
The only non-standard word here is "in-word", which I get for free,
kinda, from other utilities I've written. Its stack pic is:
\ advance input stream to a non-zero length non-whitespace string
: in-word ( -- flag )
And you can do it as an exercise, if you want. ;) It skips the blanks
and refills if needed, until the first non-blanks are next, or the
file ends.
--
No, no, you can't e-mail me with the nono.
David N. Williams
> [...]
>
> In case you want multi-line AND nestable comments, you can define them
> similarly to what I have defined for myself in my utilities:
>
> \ multi-line nestable comments
> \
> : (* ( -- )
> BEGIN
> in-word
> WHILE \ while source
> BL PARSE \ -- addr len
> 2DUP S" *)" COMPARE \ is it the closing brace?
> WHILE \ no
> S" (*" COMPARE 0= \ is it "(*" ?
> IF \ yes
> RECURSE \ if yes, nest one level
> THEN
> REPEAT \ otherwise, it's consumed
> 2DROP EXIT \ closing, unnest
> THEN
> ; IMMEDIATE
I like it! Would I be able to use it in open source code,
e.g., with the LGPL?
> The only non-standard word here is "in-word", which I get for free,
> kinda, from other utilities I've written. Its stack pic is:
>
> \ advance input stream to a non-zero length non-whitespace string
> : in-word ( -- flag )
>
> And you can do it as an exercise, if you want. ;) It skips the blanks
> and refills if needed, until the first non-blanks are next, or the file
> ends.
This is the same as Next-Word in Wil Baden's Tool Belt. The
version I use is called NEXT-INSTREAM-NAME, and also works when
pasted into an interactive session at the terminal.
-- David
Chris Hinsley
> stavrogin wrote:
>> On Thu, 02 Jun 2011 14:32:08 -1000, Elizabeth D Rather wrote:
>>>
>>> '(' is not a delimiter. It is a defined word, whose behavior is
>>> described above. Words such as ." similarly take a delimiting "
>>> according to their descriptions.
>>
>> Oh, I see. So it's ')' which is the delimiter, and that's why trying to
>> alias it did not have the expected effect.
>>
>>> If you had told us at the outset that what you're looking for is how to
>>> do multiline comments, we could have answered more usefully.
>>
>> Sorry if my intention was not clear from the outset.
>> ...
>
> A multi-line comment definition from c.l.f. several years ago
>
> \ Block comment (* ... *)
> : (*
> begin
> >in @ source nip < if
> bl word count s" *)" compare
> else refill then 0=
> until ; immediate
I thought ( and ) where allready provided as block comments ? I
originally did them to cope with nesting, but was told they don't allow
that.
\ word called ( which just drops input characters until it hits the
corresponding )
: ( IMMEDIATE
BEGIN
')' PARSE + SOURCE + =
WHILE
REFILL 0=
UNTIL THEN
;
?
Chris
Chris Hinsley
> I thought ( and ) where allready provided as block comments ? I
> originally did them to cope with nesting, but was told they don't allow
> that.
>
> \ word called ( which just drops input characters until it hits the
> corresponding )
> : ( IMMEDIATE
> BEGIN
> ')' PARSE + SOURCE + =
> WHILE
> REFILL 0=
> UNTIL THEN
> ;
>
> ?
>
> Chris
Better provide the ')' word.
: ')' [ CHAR ) ] LITERAL ;
Chris
Chris Hinsley
>> \
>> : (* ( -- )
>> BEGIN
>> in-word
>> WHILE \ while source
>> BL PARSE \ -- addr len
>> 2DUP S" *)" COMPARE \ is it the closing brace?
>> WHILE \ no
>> S" (*" COMPARE 0= \ is it "(*" ?
>> IF \ yes
>> RECURSE \ if yes, nest one level
>> THEN
>> REPEAT \ otherwise, it's consumed
>> 2DROP EXIT \ closing, unnest
>> THEN
>> ; IMMEDIATE
I like the use of RECURSE on this !
I wouldn't have done it that way, but this is very neat. :)
Chris
Anton Ertl
>Better provide the ')' word.
>
>: ')' [ CHAR ) ] LITERAL ;
On Forth systems that support the "Number prefixes" extension of Forth
200x, this is not necessary, but on others, yes, this is a way to make
the code work.
Coos Haak
Why not
: ')' [CHAR] ) ;
or
CHAR ) CONSTANT ')'
But I would use the inline version, why define a separate word for a word
that is simple and only used once?
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
BruceMcF
\ wordstream ( x*i xt -- x*j )
with the xt being a handler word:
( ca u -- flag=continue? )
... I found its best to also externalize 'end of line' handling, so:
: wordstream ( x*i xt1 xt2 -- x*j )
2>R BEGIN
BL WORD COUNT DUP IF
R@ EXECUTE
ELSE
2DROP 2R@ DROP EXECUTE
THEN
0= UNTIL 2R> 2DROP ;
: bar? ( ca u -- flag ) S" bar" COMPARE ;
: foo ( "... bar" -- )
['] REFILL ['] bar? wordstream ;
depending on spec, you may want foo IMMEDIATE
Elko T
> On 6/7/11 12:36 AM, Elko T wrote:
>> [...]
>>
>> In case you want multi-line AND nestable comments, you can define them
>> similarly to what I have defined for myself in my utilities:
>>
>> \ multi-line nestable comments
>> \
>> : (* ( -- )
>
> e.g., with the LGPL?
Sure, go ahead, no prob. Looking at the code now, I see that the
EXIT is not needed, but it is probably a remnant of my editing, where
it must have been inside the REPEAT loop at some point.
>> The only non-standard word here is "in-word", which I get for free,
>> kinda, from other utilities I've written. Its stack pic is:
>>
>> \ advance input stream to a non-zero length non-whitespace string
>> : in-word ( -- flag )
>>
>> And you can do it as an exercise, if you want. ;) It skips the blanks
>> and refills if needed, until the first non-blanks are next, or the file
>> ends.
>
> This is the same as Next-Word in Wil Baden's Tool Belt. The
> version I use is called NEXT-INSTREAM-NAME, and also works when
> pasted into an interactive session at the terminal.
Yeah, it is a useful factor to have in one's tool set.
Ed
You could do that but any source containing a comment that spanned
lines wouldn't be portable.
The other problem is the use of a single character to terminate the
comment. What if your comments included math formulae with brackets?
One could choose a different termination character but that might conflict
too. Several forths have settled for the two-character scheme employed
by C and Pascal. Typically they use (( ... )) or (* ... *) with preference
for the latter since (( ... )) has issues with math formula.
While I'm at it, the code I previously posted contains some redundancy.
This one should work equally well.
\ Block comment (* ... *)
: (*
begin
bl word count dup if
s" *)" compare
else 2drop refill then 0=
until ; immediate
\ A version with user-defined begin/end sequences
: skipover ( adr len )
begin
bl word count dup if
2over compare
else 2drop refill then 0=
until 2drop ;
: (* s" *)" skipover ; immediate
: foo s" bar" skipover ; immediate
--
Ed
> "Ed" <nos...@invalid.com> writes:
> >If optimizers currently do:
> >
> > swap drop substitute nip
> > swap over substitute tuck
> > over over substitute 2dup
> > rot rot substitute -rot
> > ...
> >
> >I see no logical reason to exclude others.
>
> Each optimization has costs: coding, testing, compilation speed, and
> correctness. So it is prudent not to write optimizations that pay off
> rarely and/or that should not occur in well-written code (how these
> factors are weighted are the compiler writer's decision).
I've yet to hear of a prospective customer who rejected an optimizing
compiler because it did its job too well!
The optimizations listed above will rarely pay-off, yet they're provided.
Why? Because the customer expects it.
Ed
> ...
> I maintain my position, that one should always strive to write efficient
> code regardless of whether there's an optimizer underneath, because good
> code is always easier to debug and maintain. And that we have a moral
> obligation to the newbies on c.l.f to provide good examples where possible.
I reject the insinuation that I am misleading newcomers and promoting
bad practice.
When a newcomer asks you which of the following represents "good"
"efficient" Forth coding, what will you tell them?
SWAP DROP or NIP
OVER OVER or 2DUP
2DROP DROP or 3DROP
There is no simple answer for it will depend on a range of factors -
including whether or not an optimizer is present.
Colin MacIntyre
Optimizing is also fun, and helps to keep the dictionary small and easy to remember. I optimize cell+, cell-, and any derivatives to just one word, 'cell' which is used like:
+1 cell
-2 cell
+31 cell
It can optimize any number >=-31 <=31 on x86 CPU's to a 3-byte instruction.
All arithmetic operators have similar 3-byte (or less) inline optimization (for any number <=127), so I can forget about 2*, 1+, lshift rshift tricks, etc.
The only tricky part was when I realized that it would sometimes optimize a jmp instruction's address, taking it as an integer. But that is fixed now.
Philosophically, this kind of goes against Moore's recommendation that the dictionary be used to replace conditionals (many tiny, simple words doing only one thing), but I figured that since it happens at compile-time no big-deal. Plus it breaks the rule to please the rule, since it can be viewed as a kind of factoring and is more readable.
Anton Ertl
>Anton Ertl wrote:
>> "Ed" <nos...@invalid.com> writes:
>> >If optimizers currently do:
>> >
>> > swap drop substitute nip
>> > swap over substitute tuck
>> > over over substitute 2dup
>> > rot rot substitute -rot
>> > ...
>> >
>> >I see no logical reason to exclude others.
>>
>> Each optimization has costs: coding, testing, compilation speed, and
>> correctness. So it is prudent not to write optimizations that pay off
>> rarely and/or that should not occur in well-written code (how these
>> factors are weighted are the compiler writer's decision).
>
>I've yet to hear of a prospective customer who rejected an optimizing
>compiler because it did its job too well!
Depending on the meaning of "too well", this might happen, too. E.g.,
if a compiler came along that optimizes as well as gcc-2.x and
supports modern architectures, I would switch to it from gcc-4.x in a
second, because gcc-4.x's "optimizations" do their job too well: Even
if they don't miscompile my code outright, they often slow it down a
lot.
However, the more frequent causes of rejection by the customer related
to the costs mentioned above would be: higher cost, slow compilation,
generation of broken code, and non-availability (increased time to
market).
Mark Wills
: ( BEGIN BL WORD COUNT 1- + C@ ASCII ) = UNTIL ; IMMEDIATE
For \ I used:
: \ >IN @ 64 + -64 AND >IN ! ; IMMEDIATE
Fine when your system is blocks only, like mine, however other file
based systems will need something else (just loop on WORD until the
current line of input has been swallowed up, or set >IN to #TIB)
Mark
Chris Hinsley
So, have I not actually implamented ( according to the spec ? I'll
correct it if sombody tells me I did it wrong.
I agree that it's be nice to have a standard multiline comment word
that cope with nesting BTW.
Regards
Chris
Chris Hinsley
Ms Rathers book, page 40, say's ( is pretty much what I've got.
Chris
Gerry Jackson
( comments can span multiple lines if the file word set is present, see
the ANS Forth standard 11.6.1.0080
However the definition is not ANS Forth because the IMMEDIATE is in the
wrong place, it should be
: (
BEGIN
')' PARSE + SOURCE + =
WHILE
REFILL 0=
UNTIL THEN
; IMMEDIATE
IMMEDIATE isn't an immediate word.
--
Gerry
Coos Haak
> On Wednesday, June 8, 2011 12:23:48 PM UTC+8, Ed wrote:
>> Anton Ertl wrote:
>>> "Ed" <nos...@invalid.com> writes:
>>> >If optimizers currently do:
>>> >
>>> > swap drop substitute nip
>>> > swap over substitute tuck
>>> > over over substitute 2dup
>>> > rot rot substitute -rot
>>> > ...
>>> >
>>> >I see no logical reason to exclude others.
>>>
>>> Each optimization has costs: coding, testing, compilation speed, and
>>> correctness. So it is prudent not to write optimizations that pay off
>>> rarely and/or that should not occur in well-written code (how these
>>> factors are weighted are the compiler writer's decision).
>>
>> I've yet to hear of a prospective customer who rejected an optimizing
>> compiler because it did its job too well!
>>
>> The optimizations listed above will rarely pay-off, yet they're provided.
>> Why? Because the customer expects it.
>
> Optimizing is also fun, and helps to keep the dictionary small and easy to remember. I optimize cell+, cell-, and any derivatives to just one word, 'cell' which is used like:
>
> +1 cell
> -2 cell
> +31 cell
>
The ANS/ISO standard has the word CELLS (plural) for this.
No Forth that I have accepts numbers beginning with a plus sign.
Chris Hinsley
I understood IMMEDIATE to work on the currently being defined word ?
And it was only a convention that it came at the end. I might be wrong
in that. I might need to do some hasty editing !
JonesForth gets me again !
I prefer to have it at the begining if that's legal because I like to
know that the word is IMMEDIATE 'up front' rather than at the end of
the definition (possibly several pages down). And yes, I know your all
going to start saying 'but you should never have a word several pages
long...' :)
Chris
stavrogin
>
> Depending on the meaning of "too well", this might happen, too. E.g.,
> if a compiler came along that optimizes as well as gcc-2.x and supports
> modern architectures, I would switch to it from gcc-4.x in a second,
> because gcc-4.x's "optimizations" do their job too well: Even if they
> don't miscompile my code outright, they often slow it down a lot.
Can't you just tell gcc not to optimize your code?
Mark Wills
Immediate works on the *last* defined word. Generally, that's the one
pointed at by LATEST.
Presumably, if you are based on JonesForth, you smudge/hide your word
during creation, and have ; un-smudge it? A word such as HEADER
creates the dictionary entry, links it to the previous entry in the
current vocabulary, and sets LATEST to point to this newly created
dictionary entry.
IMMEDIATE then toggles on/off the immediate bit/flag in the dictionary
entry.
If you want to specify IMMEDIATE from inside your colon definition,
you can do this, but IMMEDIATE itself will have to be immediate.
Generally, because IMMEDIATE *toggles* the immediate bit associated
with the word pointed at by LATEST, there is no need to have it as
immediate itself.
: SOME-WORD ... ... ; IMMEDIATE \ define immediate word
< oh no! I changed my mind... >
IMMEDIATE \ set the word back to a "normal" word
My code for LATEST is
;[ IMMEDIATE ( -- )
; toggles the immediate bit in the dictionary entry pointed to by
LATEST.
_imm mov @latest,r0 ; get address of latest dictionary entry
inct r0 ; point to length entry
mov *r0,r1 ; get the length entry
xor @immed,r1 ; toggle immediate bit (weight >8000)
mov r1,*r0 ; store it
b @retB0 ; return to caller
immed data >8000 ; flag for immediate words
Regards
Mark
BruceMcF
CELLS and ``cell'' as described are two different things ~ ``cell'' is
``CELLS +''
Mark Wills
Chris,
Sorry to labour on this point, but I thought of a problem you will
encounter if your definition of IMMEDIATE is immediate itself. You
will not be able to set children of CREATE to be immediate.
Consider:
: THING CREATE IMMEDIATE DOES> DROP ." Surprise!!!" ;
Here, the *child* of THING will be set to immediate when it is
CREATEd. However, if your definition of IMMEDIATE is immediate itself
(phew!), it would (erroneously) set THING to be immediate, which is
not what was intended.
If you now create a child of THING:
THING THINGY
Now use THINGY in a colon def:
: TEST 1 2 3 THINGY 4 5 6 ;
You will see that THINGY executes (or at least, it should!) as TEST is
being compiled, because it was set to be immediate by the parent
(THING). I hope this makes sense! If your IMMEDIATE is immediate, then
the above wouldn't work. You would need [COMPILE] IMMEDIATE. So, it
really is better to have IMMEDIATE as a standard word, and get into
the habit of tagging it onto the end of your colon defs. Or, use the
compiler switches:
: FRED [ IMMEDIATE ] ... ... ;
Though personally I prefer
: FRED ... ... ; IMMEDIATE
...as God intended ;-)
HTH
Mark
(I'm responding in the main because I got bitten more than a few times
by Jones' Forth. Still, it was a very very good learning experience!)
Chris Hinsley
> On Jun 8, 7:03 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
>> On 2011-06-08 12:15:43 +0100, Gerry Jackson said:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On 08/06/2011 05:20, Ed wrote:
>>>> Chris Hinsley wrote:
>>>>> On 2011-06-04 02:39:00 +0100, Ed said:
>>
>>>>>> stavrogin wrote:
>>>>>>> On Thu, 02 Jun 2011 14:32:08 -1000, Elizabeth D Rather wrote:
>>
>>>>>>>> '(' is not a delimiter. It is a defined word, whose behavior is
>>>>>>>> described above. Words such as ." similarly take a delimiting "
>>>>>>>> according to their descriptions.
>>
>>>>>>> Oh, I see. So it's ')' which is the delimiter, and that's why trying to
>>>>>>> alias it did not have the expected effect.
>>
>>>>>>>> If you had told us at the outset that what you're looking for is how to
>>>>>>>> do multiline comments, we could have answered more usefully.
>>
>>>>>>> Sorry if my intention was not clear from the outset.
>>>>>>> ...
>>
>>>>>> A multi-line comment definition from c.l.f. several years ago
>>
>>>>>> \ Block comment (* ... *)
>>>>>> : (*
>>>>>> begin
>>>>>>> in @ source nip< if
>>>>>> bl word count s" *)" compare
>>>>>> else refill then 0> >>>> until ; immediate
>>
>>>>> I thought ( and ) where allready provided as block comments ? I
>>>>> originally did them to cope with nesting, but was told they don't allow
>>>>> that.
>>
>>>>> \ word called ( which just drops input characters until it hits the
>>>>> corresponding )
>>>>> : ( IMMEDIATE
>>>>> BEGIN
>>>>> ')' PARSE + SOURCE + > >>> WHILE
>>>>> REFILL 0> >>> UNTIL THEN
>>>>> ;
>>
>>>>> ?
>>
>>>> You could do that but any source containing a comment that spanned
>>>> lines wouldn't be portable.
>>
>>> ( comments can span multiple lines if the file word set is present, see
>>> the ANS Forth standard 11.6.1.0080
>>
>>> However the definition is not ANS Forth because the IMMEDIATE is in the
>>> wrong place, it should be
>>
>>> : (
>>> BEGIN
>>> ')' PARSE + SOURCE + > > WHILE
>>> REFILL 0> > UNTIL THEN
I think the thing is with Forth to realise that there is no 'floor' you
can just define the word to do the right thing with another word,
especially if you make it an IMMEDIATE. ;)
I'll get round to editing my stuff so that IMMEDIATE isn't immediate
soon as I have chance. Appologies to Tarkin if he's folowed this thread
and finds I've screwed up on this one. !
Best regards to all.
Chris
Chris Hinsley
> (I'm responding in the main because I got bitten more than a few times
> by Jones' Forth. Still, it was a very very good learning experience!)
Amen to that !
He dosn't get enough credit for the school of Zen he's punting !!!!
Chris
Coos Haak
In other contexts I might assume CELL would be a constant, with value ``1
CELLS'' ;-)
Gerry Jackson
Nope
I might be wrong in
> that.
Yes
> I might need to do some hasty editing !
If you wish, you could always leave it as is until the system is fully
loaded and then redefine IMMEDIATE to be ANS Forth standard - but that
might be confusing.
>
> JonesForth gets me again !
You're not the first and won't be the last.
>
> I prefer to have it at the begining if that's legal because I like to
> know that the word is IMMEDIATE 'up front' rather than at the end of the
> definition (possibly several pages down). And yes, I know your all going
> to start saying 'but you should never have a word several pages long...' :)
>
> Chris
>
--
Gerry
BruceMcF
> In other contexts I might assume CELL would be a constant, with value ``1
> CELLS'' ;-)
Quite, its not the name I'd expect for "add 'n' cells". Maybe ``ncell
+'' or something like that.
Albert van der Horst
Very safe languages (ADA), scripting languages and assembler
prefer a "to end of line comment".
In assembler and scripting the argument is: a line can contain
anything.
This argument applies to Forth. So \ is better than (. And
attempts at nested comment make things worse.
Teach you editor to comment out a whole block line by line,
and get rid of them in one go. Much less error-prone.
\ \ I commented this definition out:
\ : champion "We gaan naar rome !@#$%^()*&!&!&*!* *) !!!" TYPE ;
\ more lines
\ more lines
As you see from the first line it nests easily.
>
>Regards
>
>Chris
>
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst
Coos Haak <chf...@hccnet.nl> wrote:
<SNIP>
>
>The ANS/ISO standard has the word CELLS (plural) for this.
>No Forth that I have accepts numbers beginning with a plus sign.
lina ?
wina ?
>--
>Coos
Groetjes Albert
Elizabeth D Rather
...
>> However the definition is not ANS Forth because the IMMEDIATE is in
>> the wrong place, it should be
>>
>> : (
>> BEGIN
>> ')' PARSE + SOURCE + =
>> WHILE
>> REFILL 0=
>> UNTIL THEN
>> ; IMMEDIATE
>>
>> IMMEDIATE isn't an immediate word.
>
> I understood IMMEDIATE to work on the currently being defined word ? And
> it was only a convention that it came at the end. I might be wrong in
> that. I might need to do some hasty editing !
>
> JonesForth gets me again !
IMMEDIATE works on the *most recently defined* word.
> I prefer to have it at the begining if that's legal because I like to
> know that the word is IMMEDIATE 'up front' rather than at the end of the
> definition (possibly several pages down). And yes, I know your all going
> to start saying 'but you should never have a word several pages long...' :)
Aaaakkkk! We were just fussing about definitions over 3 or 4 lines long
(and there are some, but hopefully not many) and you're talking about
*several pages*? Factor, man! (I love fulfilling expectations ;-)
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Coos Haak
> In article <mpe8xgmzsafk.16arbse8gzd36$.d...@40tude.net>,
> Coos Haak <chf...@hccnet.nl> wrote:
> <SNIP>
>>
>>The ANS/ISO standard has the word CELLS (plural) for this.
>>No Forth that I have accepts numbers beginning with a plus sign.
>
> lina ?
> wina ?
>
>>--
>>Coos
>
> Groetjes Albert
>
> --
Of course (slaps forehead), but not CHForth, Win32Forth, Gforth.
Chris Hinsley
>> know that the word is IMMEDIATE 'up front' rather than at the end of the
>> definition (possibly several pages down). And yes, I know your all going
>> to start saying 'but you should never have a word several pages long...' :)
>
> Aaaakkkk! We were just fussing about definitions over 3 or 4 lines
> long (and there are some, but hopefully not many) and you're talking
> about *several pages*? Factor, man! (I love fulfilling expectations
> ;-)
>
> Cheers,
> Elizabeth
Heah, I inherited the code from Jones ! I didn't have time to
completely refactor it all as well as get it passing the ANS tests and
doing things in a more Forth like way. ;)
Bet you handle a bull whip well. ;)
Chris
Elizabeth D Rather
The more I hear about Jonesforth the more I wonder why so many people
get stuck with it. Someone should post a huge sign saying "Warning!
Here be dragons!"
> Bet you handle a bull whip well. ;)
If I ever meet Jones...
Chris Hinsley
> On 6/8/11 12:25 PM, Chris Hinsley wrote:
>>>> I prefer to have it at the begining if that's legal because I like to
>>>> know that the word is IMMEDIATE 'up front' rather than at the end of the
>>>> definition (possibly several pages down). And yes, I know your all going
>>>> to start saying 'but you should never have a word several pages
>>>> long...' :)
>>>
>>> Aaaakkkk! We were just fussing about definitions over 3 or 4 lines
>>> long (and there are some, but hopefully not many) and you're talking
>>> about *several pages*? Factor, man! (I love fulfilling expectations ;-)
>>>
>>> Cheers,
>>> Elizabeth
>>
>> Heah, I inherited the code from Jones ! I didn't have time to completely
>> refactor it all as well as get it passing the ANS tests and doing things
>> in a more Forth like way. ;)
>
> The more I hear about Jonesforth the more I wonder why so many people
> get stuck with it. Someone should post a huge sign saying "Warning!
> Here be dragons!"
>
>> Bet you handle a bull whip well. ;)
>
> If I ever meet Jones...
>
>
> Cheers,
> Elizabeth
As I said earlier to Mark.
Paul Rubin
> The more I hear about Jonesforth the more I wonder why so many people
> get stuck with it.
1) It's self-hosting (starts with pure asm rather than metacompilation),
2) It's about 100x better commented than any other asm Forth that I've
ever seen.
Both of the above make it much easier to learn from.
Chris Hinsley
And in the end, when you re-implament it all you learn a huge ammount.
Chris
Harold
> I thought ( and ) where allready provided as block comments ? I
> originally did them to cope with nesting, but was told they don't allow
> that.
>
> \ word called ( which just drops input characters until it hits the
> corresponding )
> : ( IMMEDIATE
> ')' PARSE + SOURCE + =
> WHILE
> REFILL 0=
> UNTIL THEN
> ;
>
There's still a problem in that ( and ) don't allow you to comment out
[ELSE] or [THEN].
So for example:
0 [IF]
." first part"
( [ELSE] )
." second part"
[THEN]
will print "second part".
That's because Forth-94 says that [IF] and [ELSE] have to PARSE AND
DISCARD everything until the matching [ELSE] or [THEN].
When the ( is parsed and discarded, the parser next parses and
processes [ELSE], even though it appears to be commented out.
-- Harold
BruceMcF
> On Jun 7, 5:32 am, Chris Hinsley <chris.hins...@gmail.com> wrote:
>
> > I thought ( and ) where allready provided as block comments ? I
> > originally did them to cope with nesting, but was told they don't allow
> > that.
>
> > \ word called ( which just drops input characters until it hits the
> > corresponding )
> > : ( IMMEDIATE
> > BEGIN
> > ')' PARSE + SOURCE + =
> > WHILE
> > REFILL 0=
> > UNTIL THEN
> > ;
>
> > ?
>
> There's still a problem in that ( and ) don't allow you to comment out
> [ELSE] or [THEN].
> So for example:
>
> 0 [IF]
> ." first part"
> ( [ELSE] )
> ." second part"
> [THEN]
>
> will print "second part".
>
Why is that a problem? If its absolutely needed to comment out
[ELSE] ...
0 [IF] first part ([ELSE]) second part [THEN]
... seems to work. At least, it did in Win32Forth.
Elizabeth D Rather
If you want to learn Forth, isn't it better to have a free copy of
either SwiftForth or VFX? Standard, extensively documented, good user
interface, ... ? And you don't have to bother with re-implementing, or
sweating out all the idiosyncrasies and bad code, you can just start
using it.
Andrew Haley
Yabbut, everything you learn is wrong, or at best grossly misleading.
Imagine learning your all of your science from the Discovery
Institute.
Andrew.
Mark Wills
wrote:
>
> Yabbut, everything you learn is wrong, or at best grossly misleading.
> Imagine learning your all of your science from the Discovery
> Institute.
>
> Andrew.
'Tis true. I had to rewrite large parts of my Forth system, parts I
thought were done and dusted when I came to implement features like
DOES>
From memory, I re-wrote (at least) strings, variables, and constants.
However, it is really well commented. It really contributed to the
"Oh! I seeeeeeee!" moments in a major way!
Mark
Andrew Haley
> On Jun 9, 12:58?pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>>
>> Yabbut, everything you learn is wrong, or at best grossly misleading.
>> Imagine learning your all of your science from the Discovery
>> Institute.
>
> thought were done and dusted when I came to implement features like
> DOES>
>
> From memory, I re-wrote (at least) strings, variables, and constants.
>
> However, it is really well commented. It really contributed to the
> "Oh! I seeeeeeee!" moments in a major way!
An earlier generation got the same sort of thing from "Threaded
Interpretive Languages" by R.G. Loeliger.
Andrew.
Anton Ertl
>> And in the end, when you re-implament it all you learn a huge ammount.
>>
>> Chris
>
>
>If you want to learn Forth, isn't it better to have a free copy of
>either SwiftForth or VFX? Standard, extensively documented, good user
>interface, ... ? And you don't have to bother with re-implementing, or
>sweating out all the idiosyncrasies and bad code, you can just start
>using it.
That would be the rational thing if people just wanted to learn to use
Forth. But it seems that a lot of people are fascinated with the
implementation of Forth (even one that has deficiencies), or probably
more accurately, with a programming language where the implementation
is sufficiently simple that they can play around with it. That's what
attracted me, too.
So if many people are coming to Forth from that angle, all the
preaching that the vendors do to stop fussing around with implementing
Forth and start writing applications will fall an deaf ears. With a
little luck some of the people who are fascinated with the
implementation will eventually write applications, but they have to go
through the implementation stage first.
- 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
EuroForth 2010: http://www.euroforth.org/ef10/
Anton Ertl
Yes, but that's even slower AFAIK. At least in the 1995 time frame
gcc-2.x -O0 came out 6 times slower than gcc-2.x -O, whereas gcc-4.x
-O is only two time slower then gcc-2.x -O (and if our workarounds
work, most gcc-4.x versions are competetive with gcc-2.x).
BruceMcF
wrote:
So the ideal might be something like a 'conservative optimizations
only' option, if the class of 'aggressive optimizations' was well
defined wrt the gforth kernal?
Paul Rubin
> So if many people are coming to Forth from that angle, all the
> preaching that the vendors do to stop fussing around with implementing
> Forth and start writing applications will fall an deaf ears. With a
> little luck some of the people who are fascinated with the
> implementation will eventually write applications, but they have to go
> through the implementation stage first.
I think many (most?) Lisp programmers go through the same thing.
Elizabeth D Rather
> Elizabeth D Rather<era...@forth.com> writes:
>> On 6/8/11 1:18 PM, Chris Hinsley wrote:
> [JonesForth]
>>> And in the end, when you re-implament it all you learn a huge ammount.
>>>
>>> Chris
>>
>>
>> If you want to learn Forth, isn't it better to have a free copy of
>> either SwiftForth or VFX? Standard, extensively documented, good user
>> interface, ... ? And you don't have to bother with re-implementing, or
>> sweating out all the idiosyncrasies and bad code, you can just start
>> using it.
>
> That would be the rational thing if people just wanted to learn to use
> Forth. But it seems that a lot of people are fascinated with the
> implementation of Forth (even one that has deficiencies), or probably
> more accurately, with a programming language where the implementation
> is sufficiently simple that they can play around with it. That's what
> attracted me, too.
>
> So if many people are coming to Forth from that angle, all the
> preaching that the vendors do to stop fussing around with implementing
> Forth and start writing applications will fall an deaf ears. With a
> little luck some of the people who are fascinated with the
> implementation will eventually write applications, but they have to go
> through the implementation stage first.
I have nothing against people who want to experiment with implementation
strategies, but they will find it easier and do a better job if they've
learned to use Forth first. SwiftForth, at least, comes with lots of
source (in addition to detailed documentation), so you can see many
examples of code.
Anton Ertl
>So the ideal might be something like a 'conservative optimizations
>only' option, if the class of 'aggressive optimizations' was well
>defined wrt the gforth kernal?
Actually, the one "optimization" that gives us most trouble cannot be
disabled; someone developed a general approach and wrote a gcc patch
for defusing this problem, but the gcc maintainers have shown no
interest in adopting this patch or its approach.
My guess is that the other optimizations give us little trouble
because gcc is (fortunately) not capable of applying them for Gforth.
Pablo Hugo Reda
> Elizabeth D Rather <erat...@forth.com> writes:
>
> >On 6/8/11 1:18 PM, Chris Hinsley wrote:
> [JonesForth]
> >> And in the end, when you re-implament it all you learn a huge ammount.
>
> >> Chris
>
> >If you want to learn Forth, isn't it better to have a free copy of
> >either SwiftForth or VFX? Standard, extensively documented, good user
> >interface, ... ? And you don't have to bother with re-implementing, or
> >sweating out all the idiosyncrasies and bad code, you can just start
> >using it.
>
> That would be the rational thing if people just wanted to learn to use
> Forth. But it seems that a lot of people are fascinated with the
> implementation of Forth (even one that has deficiencies), or probably
> more accurately, with a programming language where the implementation
> is sufficiently simple that they can play around with it. That's what
> attracted me, too.
>
> So if many people are coming to Forth from that angle, all the
> preaching that the vendors do to stop fussing around with implementing
> Forth and start writing applications will fall an deaf ears. With a
> little luck some of the people who are fascinated with the
> implementation will eventually write applications, but they have to go
> through the implementation stage first.
>
> - anton
I agree with Anton, forth simplisity and how work is very atractive,
I come to forth searching a interpreter languaje for scripting,
when read more about forth I learn and see what is wrong with other
languajes,
I change my form of programing in C and DELPHI too, and the result is
clear.. IMHO
the aproach of forth is superior
There are much forth implementions and few real algorithm well
programed for learn.
pablo
Albert van der Horst
BruceMcF <agi...@netscape.net> wrote:
>On Jun 8, 1:49=A0pm, Coos Haak <chfo...@hccnet.nl> wrote:
>> Op Tue, 7 Jun 2011 23:29:08 -0700 (PDT) schreef Colin MacIntyre:
>>
>>
>>
>> > On Wednesday, June 8, 2011 12:23:48 PM UTC+8, Ed wrote:
>> >> Anton Ertl wrote:
>> >>> "Ed" <nos...@invalid.com> writes:
>> >>> >If optimizers currently do:
>>
>> >>> > =A0 =A0swap over =A0 substitute tuck
>> >>> > =A0 =A0over over =A0 substitute 2dup
>> >>> > =A0 =A0rot rot =A0 substitute -rot
>> >>> > =A0 =A0...
>>
>> >>> >I see no logical reason to exclude others.
>>
>> >>> Each optimization has costs: coding, testing, compilation speed, and
>off
>> >>> rarely and/or that should not occur in well-written code (how these
>> >>> factors are weighted are the compiler writer's decision).
>>
>> >> I've yet to hear of a prospective customer who rejected an optimizing
>> >> compiler because it did its job too well!
>>
>ed.
>> >> Why? =A0Because the customer expects it.
>>
>> > Optimizing is also fun, and helps to keep the dictionary small and easy=
> to remember. I optimize cell+, cell-, and any derivatives to just one word=
>, 'cell' which is used like:
>>
>> > =A0 =A0 -2 cell
>> > =A0 =A0 +31 cell
>>
>> The ANS/ISO standard has the word CELLS (plural) for this.
>> No Forth that I have accepts numbers beginning with a plus sign.
>
>``CELLS +''
I like [] better (an iforthism).
BruceMcF
wrote:
> Actually, the one "optimization" that gives us most trouble cannot be
> disabled; someone developed a general approach and wrote a gcc patch
> for defusing this problem, but the gcc maintainers have shown no
> interest in adopting this patch or its approach.
Hence 'ideal': ideally it could be, but the gcc maintainers refuse to
support it.
Ecki
> I have nothing against people who want to experiment with
> implementation strategies, but they will find it easier and do a
> better job if they've learned to use Forth first. SwiftForth, at
> least, comes with lots of source (in addition to detailed
> documentation), so you can see many examples of code.
Wouldn't this mean that it's sufficient to simply (better) document
simple systems?
Just started with Forth because of the possibility of full machine
control at a higher abstraction level and the ability to have both
compiled code and an interpreter for trying things on the fly. So I
choose to use ForthOS on an old laptop, even if it's lacking some maybe
important things (e.g. multiple keymap support).
Most other languages seem to either limit the user's abilities to
access low level details easily, or seem very limited in working on a
higher level of abstraction, or don't support both compiled and
interpreted code.
I can't believe that someone will start hacking around in the heart of
a system before getting to a sufficient knowledge level of the language
that system is implemented with (and I can't see the problem if one
does), so another point is surely that learning the language becomes far
more interesting (and practically relevant) with the ability to --
slightly -- modify your working environment than with the 100th version
of hello_world.
But maybe I'm simply on the wrong way...
Andrew Haley
> Elizabeth D Rather wrote:
>
>> I have nothing against people who want to experiment with
>> implementation strategies, but they will find it easier and do a
>> better job if they've learned to use Forth first. SwiftForth, at
>> least, comes with lots of source (in addition to detailed
>> documentation), so you can see many examples of code.
>
> Wouldn't this mean that it's sufficient to simply (better) document
> simple systems?
Peter Knaggs, me, and a few others were talking about doing a really
clean, really simple ANS-compatible Forth, with CORE in assembly
language and the rest bootstrapped from that. It's still in the
conceptual stage, I think. :-)
It has long been my opinion that an ANS-compatible Forth woouldn't be
much more complex than fig-FORTH was. I'd love to prove it.
Andrew.
Andrew Haley
> BruceMcF <agi...@netscape.net> writes:
>>So the ideal might be something like a 'conservative optimizations
>>only' option, if the class of 'aggressive optimizations' was well
>>defined wrt the gforth kernal?
>
> Actually, the one "optimization" that gives us most trouble cannot be
> disabled; someone developed a general approach and wrote a gcc patch
> for defusing this problem, but the gcc maintainers have shown no
> interest in adopting this patch or its approach.
As far as I am aware gcc maintainers have never even seen that patch.
I don't think it was submitted.
Andrew.
Ecki
> Peter Knaggs, me, and a few others were talking about doing a really
> clean, really simple ANS-compatible Forth, with CORE in assembly
> language and the rest bootstrapped from that. It's still in the
> conceptual stage, I think. :-)
I'd appreciate it - but if possible, please with AltGr-support (right
alt key), so I had to only modify drivers.key_map & Co. :) (and
multiple screen resolutions, and...). Count on me as a beta tester,
it's nice for my otherwise nearly useless old notebook.
E.
Mark Wills
wrote:
A really simple ANS-System is fairly, er, simple, I guess. The trouble
is, is doesn't get you very far.
What I would really love is a Forth system that BOOTS into Forth (no
underlying OS) on a PC that has:
File System
Blocks System
Serial Ports
TCP/IP
Various high resolution screen modes (VGA, SVGA etc)
Not so simple now, is it?
That's the problem.