Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #39232 > unrolled thread
| Started by | chitselb <chitselb@gmail.com> |
|---|---|
| First post | 2015-05-23 19:27 -0700 |
| Last post | 2015-05-24 14:06 +0000 |
| Articles | 20 on this page of 151 — 19 participants |
Back to article view | Back to comp.lang.forth
unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-23 19:27 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-23 20:27 -0700
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-24 13:44 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:36 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-24 23:16 +0200
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 15:57 -0700
Re: unexpected +LOOP behavior Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-25 02:21 +0200
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-24 15:21 -1000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 19:49 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 18:22 -0700
Re: unexpected +LOOP behavior "WJ" <w_a_x_man@yahoo.com> - 2015-05-26 17:20 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 14:15 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 08:37 -1000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 15:09 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 09:19 -1000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 17:08 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 15:42 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 19:30 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 17:45 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 21:33 -0400
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 14:08 +0200
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 06:32 -0700
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 16:15 +0200
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 14:32 -1000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 08:30 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 17:15 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-29 21:05 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 01:41 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-24 23:26 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:33 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 10:56 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-25 11:28 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 14:33 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 12:57 -0700
Re: unexpected +LOOP behavior humptydumpty <ouatubi@gmail.com> - 2015-05-25 23:01 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:21 +0000
Re: unexpected +LOOP behavior albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-26 23:59 +0000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 09:15 +0000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 10:06 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 12:03 -0400
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 16:23 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 12:39 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-27 22:14 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 17:13 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-27 23:36 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 18:06 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 10:35 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:16 +0100
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 09:42 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 16:16 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 15:24 +0100
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:32 -0400
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 23:59 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 19:31 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-27 23:11 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-28 12:21 +0100
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-28 12:24 +0100
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 10:53 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:19 +0100
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:51 +0000
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 17:48 +0200
Re: unexpected +LOOP behavior Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-29 02:08 +0200
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 08:25 +0000
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:40 +0100
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:16 +0000
Re: unexpected +LOOP behavior albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-29 18:43 +0000
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 20:08 +0100
x86 tricks Lars Brinkhoff <lars.spam@nocrew.org> - 2015-06-05 09:42 +0200
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 09:32 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 09:40 +0000
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 11:17 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 15:49 +0000
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 17:45 +0100
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 16:53 +0000
Re: x86 tricks rickman <gnuarm@gmail.com> - 2015-06-07 13:20 -0400
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-08 07:18 +0000
Re: x86 tricks Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-08 17:18 +0200
Re: x86 tricks Tessa Bonting <tessa.bonting@gmail.com> - 2015-06-08 08:42 -0700
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 09:47 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-07 15:05 +0000
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-07 17:49 +0100
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 13:19 +0100
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:38 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-23 21:33 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-23 22:10 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-23 22:20 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 21:13 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:34 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 22:04 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-28 01:27 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-28 03:20 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-28 04:13 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 04:23 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 11:28 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 18:32 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 18:53 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-23 22:26 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-23 21:37 -1000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 10:24 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:40 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-25 14:08 +0200
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-25 17:27 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:47 -1000
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:33 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 12:53 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 13:05 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:49 -1000
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 18:03 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 16:44 -1000
Re: unexpected +LOOP behavior humptydumpty <ouatubi@gmail.com> - 2015-05-25 22:56 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-26 08:05 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:43 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-24 08:29 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-24 15:44 +0000
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-27 00:57 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-06-05 13:11 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 12:24 -1000
Re: unexpected +LOOP behavior JennyB <jennybrien@googlemail.com> - 2015-06-06 13:29 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-07 14:56 +0000
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-06-07 10:38 -1000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-08 08:08 +0000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 10:01 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:40 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 11:29 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-25 09:51 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 10:44 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-25 12:34 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 12:59 -0700
unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-24 01:39 -0700
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-24 14:46 +0200
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:17 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:48 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 18:15 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 12:35 +0000
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-25 17:27 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 18:16 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 16:17 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 17:16 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 17:50 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 18:47 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 20:01 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 20:29 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 20:32 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-26 08:03 +0000
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-26 01:10 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 22:31 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 20:07 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 20:20 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 22:00 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 02:41 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-24 14:06 +0000
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-05-27 14:08 +0200 |
| Message-ID | <13nbq4ulnyxs3$.1qdrdju4v9nou.dlg@40tude.net> |
| In reply to | #39344 |
Op Tue, 26 May 2015 17:45:30 -0700 (PDT) schreef chitselb:
> On Tuesday, May 26, 2015 at 7:30:36 PM UTC-4, rickman wrote:
>> On 5/26/2015 6:42 PM, chitselb wrote:
>>> If I were to hazard a guess, state-smart words did two things instead of one, which was very unForthy. Also they had to be immediate, and were less reusable.
>>
>> Reusable? Can you explain that?
>>
>> --
>>
>> Rick
>
> Not good for reuse... hmm... Well, when is the last time you invoked something like this in a definition?
>
> [COMPILE] {some-immediate-word}
Since when is [COMPILE] state smart?
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | chitselb <chitselb@gmail.com> |
|---|---|
| Date | 2015-05-27 06:32 -0700 |
| Message-ID | <876769de-3e65-4e1b-a69b-64b00d434dfe@googlegroups.com> |
| In reply to | #39355 |
On Wednesday, May 27, 2015 at 8:20:03 AM UTC-4, Coos Haak wrote:
> Op Tue, 26 May 2015 17:45:30 -0700 (PDT) schreef chitselb:
>
> > On Tuesday, May 26, 2015 at 7:30:36 PM UTC-4, rickman wrote:
> >> On 5/26/2015 6:42 PM, chitselb wrote:
> >>> If I were to hazard a guess, state-smart words did two things instead of one, which was very unForthy. Also they had to be immediate, and were less reusable.
> >>
> >> Reusable? Can you explain that?
> >>
> >> --
> >>
> >> Rick
> >
> > Not good for reuse... hmm... Well, when is the last time you invoked something like this in a definition?
> >
> > [COMPILE] {some-immediate-word}
>
> Since when is [COMPILE] state smart?
> --
> Coos
>
> CHForth, 16 bit DOS applications
> http://home.hccnet.nl/j.j.haak/forth.html
It isn't, but it could be used to compile, say, a state-smart word
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-05-27 16:15 +0200 |
| Message-ID | <kutsp556fx7i.jn4iexrxdlar.dlg@40tude.net> |
| In reply to | #39356 |
Op Wed, 27 May 2015 06:32:05 -0700 (PDT) schreef chitselb:
> On Wednesday, May 27, 2015 at 8:20:03 AM UTC-4, Coos Haak wrote:
>> Op Tue, 26 May 2015 17:45:30 -0700 (PDT) schreef chitselb:
>>
>>> On Tuesday, May 26, 2015 at 7:30:36 PM UTC-4, rickman wrote:
>>>> On 5/26/2015 6:42 PM, chitselb wrote:
>>>>> If I were to hazard a guess, state-smart words did two things instead of one, which was very unForthy. Also they had to be immediate, and were less reusable.
>>>>
>>>> Reusable? Can you explain that?
>>>>
>>>> --
>>>>
>>>> Rick
>>>
>>> Not good for reuse... hmm... Well, when is the last time you invoked something like this in a definition?
>>>
>>> [COMPILE] {some-immediate-word}
>>
>> Since when is [COMPILE] state smart?
>> --
>> Coos
>>
>> CHForth, 16 bit DOS applications
>> http://home.hccnet.nl/j.j.haak/forth.html
>
> It isn't, but it could be used to compile, say, a state-smart word
POSTPONE too.
I've not used [COMPILE] for ages. POSTPONE is sufficient.
Can't remember when I used POSTPONE with a state-smart word,
except somewhere in my metacompiler. But there I know what I'm doing.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-05-26 14:32 -1000 |
| Message-ID | <0eednaXfBMYWjfjInZ2dnUU7-X-dnZ2d@supernews.com> |
| In reply to | #39339 |
On 5/26/15 12:42 PM, chitselb wrote: > If I were to hazard a guess, state-smart words did two things instead of one, which was very unForthy. Also they had to be immediate, and were less reusable. > Yes, generally words that do different things in different circumstances are troublesome. As compilers become more advanced and implementation strategies more sophisticated, there's also a desire to make STATE itself either less prominent. Many would like to see it gone altogether. Cheers, Eliza -- ================================================== 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." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-27 08:30 +0000 |
| Message-ID | <2015May27.103000@mips.complang.tuwien.ac.at> |
| In reply to | #39338 |
rickman <gnuarm@gmail.com> writes:
>Just to refresh more of my memory, why was state-smartness eschewed?
@InProceedings{ertl98,
author = {M. Anton Ertl},
title = {\texttt{State}-smartness --- Why it is Evil and How
to Exorcise it},
booktitle = {EuroForth'98 Conference Proceedings},
year = {1998},
address = {Schlo\ss{} Dagstuhl},
url = {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
abstract = {\texttt{State}-smart words provide a number of unpleasant
surprises to their users. They are applied in two
contexts, and they fail in both: 1) for providing an
arbitrary combination of interpretation and
compilation semantics; 2) for optimizing with a
special implementation of the (default) compilation
semantics. This paper discusses these issues and
shows programmers and system implementors how to
avoid \texttt{state}-smart words. It also reports our
experiences in converting the \texttt{state}-smart
words in Gforth into a clean solution: little work
and few problems.}
}
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-27 17:15 -0400 |
| Message-ID | <mk5c2b$re4$2@dont-email.me> |
| In reply to | #39351 |
On 5/27/2015 4:30 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> Just to refresh more of my memory, why was state-smartness eschewed?
>
> @InProceedings{ertl98,
> author = {M. Anton Ertl},
> title = {\texttt{State}-smartness --- Why it is Evil and How
> to Exorcise it},
> booktitle = {EuroForth'98 Conference Proceedings},
> year = {1998},
> address = {Schlo\ss{} Dagstuhl},
> url = {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
> abstract = {\texttt{State}-smart words provide a number of unpleasant
> surprises to their users. They are applied in two
> contexts, and they fail in both: 1) for providing an
> arbitrary combination of interpretation and
> compilation semantics; 2) for optimizing with a
> special implementation of the (default) compilation
> semantics. This paper discusses these issues and
> shows programmers and system implementors how to
> avoid \texttt{state}-smart words. It also reports our
> experiences in converting the \texttt{state}-smart
> words in Gforth into a clean solution: little work
> and few problems.}
> }
Thank you. I have downloaded it and will give it some attention.
--
Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-29 21:05 -0700 |
| Message-ID | <1e7de477-8daa-44ea-a405-ffae9ebc2762@googlegroups.com> |
| In reply to | #39333 |
On Tuesday, May 26, 2015 at 11:37:37 AM UTC-7, Elizabeth D. Rather wrote: > On 5/26/15 8:15 AM, rickman wrote: > > On 5/26/2015 1:20 PM, WJ wrote: > >> Bernd Paysan wrote: > >> > >>>> But why are some Forth programmers so keen on their "all bits set" > >>>> flag? Well, you can do neat things with it. > >>>> > >>>> : >CHAR DUP 9 > 7 AND + ASCII 0 + ; > >>>> > >>>> This will convert a digit to its ASCII representation. True, it > >>>> is a clever piece of programming, but in our opinion it is bad > >>>> style. Why? Because you are using a flag as a bitmask, which is a > >>>> completely different datatype. Although there is no such thing as > >>>> "data typing" in Forth, this way of programming makes it > >>>> difficult to understand and maintain a program, which the > >>>> ANS-Forth standard acknowledges: > >>> > >>> Honestly, this is only a problem if you don't know that idiom. > >> > >> That code is unreadable and unmaintainable. It's very hard > >> to figure out how it accomplishes its task. I would not > >> pay a programmer to produce code like that. > >> > >> This is somewhat more understandable: > >> > >> : >char > >> dup 9 > if [char] A 10 - else [char] 0 then > >> + ; > > > > If you have any reason to look at the definition of >char then I can't > > see how you would not understand how it works. Perhaps this would be a > > better definition... > > > > \ Convert n to ASCII char > > : >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ; > > > > Lol, saying it is unreadable and unmaintainable is a bit of a stretch. I > > think that exact code has been read and understood as well as maintained > > for many years now. I am pretty sure I have seen something similar to > > it way back when I was learning assembly language. I think it took me > > two minutes to see what it was doing. > > Indeed, proper documentation as in rickman's version above is essential > to readable & maintainable code. Neither of the previous versions is > acceptable, although I find the shorter code quite clear (and, as > rickman notes, it's been around for many years). I would have preferred > [CHAR] instead of ASCII, however, as it's Standard. > > Cheers, > Elizabeth You say that Rickman's version is the best (readable & maintainable) --- am I to assume that my own version is one of the previous versions that is not acceptable?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-25 01:41 -0400 |
| Message-ID | <mjucjs$k0p$1@dont-email.me> |
| In reply to | #39257 |
On 5/24/2015 5:16 PM, Hans Bezemer wrote: > rickman wrote: > >> On 5/24/2015 7:44 AM, Hans Bezemer wrote: >>> >>> Forth-83 added lots of horrible, "clever" tricks that made the language >>> almost unusable. "All bits set" for TRUE was another one. Really, it's no >>> wonder Forth went through the drain in the late 80-ies. >> >> What is wrong with using -1 for a logic TRUE? > Ok, here we go again: > > Another nice topic for a flame war is the value of truth. In > ANS-Forth the 'TRUE' has the value "-1", which means all bits are > set. Which is very clever. You can 'XOR', 'OR', 'AND' and > 'INVERT' it with any other value and it will behave as logical > value. But "the all bits set" flag has its drawbacks too. Let's > see what the ANS-Forth standard says about flags: > > "A FALSE flag is a single-cell datum with all bits unset, and a > TRUE flag is a single-cell datum with all bits set. While Forth > words which test flags accept any non-null bit pattern as true, > there exists the concept of the well-formed flag. If an operation > whose result is to be used as a flag may produce any bit-mask > other than TRUE or FALSE, the recommended discipline is to > convert the result to a well-formed flag by means of the Forth > word 0<> so that the result of any subsequent logical operations > on the flag will be predictable. In addition to the words which > move, fetch and store single-cell items, the following words are > valid for operations on one or more flag data residing on the > data stack: AND OR XOR INVERT" > > We highly recommend the discipline of converting a non-zero value > to a well-formed flag. But we don't understand why 'INVERT' is a > valid way to manipulate a flag. We'll try to explain you why. > > Forth traditionally has no specific logical operators. Instead, > binary operators were used. This put 'INVERT' (or 'NOT' as it was > called in Forth-79) in a difficult position. 'INVERT'ing any > non-zero value will result in a non-zero value, except when all > bits are set. > > That is why '0=' was introduced, a full-fledged logical operator. > So why use 'INVERT' when you want to perform a logical operation? > Another quote: > > "Since a "char" can store small positive numbers and since the > character data type is a sub-range of the unsigned integer data > type, C! must store the n least-significant bits of a cell (8 <= > n <= bits/cell). Given the enumeration of allowed number > representations and their known encodings, "TRUE xx C! xx C@" > must leave a stack item with some number of bits set, which will > thus will be accepted as non-zero by IF." > > This is another problem of using "all bits set" as a true flag: > you store a well formed flag in an address unit that should > easily be able to handle it and you'll never get it back. A flag > is a boolean and can have two values: either true or false. The > smallest unit that can hold a boolean is a bit. ANS-Forth > programmers are denied that privilege. > > But why are some Forth programmers so keen on their “all bits set” > flag? Well, you can do neat things with it. > > : >CHAR DUP 9 > 7 AND + ASCII 0 + ; > > This will convert a digit to its ASCII representation. True, it > is a clever piece of programming, but in our opinion it is bad > style. Why? Because you are using a flag as a bitmask, which is a > completely different datatype. Although there is no such thing as > “data typing” in Forth, this way of programming makes it > difficult to understand and maintain a program, which the > ANS-Forth standard acknowledges: > > "The discipline of circumscribing meaning which a program may > assign to various combinations of bit patterns is sometimes > called data typing. Many computer languages impose explicit data > typing and have compilers that prevent ill-defined operations. > Forth rarely explicitly imposes data-type restrictions. Still, > data types implicitly do exist, and discipline is required, > particularly if portability of programs is a goal. In Forth, it > is incumbent upon the programmer (rather than the compiler) to > determine that data are accurately typed." > > That is why 4tH uses "1" as a true flag. Usually, it won't make > much difference. Except when you use 'INVERT' to invert a flag or > intend to make obfuscated programs. If you use '0=' instead, you > won't run in any trouble, not even when you port your program to > ANS-Forth. Clarity may introduce a little overhead, but in this > age of multi-gigaherz machines, who is counting? Have you ever seen the futuristic space show "Red Dwarf"? One character is a person playing the descendent of a cat. In a scene some large fiery space object is hurtling toward them and the cat asks, "What is it?" One character explains the physical makeup and the cat turns to another character and asks, "What is it?" This person explains that it is the remnant of something with a simpler description and the cat turns to a third character and asks, "What is it?" This final character says it is a big fiery ball of death headed straight for them! The cat understand this... So... What is wrong with using -1 for a logic TRUE? I think you describe three problems. The first I don't get because you say there are no logical operators, but 0= seems to be exactly that. I don't see the problem. The second problem is that storing a flag in something smaller than a cell will not return the flag exactly. Yes... duh! Again, I don't see the problem. The third problem seems to revolve around not the actual value of the flag, but the fact that programmers rely on the value of the flag in operations. How is that the fault of the definition of flag. If you define a true flag as the value 1 and a false flag as 0, then programmers will do things like adding the flag to an integer. Still a problem according to you and not fixed. Or do I misunderstand your writing and a true is the character "1" and false the character "0"? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-05-24 23:26 -0700 |
| Message-ID | <8ce093c2-0ec2-45e7-9091-5d66216ff253@googlegroups.com> |
| In reply to | #39274 |
> So... What is wrong with using -1 for a logic TRUE? > > I think you describe three problems. The first I don't get because you > say there are no logical operators, but 0= seems to be exactly that. I > don't see the problem. 0= is a comparison operation. It's the shortcut for 0 = Basically it's an '=' operation > > The second problem is that storing a flag in something smaller than a > cell will not return the flag exactly. Yes... duh! Again, I don't see > the problem. > If you have some memory allocation scheme and keep 'dirty' flags in a buffer, you may want to use one byte for the flag, not an entire cell. Think you have 1K flags. This is 4K bytes for a 32bit system, opposed to only 1K. I'm speaking of microcontrollers here, where 3K of RAM can be huge. I know, you may say that with some custom code you can store the flags in one bit each, with proper time consuming bitmask operations. > The third problem seems to revolve around not the actual value of the > flag, but the fact that programmers rely on the value of the flag in > operations. How is that the fault of the definition of flag. If you > define a true flag as the value 1 and a false flag as 0, then > programmers will do things like adding the flag to an integer. Still a > problem according to you and not fixed. Or do I misunderstand your > writing and a true is the character "1" and false the character "0"? > > -- A stubborn programmer may add even the standard -1 flag to something, implementing a very clever 1- operation. Sometimes you need decrementing, not as often as incrementing though. I may say another thing: one bit booleans save some power. You are toggling only one bit, not 16 or 32 bits. Who knows, in a deep wireless device working on a coin battery for years, this may save some power? :)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-25 14:33 +0000 |
| Message-ID | <2015May25.163301@mips.complang.tuwien.ac.at> |
| In reply to | #39275 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>A stubborn programmer may add even the standard -1 flag to something, implementing a very clever 1- operation. Sometimes you need decrementing, not as often as incrementing though.
You can decrement with Forth-79 flags:
( n 79-flag ) -
And you can increment with Forth-83 flags:
( n 83-flag ) -
In this case the 79-flag is more intuitive, but in any case, both are
legitimate operations (with an environmental dependency on
2s-complement in Forth-94 and -2012).
>I may say another thing: one bit booleans save some power. You are toggling only one bit, not 16 or 32 bits. Who knows, in a deep wireless device working on a coin battery for years, this may save some power? :)
On such a device, you can have a wff! and wff@ that changes only one
bit, and where the compiler optimizes the full n bits away in many
places, such as "0< wff!" and "wff@ if".
Please limit your lines to about 70 chars.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-25 10:56 -0400 |
| Message-ID | <mjvd5e$59p$1@dont-email.me> |
| In reply to | #39275 |
On 5/25/2015 2:26 AM, Raimond Dragomir wrote: >> So... What is wrong with using -1 for a logic TRUE? >> >> I think you describe three problems. The first I don't get because >> you say there are no logical operators, but 0= seems to be exactly >> that. I don't see the problem. > > 0= is a comparison operation. It's the shortcut for 0 = Basically > it's an '=' operation But you don't explain any problem??? >> The second problem is that storing a flag in something smaller than >> a cell will not return the flag exactly. Yes... duh! Again, I >> don't see the problem. >> > If you have some memory allocation scheme and keep 'dirty' flags in a > buffer, you may want to use one byte for the flag, not an entire > cell. Think you have 1K flags. This is 4K bytes for a 32bit system, > opposed to only 1K. I'm speaking of microcontrollers here, where 3K > of RAM can be huge. I know, you may say that with some custom code > you can store the flags in one bit each, with proper time consuming > bitmask operations. So store the flags in bytes. Where is the problem? >> The third problem seems to revolve around not the actual value of >> the flag, but the fact that programmers rely on the value of the >> flag in operations. How is that the fault of the definition of >> flag. If you define a true flag as the value 1 and a false flag as >> 0, then programmers will do things like adding the flag to an >> integer. Still a problem according to you and not fixed. Or do I >> misunderstand your writing and a true is the character "1" and >> false the character "0"? >> >> -- > > A stubborn programmer may add even the standard -1 flag to something, > implementing a very clever 1- operation. Sometimes you need > decrementing, not as often as incrementing though. > > I may say another thing: one bit booleans save some power. You are > toggling only one bit, not 16 or 32 bits. Who knows, in a deep > wireless device working on a coin battery for years, this may save > some power? :) In such a device you are free to use a 1 bit boolean. But that would not be forth even in the systems that use 1 and 0 as they are still 32 bit tokens with the value 1 and 0. I still don't see any problems using all 1s for a logic true. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-05-25 11:28 -0700 |
| Message-ID | <f018761a-4157-46d4-a290-39a2ae28a08d@googlegroups.com> |
| In reply to | #39289 |
luni, 25 mai 2015, 17:57:01 UTC+3, rickman a scris: > On 5/25/2015 2:26 AM, Raimond Dragomir wrote: > >> So... What is wrong with using -1 for a logic TRUE? > >> > >> I think you describe three problems. The first I don't get because > >> you say there are no logical operators, but 0= seems to be exactly > >> that. I don't see the problem. > > > > 0= is a comparison operation. It's the shortcut for 0 = Basically > > it's an '=' operation > > But you don't explain any problem??? > ? > > >> The second problem is that storing a flag in something smaller than > >> a cell will not return the flag exactly. Yes... duh! Again, I > >> don't see the problem. > >> > > If you have some memory allocation scheme and keep 'dirty' flags in a > > buffer, you may want to use one byte for the flag, not an entire > > cell. Think you have 1K flags. This is 4K bytes for a 32bit system, > > opposed to only 1K. I'm speaking of microcontrollers here, where 3K > > of RAM can be huge. I know, you may say that with some custom code > > you can store the flags in one bit each, with proper time consuming > > bitmask operations. > > So store the flags in bytes. Where is the problem? > true some-addr c! ... some-addr c@ You store -1 (well trying...) C@ will get ... oops ... 255 And 255 is not the "true", that is the problem. > > >> The third problem seems to revolve around not the actual value of > >> the flag, but the fact that programmers rely on the value of the > >> flag in operations. How is that the fault of the definition of > >> flag. If you define a true flag as the value 1 and a false flag as > >> 0, then programmers will do things like adding the flag to an > >> integer. Still a problem according to you and not fixed. Or do I > >> misunderstand your writing and a true is the character "1" and > >> false the character "0"? > >> > >> -- > > > > A stubborn programmer may add even the standard -1 flag to something, > > implementing a very clever 1- operation. Sometimes you need > > decrementing, not as often as incrementing though. > > > > I may say another thing: one bit booleans save some power. You are > > toggling only one bit, not 16 or 32 bits. Who knows, in a deep > > wireless device working on a coin battery for years, this may save > > some power? :) > > In such a device you are free to use a 1 bit boolean. But that would > not be forth even in the systems that use 1 and 0 as they are still 32 > bit tokens with the value 1 and 0. > Why that would not be forth? > I still don't see any problems using all 1s for a logic true. > I don't see either. 0/1 booleans seems to me more convenient to use, that's all. > -- > > Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-25 14:33 -0400 |
| Message-ID | <mjvprc$nou$1@dont-email.me> |
| In reply to | #39297 |
On 5/25/2015 2:28 PM, Raimond Dragomir wrote: > luni, 25 mai 2015, 17:57:01 UTC+3, rickman a scris: >> On 5/25/2015 2:26 AM, Raimond Dragomir wrote: >>>> So... What is wrong with using -1 for a logic TRUE? >>>> >>>> I think you describe three problems. The first I don't get because >>>> you say there are no logical operators, but 0= seems to be exactly >>>> that. I don't see the problem. >>> >>> 0= is a comparison operation. It's the shortcut for 0 = Basically >>> it's an '=' operation >> >> But you don't explain any problem??? >> > ? > >> >>>> The second problem is that storing a flag in something smaller than >>>> a cell will not return the flag exactly. Yes... duh! Again, I >>>> don't see the problem. >>>> >>> If you have some memory allocation scheme and keep 'dirty' flags in a >>> buffer, you may want to use one byte for the flag, not an entire >>> cell. Think you have 1K flags. This is 4K bytes for a 32bit system, >>> opposed to only 1K. I'm speaking of microcontrollers here, where 3K >>> of RAM can be huge. I know, you may say that with some custom code >>> you can store the flags in one bit each, with proper time consuming >>> bitmask operations. >> >> So store the flags in bytes. Where is the problem? >> > true some-addr c! ... some-addr c@ > You store -1 (well trying...) C@ will get ... oops ... 255 > And 255 is not the "true", that is the problem. But 255 will be treated as "true" by any logic function. >>>> The third problem seems to revolve around not the actual value of >>>> the flag, but the fact that programmers rely on the value of the >>>> flag in operations. How is that the fault of the definition of >>>> flag. If you define a true flag as the value 1 and a false flag as >>>> 0, then programmers will do things like adding the flag to an >>>> integer. Still a problem according to you and not fixed. Or do I >>>> misunderstand your writing and a true is the character "1" and >>>> false the character "0"? >>>> >>>> -- >>> >>> A stubborn programmer may add even the standard -1 flag to something, >>> implementing a very clever 1- operation. Sometimes you need >>> decrementing, not as often as incrementing though. >>> >>> I may say another thing: one bit booleans save some power. You are >>> toggling only one bit, not 16 or 32 bits. Who knows, in a deep >>> wireless device working on a coin battery for years, this may save >>> some power? :) >> >> In such a device you are free to use a 1 bit boolean. But that would >> not be forth even in the systems that use 1 and 0 as they are still 32 >> bit tokens with the value 1 and 0. >> > Why that would not be forth? Because 1 bit data items are not logic values. Logic values are defined as a cell, not a bit. >> I still don't see any problems using all 1s for a logic true. >> > > I don't see either. 0/1 booleans seems to me more convenient to use, that's all. I believe this is a matter of preference. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-25 12:57 -0700 |
| Message-ID | <d6a3c613-ff08-46ab-b2e6-d843d243aaa4@googlegroups.com> |
| In reply to | #39297 |
On Monday, May 25, 2015 at 11:28:05 AM UTC-7, Raimond Dragomir wrote: > luni, 25 mai 2015, 17:57:01 UTC+3, rickman a scris: > > So store the flags in bytes. Where is the problem? > > > true some-addr c! ... some-addr c@ > You store -1 (well trying...) C@ will get ... oops ... 255 > And 255 is not the "true", that is the problem. > > ... 0/1 booleans seems to me more convenient to use, that's all. This is the same as the old argument (in the 1980s) about whether little-endian or big-endian was better. The names "little-endian" and "big-endian" were a reference to Gulliver's Travels where on an island the people went to war over the question of whether to break their eggs on the little end or the big end --- the moral of the story being that people fight over meaningless matters. The truth however, is that little-endian is definitely better. The reason is that if you have a double-integer stored in a 2VARIABLE and it happens to be small enough to be a single-integer (the high-cell is 0 or -1) then you can @ it from your 2VARIABLE just the same as if it were a VARIABLE containing a single-integer. The same thing is true here (bit-0 is the little-end of every size of integer). If you use 1|0 for your flag, then you can fetch it with C@ @ or 2@ and you get the same value every time. If you use -1|0 for your flag, then C@ gives you 255, @ gives you -1 and 2@ gives you 2^32. This is actually quite obvious --- this has been well-known for many decades --- ANS-Forth's use of -1|0 is just perpetuating a Forth-83 bug forever. Also, as I said before, if you really want a mask with all bits set or clear, then NEGATE your flag to get a mask. You could define FLAG>MASK to help clarify your source-code: macro: flag>mask ( flag -- mask ) negate ; Given a modern optimizing compiler, this compiles as a single instruction, so we are talking about a matter of nanoseconds --- premature optimization that doesn't matter anyway --- the hallmark of novice programmers. : and-flag ( n flag -- nAmask ) flag>mask and ; ok see and-flag AND-FLAG ( 004DEFE0 F7DB ) NEG EBX ( 004DEFE2 235D00 ) AND EBX, [EBP] ( 004DEFE5 8D6D04 ) LEA EBP, [EBP+04] ( 004DEFE8 C3 ) NEXT, ( 9 bytes, 4 instructions ) ok
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-05-25 23:01 -0700 |
| Message-ID | <1c8c686b-610a-4f71-a334-c98a6c551ea2@googlegroups.com> |
| In reply to | #39297 |
luni, 25 mai 2015, 21:28:05 UTC+3, Raimond Dragomir a scris: > luni, 25 mai 2015, 17:57:01 UTC+3, rickman a scris: > > On 5/25/2015 2:26 AM, Raimond Dragomir wrote: > > >> So... What is wrong with using -1 for a logic TRUE? > > >> > > >> I think you describe three problems. The first I don't get because > > >> you say there are no logical operators, but 0= seems to be exactly > > >> that. I don't see the problem. > > > > > > 0= is a comparison operation. It's the shortcut for 0 = Basically > > > it's an '=' operation > > > > But you don't explain any problem??? > > > ? > > > > > >> The second problem is that storing a flag in something smaller than > > >> a cell will not return the flag exactly. Yes... duh! Again, I > > >> don't see the problem. > > >> > > > If you have some memory allocation scheme and keep 'dirty' flags in a > > > buffer, you may want to use one byte for the flag, not an entire > > > cell. Think you have 1K flags. This is 4K bytes for a 32bit system, > > > opposed to only 1K. I'm speaking of microcontrollers here, where 3K > > > of RAM can be huge. I know, you may say that with some custom code > > > you can store the flags in one bit each, with proper time consuming > > > bitmask operations. > > > > So store the flags in bytes. Where is the problem? > > > true some-addr c! ... some-addr c@ > You store -1 (well trying...) C@ will get ... oops ... 255 > And 255 is not the "true", that is the problem. > > > > > >> The third problem seems to revolve around not the actual value of > > >> the flag, but the fact that programmers rely on the value of the > > >> flag in operations. How is that the fault of the definition of > > >> flag. If you define a true flag as the value 1 and a false flag as > > >> 0, then programmers will do things like adding the flag to an > > >> integer. Still a problem according to you and not fixed. Or do I > > >> misunderstand your writing and a true is the character "1" and > > >> false the character "0"? > > >> > > >> -- > > > > > > A stubborn programmer may add even the standard -1 flag to something, > > > implementing a very clever 1- operation. Sometimes you need > > > decrementing, not as often as incrementing though. > > > > > > I may say another thing: one bit booleans save some power. You are > > > toggling only one bit, not 16 or 32 bits. Who knows, in a deep > > > wireless device working on a coin battery for years, this may save > > > some power? :) > > > > In such a device you are free to use a 1 bit boolean. But that would > > not be forth even in the systems that use 1 and 0 as they are still 32 > > bit tokens with the value 1 and 0. > > > Why that would not be forth? > > > I still don't see any problems using all 1s for a logic true. > > > > I don't see either. 0/1 booleans seems to me more convenient to use, that's all. > > > -- > > > > Rick Hi! 0 means 'false'. Other value means 'true'. Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-25 14:21 +0000 |
| Message-ID | <2015May25.162110@mips.complang.tuwien.ac.at> |
| In reply to | #39257 |
Hans Bezemer <the.beez.speaks@gmail.com> writes:
>"Since a "char" can store small positive numbers and since the
>character data type is a sub-range of the unsigned integer data
>type, C! must store the n least-significant bits of a cell (8 <=
>n <= bits/cell). Given the enumeration of allowed number
>representations and their known encodings, "TRUE xx C! xx C@"
>must leave a stack item with some number of bits set, which will
>thus will be accepted as non-zero by IF."
>
>This is another problem of using "all bits set" as a true flag:
>you store a well formed flag in an address unit that should
>easily be able to handle it and you'll never get it back.
Well, if you want to get it back, define
: wff@ ( c-addr -- f ) c@ 0<> ;
or a sign-extending c@
: mask-extend ( x mask -- n ) \ credits: Stephen Pelc
over and negate or ;
: sc@ ( c-addr -- n ) c@ $80 mask-extend ;
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-26 23:59 +0000 |
| Message-ID | <556508ea$0$3081$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #39257 |
In article <55623fa0$0$2821$e4fe514c@news2.news.xs4all.nl>, Hans Bezemer <the.beez.speaks@gmail.com> wrote: >rickman wrote: > <SNIP> > >But why are some Forth programmers so keen on their “all bits set” > flag? Well, you can do neat things with it. > >: >CHAR DUP 9 > 7 AND + ASCII 0 + ; > >This will convert a digit to its ASCII representation. True, it >is a clever piece of programming, but in our opinion it is bad >style. Why? Because you are using a flag as a bitmask, which is a >completely different datatype. Although there is no such thing as >“data typing” in Forth, this way of programming makes it >difficult to understand and maintain a program, which the >ANS-Forth standard acknowledges: > And the Python programmers? Are they using a flag as a bit-mask in the following example? Or have they just given a sensible meaning to and-ing. In the following x is a list. It is anded with impunity and according to Python rules. >>> x=list(range(10)) >>> x [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> a=True >>> a True >>> y=a and x >>> y [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> >>> a=False >>> y=a and x >>> y False >>> if a and x: ... print 1 ... else: ... print 2 ... 2 >"The discipline of circumscribing meaning which a program may >assign to various combinations of bit patterns is sometimes >called data typing. Many computer languages impose explicit data >typing and have compilers that prevent ill-defined operations. >Forth rarely explicitly imposes data-type restrictions. Still, >data types implicitly do exist, and discipline is required, >particularly if portability of programs is a goal. In Forth, it >is incumbent upon the programmer (rather than the compiler) to >determine that data are accurately typed." Basically, you must be able to do some abstract thinking around datatypes. I note that Forthers have sometimes difficulty going one step up the abstraction ladder, like thinking of (addr,len) as a string. I've trouble with memoizing and list comprehensions in Python. Maybe from doing to much Forth. > >That is why 4tH uses "1" as a true flag. Usually, it won't make >much difference. Except when you use 'INVERT' to invert a flag or >intend to make obfuscated programs. If you use '0=' instead, you >won't run in any trouble, not even when you port your program to >ANS-Forth. Clarity may introduce a little overhead, but in this >age of multi-gigaherz machines, who is counting? Sorry, but by me that doesn't follow. > >Hans Bezemer > 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
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-27 09:15 +0000 |
| Message-ID | <2015May27.111505@mips.complang.tuwien.ac.at> |
| In reply to | #39257 |
Hans Bezemer <the.beez.speaks@gmail.com> writes:
>But why are some Forth programmers so keen on their “all bits set”
> flag? Well, you can do neat things with it.
>
>: >CHAR DUP 9 > 7 AND + ASCII 0 + ;
>
>This will convert a digit to its ASCII representation. True, it
>is a clever piece of programming, but in our opinion it is bad
>style. Why? Because you are using a flag as a bitmask, which is a
>completely different datatype.
This is Forth, and in Forth it's the same data type. And a
straight-line piece of code is preferable to a piece of code for the
same task that contains an IF (as someone posted elsewhere): You can
test the straight-line code against stack errors with just one test
case (if it does not contain variable-stack-effect words like ?DUP).
What is not so great in this piece of code is the unexplained "7".
One can fix this with
: >char ( u -- c )
dup 9 > 'A' '0' 10 + - and + '0' + ;
Or, for Forth systems that don't do constant folding in the compiler:
: >char ( u -- c )
dup 9 > [ 'A' '0' 10 + - ] literal and + '0' + ;
It may be easier to comprehend the purpose of the > ... AND + when
rearranged as follows:
: >char ( u -- c )
'0' + dup '9' > [ 'A' '0' 10 + - ] literal and + ;
For cases where AND alone is not sufficient, Gforth contains the
following word in the development version:
select ( u1 u2 f -- u ) gforth
""select @i{u1} if @i{f} is true, @i{u2} if false.""
With that you can write >CHAR as follows:
: >char ( u -- c )
dup '0' [ 'A' 10 - ] literal rot 9 > select + ;
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-27 10:06 +0000 |
| Message-ID | <2015May27.120605@mips.complang.tuwien.ac.at> |
| In reply to | #39352 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>For cases where AND alone is not sufficient, Gforth contains the
>following word in the development version:
>
>select ( u1 u2 f -- u ) gforth
>""select @i{u1} if @i{f} is true, @i{u2} if false.""
>
>With that you can write >CHAR as follows:
>
>: >char ( u -- c )
> dup '0' [ 'A' 10 - ] literal rot 9 > select + ;
Well, of course you still need to do the order of arguments in a way
that matches the flag computation:
: >char ( u -- c )
dup [ 'A' 10 - ] literal '0' rot 9 > select + ;
or
: >char ( u -- c )
dup '0' [ 'A' 10 - ] literal rot 10 < select + ;
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-27 12:03 -0400 |
| Message-ID | <mk4pr1$dem$1@dont-email.me> |
| In reply to | #39352 |
On 5/27/2015 5:15 AM, Anton Ertl wrote:
> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>> But why are some Forth programmers so keen on their “all bits setâ€
>> flag? Well, you can do neat things with it.
>>
>> : >CHAR DUP 9 > 7 AND + ASCII 0 + ;
>>
>> This will convert a digit to its ASCII representation. True, it
>> is a clever piece of programming, but in our opinion it is bad
>> style. Why? Because you are using a flag as a bitmask, which is a
>> completely different datatype.
>
> This is Forth, and in Forth it's the same data type. And a
> straight-line piece of code is preferable to a piece of code for the
> same task that contains an IF (as someone posted elsewhere): You can
> test the straight-line code against stack errors with just one test
> case (if it does not contain variable-stack-effect words like ?DUP).
>
> What is not so great in this piece of code is the unexplained "7".
> One can fix this with
>
> : >char ( u -- c )
> dup 9 > 'A' '0' 10 + - and + '0' + ;
>
> Or, for Forth systems that don't do constant folding in the compiler:
>
> : >char ( u -- c )
> dup 9 > [ 'A' '0' 10 + - ] literal and + '0' + ;
>
> It may be easier to comprehend the purpose of the > ... AND + when
> rearranged as follows:
>
> : >char ( u -- c )
> '0' + dup '9' > [ 'A' '0' 10 + - ] literal and + ;
>
> For cases where AND alone is not sufficient, Gforth contains the
> following word in the development version:
>
> select ( u1 u2 f -- u ) gforth
> ""select @i{u1} if @i{f} is true, @i{u2} if false.""
>
> With that you can write >CHAR as follows:
>
> : >char ( u -- c )
> dup '0' [ 'A' 10 - ] literal rot 9 > select + ;
How about...
\ Convert n to ASCII char - constant 7 spans gap between ASCII 9 and A
: >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ;
BTW, I haven't seen the character notation 'A' before. Is that done in
number? I take it this is not part of the ANS standard?
--
Rick
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web