Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33600 > unrolled thread
| Started by | hughaguilar96@yahoo.com |
|---|---|
| First post | 2014-09-30 19:25 -0700 |
| Last post | 2014-10-16 01:03 -0400 |
| Articles | 20 on this page of 91 — 16 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Why smudge? hughaguilar96@yahoo.com - 2014-09-30 19:25 -0700
Re: Why smudge? november.nihal@gmail.com - 2014-10-01 08:54 -0700
Re: Why smudge? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-01 19:09 +0000
Re: Why smudge? november.nihal@gmail.com - 2014-10-01 10:16 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-01 18:54 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 15:31 -0700
Re: Why smudge? Michael Barry <barrym95838@yahoo.com> - 2014-10-02 16:35 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 17:02 -0700
Re: Why smudge? Michael Barry <barrym95838@yahoo.com> - 2014-10-02 17:51 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 18:50 -0700
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-04 00:30 +0100
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-03 17:40 -0700
Re: Why smudge? Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-10-03 23:00 -0700
Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-04 21:14 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:42 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Enoch <emc.consultants@gmail.com> - 2014-10-05 10:43 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-05 20:21 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-06 03:58 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-05 17:09 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Michael Barry <barrym95838@yahoo.com> - 2014-10-06 11:15 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-06 18:52 -0700
More ranting Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-07 03:48 -0500
Re: More ranting albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-07 12:43 +0000
Re: More ranting Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:23 +0200
Re: More ranting "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-16 01:03 -0400
Re: More ranting Just Ian <superian@gmail.com> - 2014-10-16 07:14 -0700
Re: More ranting Michael Barry <barrym95838@yahoo.com> - 2014-10-16 13:23 -0700
uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 15:36 +0000
Re: uninitialized and implicitly initialized locals (was: More ranting) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 22:15 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) mhx@iae.nl - 2014-10-07 15:07 -0700
Re: uninitialized and implicitly initialized locals (was: More ranting) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:11 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 13:25 +0000
Re: uninitialized and implicitly initialized locals (was: More ranting) hughaguilar96@yahoo.com - 2014-10-09 16:22 -0700
Re: uninitialized and implicitly initialized locals (was: More ranting) "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 21:58 -0400
Re: uninitialized and implicitly initialized locals (was: More ranting) mhx@iae.nl (Marcel Hendrix) - 2014-10-12 11:18 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 12:35 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-07 15:27 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 12:56 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 08:24 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 15:32 +0000
Simplified automatic scoping (was: uninitialized ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 16:06 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 11:57 -0500
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 12:18 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 14:19 +0000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-09 14:42 -0700
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 14:07 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-09 10:44 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-10 16:03 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-10 13:35 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 10:53 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 11:34 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-15 12:44 +0000
Re: uninitialized and implicitly initialized locals albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-15 14:34 +0000
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-15 15:03 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-15 11:10 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-16 12:19 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-17 03:56 -0500
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-17 07:48 -1000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-17 19:26 -0700
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-18 12:55 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-18 13:21 -0500
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-18 08:44 -1000
Re: uninitialized and implicitly initialized locals albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-19 09:53 +0000
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-20 12:48 +0000
Re: uninitialized and implicitly initialized locals "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-20 16:24 -0400
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-20 10:30 -1000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-20 16:23 -0700
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 04:16 -0500
Re: uninitialized and implicitly initialized locals mhx@iae.nl (Marcel Hendrix) - 2014-10-26 11:32 +0200
Re: uninitialized and implicitly initialized locals stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-26 14:27 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 13:56 -0500
Re: uninitialized and implicitly initialized locals mhx@iae.nl (Marcel Hendrix) - 2014-10-26 20:32 +0200
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 16:18 -0500
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-26 15:05 -0700
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 17:53 -0500
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-26 16:30 -0700
Re: uninitialized and implicitly initialized locals "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-27 01:45 -0400
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-27 12:21 -0500
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 17:57 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-06 20:55 +0100
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-06 16:05 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-09 07:36 +0100
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-10 01:52 +0000
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-09 19:56 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:11 -0400
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-05 11:05 +0100
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-05 19:48 -0700
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-06 07:53 +0100
Re: Why smudge? "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 21:29 -1000
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-09 15:16 -0700
Re: Why smudge? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-16 01:03 -0400
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-30 19:25 -0700 |
| Subject | Re: Why smudge? |
| Message-ID | <da233370-2677-44bb-b73c-cda6abf57611@googlegroups.com> |
On Monday, July 5, 1993 11:21:00 AM UTC-7, Ray Duncan wrote:
> In article <xtifrC9oHqq.8z0@netcom.com> xtifr@netcom.com (Chris Waters) writes:
> >In <218dbj$4u7@news.cerf.net> duncan@nic.cerf.net (Ray Duncan) writes:
> >
> >>Yes. However, we are trying to optimize the common case, and
> >>as far as we have seen search orders deeper than 2 or 3 vocabularies
> >>are quite uncommon. FIND also collapses the search order
> >>if possible before doing anything else, e.g. if CONTEXT and
> >>CURRENT are both the same vocabulary, it will only probe the
> >>hash table once.
> >
> >I thought that searching CURRENT was removed from both the 83-standard
> >and dpANS! In fact, I'm not even sure that it was in the 79-standard.
> >(Although collapsing any duplicate vocabularies pointed to by CONTEXT is
> >certainly a good idea in any case.)
>
> I am using CONTEXT and CURRENT as shorthand for the "first vocabulary
> in the search order" and "the compilation vocabulary." VARIABLEs
> with the names CONTEXT and CURRENT actually exist in our system, but
> they just contain a vocabulary number, not a pointer to a linked
> list of headers as in a traditional system. The FIND in our
> system is driven by a byte array of vocabulary numbers that is set
> up by execution of a vocabulary name and DEFINITIONS and so on.
> This byte array defines the search order and can theoretically
> be of any length up to 255 bytes, although in our systems the
> default search order has 3 tiers: CONTEXT, CURRENT, and lastly
> FORTH.
>
> As for Forth-83 and dpANS -- Forth-83 was singularly vague on
> the subject of vocabulary implementation, and (the last time
> I looked) so is dpANS. In the Forth-83 standard there is nothing
> that says the use of system variables named CONTEXT and CURRENT
> makes the system nonstandard. Nor is there anything that says
> the compilation vocabulary CAN'T be part of the search order.
>
> Perhaps you are confusing the infamous Ragsdale ALSO/ONLY
> experimental vocabulary proposal with the Forth-83 standard.
> It's true it was included in the Forth-83 Standard document,
> but it is not part of the standard and is not required.
> We considered, and still consider, the ALSO/ONLY scheme to
> be severely brain-damaged and we have never used it, although
> it is straightforward to layer an ALSO/ONLY compatibility layer
> on top of any of our systems.
I had not previously paid any attention to word-lists in ANS-Forth. Now, writing this cross-compiler, I was obliged to read up on them. When I read the entry on ALSO (16.6.2.0715) I saw this:
"Transform the search order consisting of widn, ... wid2, wid1 (where wid1 is searched first) into widn, ... wid2, wid1, wid1." I said to myself: "WTF? Why would I want wid1 searched twice?" Then after some more reading, I discovered the definition for FORTH (16.6.2.1590):
"Transform the search order consisting of widn, ... wid2, wid1 (where wid1 is searched first) into widn, ... wid2, widFORTH-WORDLIST."
So, apparently the idea is to use FORTH after ALSO to fix the top value of the search-order. ALSO makes no sense except in the context of being followed by a word such as FORTH that fixes the problem that it creates. But there is no word provided to allow the user to do this with his own word-lists. The user has to write code for this himself. I wrote the following, that will go into the next novice package upgrade:
: <set-context> { wid anchor -- widN... N }
get-order dup 1 < abort" *** SET-CONTEXT given empty search-order ***"
over anchor = if
wid anchor = if exit then
wid swap 1+ exit then
nip wid swap ;
\ WID will replace whatever was on top, unless ANCHOR was on top
\ in which case WID will be pushed above it
: set-context ( wid -- )
forth-wordlist <set-context> set-order ;
\ like in Forth-83, the WID becomes the context
\ with FORTH-WORDLIST as the anchor below it
\ FORTH-WORDLIST SET-CONTEXT would do the same thing that FORTH does.
: <push-context> { wid -- }
get-order
over wid = if exit then
wid swap 1+ ;
\ the WID becomes the context, with whatever was below it remaining
: push-context ( wid -- )
<push-context> set-order ;
\ I don't recommend using ALSO with <SET-CONTEXT> because problems will
\ result if the anchor is the top wid. Use PUSH-CONTEXT instead.
\ All in all, ALSO is a screw-ball idea, as it involves making a duplicate
\ in the search-order, which makes no sense.
[toc] | [next] | [standalone]
| From | november.nihal@gmail.com |
|---|---|
| Date | 2014-10-01 08:54 -0700 |
| Message-ID | <4f8cd07b-7176-48b1-8f08-a048a6f8e01d@googlegroups.com> |
| In reply to | #33600 |
> \ All in all, ALSO is a screw-ball idea, as it involves making a duplicate > > \ in the search-order, which makes no sense. Think of wordlist as a stack of wids. - "only" empties the stack - "also" behaves like dup - "previous" behaves like drop So why would you want to duplicate the top of the wordlist stack ? Any word created using "vocabulary" acts directly with whatever is on top of the wordlist stack. When you type say 10 at a console... The forth data stack is => ( -- 10 20 30 ) you dont get ( -- 10 20 10 ) but you get ( 10 20 30 10 ) But on the wordlist stack, Say the wordlist stack is => ( -- 10 20 30 ) you dont get ( 10 20 30 10 ) but you get ( -- 10 20 10 ) Usually when you are trying to change the context, you dont want to lose whatever is at the top already there. That's why "also" is important. That how I think of it, but lets see if others agree or disagree. NN
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-01 19:09 +0000 |
| Message-ID | <542c515f$0$6947$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #33604 |
In article <4f8cd07b-7176-48b1-8f08-a048a6f8e01d@googlegroups.com>, <november.nihal@gmail.com> wrote: >> \ All in all, ALSO is a screw-ball idea, as it involves making a duplicate >> >> \ in the search-order, which makes no sense. > >Think of wordlist as a stack of wids. > >- "only" empties the stack >- "also" behaves like dup >- "previous" behaves like drop > >So why would you want to duplicate the top of the wordlist stack ? > >Any word created using "vocabulary" acts directly with whatever is on >top of the wordlist stack. > >When you type say 10 at a console... > >The forth data stack is => ( -- 10 20 30 ) >you dont get ( -- 10 20 10 ) >but you get ( 10 20 30 10 ) > >But on the wordlist stack, > >Say the wordlist stack is => ( -- 10 20 30 ) >you dont get ( 10 20 30 10 ) >but you get ( -- 10 20 10 ) > >Usually when you are trying to change the context, you dont want to lose >whatever is at the top already there. That's why "also" is important. > >That how I think of it, but lets see if others agree or disagree. The replacing is from the time that Chuck Moore had two wordlists: the system and the application. The application changed all the time. colorforth is much like this still. In this time and age, now we have the idea of several libraries used to run an application (apart from the system), it makes more sense to push a namespace (as everybody else calls it) to the search order. Also wordlists suffer from the same problem as locals: semantics without a syntax, such that everybody has to invent their own. This makes it legal for me to in ciforth to replace VOCABULARY with NAMESPACE and push instead of replace when a namespace is invoked. > >NN 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 | november.nihal@gmail.com |
|---|---|
| Date | 2014-10-01 10:16 -0700 |
| Message-ID | <8782520c-259f-4a16-959b-6d491f9a9224@googlegroups.com> |
| In reply to | #33600 |
I wrote these a while ago and I think they explain intention cleanly, : >context ( wid -- ) >r get-order r> swap 1+ set-order ; : context> ( -- wid ) get-order swap >r 1- set-order r> ; : context@ ( -- wid ) get-order over >r set-order r> ; If I understand your code correctly then it translates to :- \ dont duplicate : push-context ( wid -- ) dup context@ = if drop else >context then ; \ wid will replace whatever was on top unless anchor was on top : set-context ( wid -- ) forth-wordlist dup context@ = if over = if drop else >context then else drop context> drop >context then ; Hope its useful.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-01 18:54 -0700 |
| Message-ID | <a5d9a739-d73d-495f-aa2f-327e1d61c0aa@googlegroups.com> |
| In reply to | #33606 |
On Wednesday, October 1, 2014 10:16:45 AM UTC-7, novembe...@gmail.com wrote: > I wrote these a while ago and I think they explain intention cleanly, > > : >context ( wid -- ) >r get-order r> swap 1+ set-order ; > : context> ( -- wid ) get-order swap >r 1- set-order r> ; > : context@ ( -- wid ) get-order over >r set-order r> ; > > If I understand your code correctly then it translates to :- > > \ dont duplicate > : push-context ( wid -- ) > dup context@ = if drop else >context then ; > > \ wid will replace whatever was on top unless anchor was on top > > : set-context ( wid -- ) > forth-wordlist dup context@ = if > over = if drop else >context then > else drop context> drop >context then ; Yes, that appears to be the same (although I didn't actually test your code). Note that I have <SET-CONTEXT> that allows any wid to be used as the anchor, not just FORTH-WORDLIST. Eventually, I will want to be able to write my cross-compiler in itself, so this will be necessary. There may be other cases in which it is necessary --- why should FORTH-WORDLIST be so special that only it can be used as an anchor?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-02 15:31 -0700 |
| Message-ID | <ce18a880-3d78-4866-866b-a75e243fd49a@googlegroups.com> |
| In reply to | #33600 |
On Tuesday, September 30, 2014 7:25:06 PM UTC-7, hughag...@yahoo.com wrote:
> The user has to write code for this himself. I wrote the following, that will go into the next novice package upgrade:
>
> : <set-context> { wid anchor -- widN... N }
> get-order dup 1 < abort" *** SET-CONTEXT given empty search-order ***"
> over anchor = if
> wid anchor = if exit then
> wid swap 1+ exit then
> nip wid swap ;
> \ WID will replace whatever was on top, unless ANCHOR was on top
> \ in which case WID will be pushed above it
>
> : set-context ( wid -- )
> forth-wordlist <set-context> set-order ;
> \ like in Forth-83, the WID becomes the context
> \ with FORTH-WORDLIST as the anchor below it
>
> \ FORTH-WORDLIST SET-CONTEXT would do the same thing that FORTH does.
>
> : <push-context> { wid -- }
> get-order
> over wid = if exit then
> wid swap 1+ ;
> \ the WID becomes the context, with whatever was below it remaining
>
> : push-context ( wid -- )
> <push-context> set-order ;
>
> \ I don't recommend using ALSO with <SET-CONTEXT> because problems will
> \ result if the anchor is the top wid. Use PUSH-CONTEXT instead.
> \ All in all, ALSO is a screw-ball idea, as it involves making a duplicate
> \ in the search-order, which makes no sense.
This code that I presented here is a bug-ridden mess, so I'm retracting it. It won't go into the novice package; SET-CONTEXT doesn't work. I now believe that it is impossible to write SET-CONTEXT in ANS-Forth, and I have given up on the effort.
I am surprised that nobody pointed out the bug in my SET-CONTEXT --- that would have been an opportunity slam me for being a bad ANS-Forth programmer --- but too late now, as I have found the bug myself (although I don't know how to fix the bug).
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2014-10-02 16:35 -0700 |
| Message-ID | <64fa7d1f-d80b-4e7c-b087-d42c9c5a201d@googlegroups.com> |
| In reply to | #33656 |
On Thursday, October 2, 2014 3:31:06 PM UTC-7, hughag...@yahoo.com wrote: > > This code that I presented here is a bug-ridden mess, so I'm retracting it. > It won't go into the novice package; SET-CONTEXT doesn't work. I now > believe that it is impossible to write SET-CONTEXT in ANS-Forth, and I have > given up on the effort. > > > I am surprised that nobody pointed out the bug in my SET-CONTEXT --- that > would have been an opportunity slam me for being a bad ANS-Forth programmer > --- but too late now, as I have found the bug myself (although I don't know > how to fix the bug). > Hugh, could you be so kind as to explain the nature of the bug? I don't know Forth nearly well enough to find it myself, but I would like to learn, both about its nature and your doubts in your ability to fix it. I'm one of those guys who is writing his own interpreter, but has never programmed anything of note in actual Forth. The language intrigues me, and it would be nice to gather some insights interactively from a live person with experience, rather than just from on-line texts. If it helps, I certify that I am not homosexual, and I have no vested interest in any particular standard or implementation (although I have been using an assembly listing of Dr. Brad Rodriguez' ITC Camel Forth for the MSP430 as a general guide. My target is a vapor-ware micro-processor of my own design, and I thought that the best way to shape and optimize the instruction set was to write something non-trivial, like a Forth interpreter. Thanks, Mike
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-02 17:02 -0700 |
| Message-ID | <30e2841a-637c-461c-8df9-02957a978226@googlegroups.com> |
| In reply to | #33662 |
On Thursday, October 2, 2014 4:35:30 PM UTC-7, Michael Barry wrote: > Hugh, could you be so kind as to explain the nature of the bug? I don't know > > Forth nearly well enough to find it myself, but I would like to learn, both > about its nature and your doubts in your ability to fix it. SET-CONTEXT assumes that the 1st wid in the search order is the wid that you want to replace. Sometimes this is true, and sometimes it is not true, and this varies from one ANS-Forth-compliant Forth system to another. In VFX, colon words with local variables will have a wid called LOCALVARS in 1st place in the search order during the compilation of the colon word, but semicolon removes it. If you execute SET-CONTEXT during the execution of a colon word that has locals, it will replace LOCALVARS rather than the wid that you expected to replace (the wid you thought was 1st is actually 2nd) --- chaos will result. I have only tested VFX so far --- whether SwiftForth or Gforth or whatever also have something like LOCALVARS, I don't know --- also, I don't know if VFX uses word-lists internally for anything other than local variables or not (this kind of thing is not documented anywhere, and even if it was, there is no guarantee that it will remain true from one release to the next). In UR/Forth, this problem never arose. CONTEXT and CURRENT were only changed by the programmer, and never by the internal workings of the system. UR/Forth didn't have local variables though, so maybe if Ray Duncan had continued upgrading UR/Forth he would have started mucking around with CONTEXT when he implemented local variables, and gotten into the same mess that ANS-Forth is in --- but Ray Duncan was pretty smart, so he might have foreseen the problem and dodged it --- we will never know, as he gave up Forth programming when ANS-Forth came out. The best solution would have been for the ANS-Forth document to state emphatically that the search-order and CURRENT are never changed by the internal workings of the system, but are for exclusive use by the user. Pelc would have had to use SEARCH-WORDLIST to find his local variables --- but he would have managed --- and this would have allowed users such as myself to write SET-CONTEXT and be confident in it always working the same way. P.S. --- Thanks for your politeness! :-)
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2014-10-02 17:51 -0700 |
| Message-ID | <671c3bb9-7e30-4908-add9-5d35ae621d57@googlegroups.com> |
| In reply to | #33666 |
On Thursday, October 2, 2014 5:02:39 PM UTC-7, hughag...@yahoo.com wrote: > > P.S. --- Thanks for your politeness! :-) > You're welcome. That's a lot of explanation for a n00b like me to digest, but I will try to do so, and will post any further questions that may pop up. My spare time is limited, but this type of activity is my preferred method of unwinding after a long day at work, fixing old worn-out cars in a poor neighborhood. Take care, Mike
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-02 18:50 -0700 |
| Message-ID | <b939c898-f6cd-4cba-998d-60f740d427eb@googlegroups.com> |
| In reply to | #33669 |
On Thursday, October 2, 2014 5:51:22 PM UTC-7, Michael Barry wrote: > On Thursday, October 2, 2014 5:02:39 PM UTC-7, hughag...@yahoo.com wrote: > > > P.S. --- Thanks for your politeness! :-) > > You're welcome. That's a lot of explanation for a n00b like me to digest, > but I will try to do so, and will post any further questions that may pop > up. My spare time is limited, but this type of activity is my preferred > method of unwinding after a long day at work, fixing old worn-out cars in > a poor neighborhood. When I visited Testra recently, I noticed something like 8 cars in the parking lot. When I went inside, I asked: "Do you have an entire team of programmers working for you now?" I was told, no, they still just have the one programmer that they had when I was there 20 years ago --- the cars are not running --- they are just fixing them up in their spare time. lol
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2014-10-04 00:30 +0100 |
| Message-ID | <m0nbj4$qiv$1@dont-email.me> |
| In reply to | #33666 |
On 03/10/2014 01:02, hughaguilar96@yahoo.com wrote:
> On Thursday, October 2, 2014 4:35:30 PM UTC-7, Michael Barry wrote:
>> Hugh, could you be so kind as to explain the nature of the bug? I don't know
>>
>> Forth nearly well enough to find it myself, but I would like to learn, both
>> about its nature and your doubts in your ability to fix it.
>
> SET-CONTEXT assumes that the 1st wid in the search order is the wid that you want to replace. Sometimes this is true, and sometimes it is not true, and this varies from one ANS-Forth-compliant Forth system to another. In VFX, colon words with local variables will have a wid called LOCALVARS in 1st place in the search order during the compilation of the colon word, but semicolon removes it. If you execute SET-CONTEXT during the execution of a colon word that has locals, it will replace LOCALVARS rather than the wid that you expected to replace (the wid you thought was 1st is actually 2nd) --- chaos will result. I have only tested VFX so far
You are using VFX Forth in an area where it is less than perfect e.g.
using the current free version of VFX Forth (August 2014) [1]
: foo { bar } bar . [ previous ] bar . ;
Err# -13 ERR: Undefined word.
-> : foo { bar } bar . [ previous ] bar . ;
This is a greatly simplified version of a problem I had a few years ago
which I reported to MPE but, presumably, was not considered important
enough to fix.
Investigating further reveals inconsistent behaviour:
: x { y } [ order previous order ] ;
LOCALVARS FORTH EXTERNALS ROOT
Current: FORTH
FORTH EXTERNALS ROOT
Current: FORTH
ok
shows that the LOCALSVAR wordlist is removed by PREVIOUS.
However going back to the first definition and looking at the search
order after it fails to compile:
: foo { bar } bar . [ previous ] bar . ;
Err# -13 ERR: Undefined word.
-> : foo { bar } bar . [ previous ] bar . ;
^
order
EXTERNALS ROOT
Current: FORTH
ok
It seems to have removed the Forth wordlist as well as the LOCALSVAR
wordlist.
ALSO leaves LOCALSVAR in the search order after a definition is complete
: x { y } [ also ] ; order
LOCALVARS FORTH EXTERNALS ROOT
Current: FORTH
ok
GET-ORDER seems to return the LOCALSVAR wid. The following is a clear
non-compliance
1234 constant y ok
ok
: x { y } [ get-order forth-wordlist swap 1+ set-order ] y . ; ok
9999 x 1234 ok
See ANS Forth 13.3.3 1) " ... none of the Search-Order words shall
change the locals' privileged position in the search order. ..."
As I said - less than perfect behaviour. I don't think that any of the
other major systems have these problems. I agree that system wids should
not be placed in the search order.
[1] I know that using { for locals is not ANS Forth but the behaviour is
the same using LOCALS| and the Forth 200X {:
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-03 17:40 -0700 |
| Message-ID | <4bf7471b-6bf4-4cf9-a82a-ac561a15836b@googlegroups.com> |
| In reply to | #33685 |
On Friday, October 3, 2014 4:30:47 PM UTC-7, Gerry wrote:
> You are using VFX Forth in an area where it is less than perfect e.g.
> using the current free version of VFX Forth (August 2014) [1]
Well, I can't afford to buy the supported version, and I don't have any need for making stand-alone executables anyway (I'm writing a cross-compiler, and the users can run it out of the free-VFX's REPL).
> : foo { bar } bar . [ previous ] bar . ;
> Err# -13 ERR: Undefined word.
> -> : foo { bar } bar . [ previous ] bar . ;
>
> This is a greatly simplified version of a problem I had a few years ago
> which I reported to MPE but, presumably, was not considered important
> enough to fix.
You are correct; this violates: 13.3.3 1) " ... none of the Search-Order words shall change the locals' privileged position in the search order. ..."
I doubt that Pelc thought that this "was not considered important enough to fix." More likely, he purposely strives to undermine anybody's independent effort to write a cross-compiler, because cross-compilers are how he makes his money primarily. This is also why he made sure that SMUDGE was not in ANS-Forth --- the only people who need SMUDGE are those writing cross-compilers --- people writing Forth application programs are happy so long as : and ; behave as if they are internally using SMUDGE and UNSMUDGE (aka HIDE and REVEAL) --- weirdly enough, the ANS-Forth document requires : and ; to behave as if they are using SMUDGE and UNSMUDGE, but makes no mention at all of SMUDGE (not even in the section on porting programs from old standards to ANS-Forth).
Are you writing a cross-compiler? I can't think of any other reason why you would be doing word-list manipulations at compile-time inside of a colon word. I'm writing one for the ARM Cortex-M3 right now. If you are interested in getting involved, contact me by private email. I liked your quotation code that you sent me, btw (you are one of only a tiny handful of people on C.L.F. who actually writes Forth code, and are not just blowing hot air) --- my Forth will have quotations, but this will be implemented completely differently than your approach --- the compiler is for micro-controllers, so speed is of the essence!
> Investigating further reveals inconsistent behaviour:
> : x { y } [ order previous order ] ;
> LOCALVARS FORTH EXTERNALS ROOT
> Current: FORTH
>
> FORTH EXTERNALS ROOT
> Current: FORTH
> ok
>
> shows that the LOCALSVAR wordlist is removed by PREVIOUS.
This is what I said above regarding 13.3.3-1.
> However going back to the first definition and looking at the search
> order after it fails to compile:
>
> : foo { bar } bar . [ previous ] bar . ;
> Err# -13 ERR: Undefined word.
> -> : foo { bar } bar . [ previous ] bar . ;
>
> order
> EXTERNALS ROOT
> Current: FORTH
> ok
>
> It seems to have removed the Forth wordlist as well as the LOCALSVAR
> wordlist.
If your "it" referred to PREVIOUS, that is unlikely --- I don't think this is inconsistent --- more likely, it was QUIT that was called due to the crash, and it did an ONLY. I think that it is okay for QUIT to do ONLY because we want to get back to a rational state. I do wonder at why ONLY doesn't leave FORTH on the top of the search-order though --- putting us back in the REPL without FORTH in the search-order is not exactly putting us in a "rational state."
> ALSO leaves LOCALSVAR in the search order after a definition is complete
>
> : x { y } [ also ] ; order
> LOCALVARS FORTH EXTERNALS ROOT
> Current: FORTH
> ok
>
> GET-ORDER seems to return the LOCALSVAR wid. The following is a clear
> non-compliance
> 1234 constant y ok
> : x { y } [ get-order forth-wordlist swap 1+ set-order ] y . ; ok
>
> 9999 x 1234 ok
Yes --- Pelc seems to have no regard for 13.3.3-1 whatsoever --- all of the word-list jugglers have access to LOCALSVAR just like any other wid.
> I agree that system wids should
> not be placed in the search order.
It would have actually be quite easy to implement this correctly. Pelc could have put his locals in LOCALVARS but not put LOCALVARS in the search order. He could have just written FIND so that it does a SEARCH-WORDLIST of LOCALVARS first (giving LOCALVARS the "privileged position" that ANS-Forth requires), and then done a normal FIND of the search-chain.
It would take maybe one day of work to fix this problem, but I doubt that Pelc will do it --- I think he purposely strives to pull the rug out from under cross-compiler writers --- these are bugs that will never get fixed.
Over on this thread (https://groups.google.com/forum/#!topic/comp.lang.forth/-FDxsdLIIkU), everybody is bragging about making hundreds of dollars per hour programming in Forth --- so maybe Pelc doesn't fix the bug because his one-day of work required to fix the bug is worth thousands of dollars, and he is waiting for us to send him a check. ;-)
Of course, I haven't actually bought a copy of VFX (as mentioned above), so I can't really expect him to spring into action to fix bugs that I find in VFX (I did expect Forth Inc. to fix bugs that I found in SwiftForth, but that was different because I had paid over $400 for SwiftForth). It is a bug though, as it clearly violates 13.3.3-1 --- so even though I'm not paying him, he ought to fix it anyway. On a positive note though, this is the first bug I have found in VFX --- by comparison, every other Forth I tested my novice package on (SwiftForth, Gforth and Win32Forth) turned up bugs --- but I haven't yet tested all of my example programs in the novice package on VFX, so I can't say for sure that no bugs will turn up.
BTW: Gerry --- did you know Ray Duncan? He didn't fix two bugs in UR/Forth that I told him about. For the most part though, he was a good guy and his UR/Forth was a good system --- it would have been difficult for me to write MFX in any of the other Forth systems available at that time.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-10-03 23:00 -0700 |
| Message-ID | <345f59dc-e054-43b4-8822-dc2470dc24ed@googlegroups.com> |
| In reply to | #33687 |
>
>
> > ALSO leaves LOCALSVAR in the search order after a definition is complete
>
> >
>
> > : x { y } [ also ] ; order
>
> > LOCALVARS FORTH EXTERNALS ROOT
>
> > Current: FORTH
>
> > ok
>
> >
>
> > GET-ORDER seems to return the LOCALSVAR wid. The following is a clear
>
> > non-compliance
>
>
>
> > 1234 constant y ok
>
> > : x { y } [ get-order forth-wordlist swap 1+ set-order ] y . ; ok
>
> >
>
> > 9999 x 1234 ok
>
>
This simple code is a clear evidence of a bad design regarding locals implementation (not wordlists). For me it is more and more clear that local variables are really not welcome in the forth community.
VFX seems to be quickly patched to have local support without further testing or investigation.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-04 21:14 -0700 |
| Subject | Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <642444d6-5954-4fe4-9b6b-4d89c65e2d6b@googlegroups.com> |
| In reply to | #33689 |
On Friday, October 3, 2014 11:00:54 PM UTC-7, Raimond Dragomir wrote:
> This simple code is a clear evidence of a bad design regarding locals implementation (not wordlists). For me it is more and more clear that local variables are really not welcome in the forth community.
Wordlists are a bad design ("severely brain-damaged" in Ray Duncan's words). This is because ALSO duplicates the 1st wid of the search-order, which makes no sense. Forth is supposed to be context-free, but ALSO only makes sense in the context of being followed immediately by FORTH or some such word that replaces the 1st wid of the search-order with a new wid. This is a violation of the idea that Forth should not have any syntax --- exceptions are IF THEN etc. that have to be used in relation to each other --- but, for the most part, words are not supposed to require other words to fix what they left in a damaged state (which is what ALSO does).
Locals are a bad design too, mostly because LOCALS| takes its parameters backwards. In Forth-200x locals are a bad design because the locals to the right of the | are not zeroed out. But this has nothing to do with what we are discussing here, in regard to how locals relate to word-list juggling. ANS-Forth actually did something intelligent in 13.3.3-1 when it required that the word-list jugglers would not affect LOCALVARS --- but, sadly, that is the rule that Pelc violated in VFX --- so blame Pelc on this one, not ANS-Forth.
Also, I don't think that locals are not welcome in the Forth community --- this was true of Charles Moore who hates locals, and it was true up through the era of Forth-83 (UR/Forth was Forth-83 and it did not have locals, although MFX written in UR/Forth did have locals) --- but people realized that locals were a good thing and they were clamoring for them in the early 1990s, which is why ANS-Forth provided them. I used to be a purist in that I didn't use locals at all (see my LowDraw.4th program that was written about 10 years prior to the novice package), but I came to realize that they are useful --- so did everybody else.
> VFX seems to be quickly patched to have local support without further testing or investigation.
This may be an explanation for why VFX has a bug --- but it is not an explanation for why Pelc didn't fix the bug after Gerry told him about it.
I think Pelc is not going to fix the bug, because he wants to make life as difficult as possible for cross-compiler writers. But I have written a work-around for the bug in VFX! I said earlier that I had abandoned SET-CONTEXT --- but now I have figured out how to write SET-CONTEXT. This will go in the next novice package upgrade. Here it is (with the comments removed for brevity):
: set-forth ( -- )
only forth definitions ;
: get-context ( -- wid )
get-order dup 1 < abort" *** GET-CONTEXT given empty search-order ***"
over >r \ r: -- top-wid
0 do drop loop \ --
r> ;
: <push-context> { wid -- }
get-order
wid swap 1+
set-order ;
: <pop-context> ( -- wid )
get-order dup 1 < abort" *** POP-CONTEXT given empty search-order ***"
swap >r 1-
set-order
r> ;
: <drop-context> ( -- )
<pop-context> drop ;
false value localvars#
false value expected#
: fill-localvars# ( -- )
[ get-context to expected# ]
1 2 3 locals| x y z |
[
get-context expected# <> [if]
<pop-context> to localvars#
get-context expected# <> [if] .( *** FILL-LOCALVARS# can't find EXPECTED# ***) abort [then]
localvars# <push-context> [then]
] ;
: push-underneath { wid -- }
<pop-context>
get-context wid <> if
wid <push-context> then
<push-context> ;
: replace-1st ( wid -- )
push-underneath <drop-context> ;
: <set-context> { wid anchor -- }
get-context anchor = if
wid anchor = if exit then
wid <push-context>
exit then
get-context localvars# = if
<pop-context>
get-context anchor = if
wid <push-context>
else
wid replace-1st then
<push-context>
exit then
wid replace-1st ;
: set-context ( wid -- )
forth-wordlist <set-context> ;
: push-context { wid -- }
get-context localvars# = if
<pop-context> wid <push-context> <push-context>
else
wid <push-context> then ;
: pop-context { -- wid }
<pop-context>
dup localvars# = if
<pop-context> swap <push-context> then ;
: drop-context ( -- )
pop-context drop ;
char & comment \ this is for testing the word-list stuff
wordlist constant test1#
wordlist constant test2#
: test ( -- )
[ .( TEST1# = ) test1# u. ]
[ .( TEST2# = ) test2# u. ]
[ set-forth order ]
[ forth-wordlist set-context order ]
[ test1# set-context order ]
1 2 3 locals| x y z | [ order ]
[ test1# push-context order ]
[ drop-context order ]
[ test1# set-context order ]
[ test2# set-context order ]
[ test1# push-context order ]
[ drop-context order ]
;
order
set-forth
&
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-05 03:42 -0500 |
| Subject | Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <W9-dnb0odq4MmazJnZ2dnUU7-emdnZ2d@supernews.com> |
| In reply to | #33699 |
hughaguilar96@yahoo.com wrote:
>
> Wordlists are a bad design ("severely brain-damaged" in Ray Duncan's
> words). This is because ALSO duplicates the 1st wid of the
> search-order, which makes no sense.
I don't like it much, but it doesn't seem like a show-stopper; it's
an inconvenience.
> Forth is supposed to be context-free,
Since when? Forth has plenty of global context, by design. Forth has
never been a "pure" language in that sense.
> Locals are a bad design too, mostly because LOCALS| takes its
> parameters backwards.
Which is why ANS provided the tools to define locals in any syntax you
like. Given that there was insufficient common practice in this area
at the time there was nothing else that ANS could have done.
> In Forth-200x locals are a bad design because the locals to the
> right of the | are not zeroed out.
Eh? If you need a local to be zeroed, zero it. If you don't, don't:
Forth provides the freedom you need.
> Also, I don't think that locals are not welcome in the Forth
> community --- this was true of Charles Moore who hates locals, and
> it was true up through the era of Forth-83 (UR/Forth was Forth-83
> and it did not have locals, although MFX written in UR/Forth did
> have locals) --- but people realized that locals were a good thing
> and they were clamoring for them in the early 1990s, which is why
> ANS-Forth provided them. I used to be a purist in that I didn't use
> locals at all (see my LowDraw.4th program that was written about 10
> years prior to the novice package), but I came to realize that they
> are useful --- so did everybody else.
Not everyone: some Forthers use locals, some don't.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Enoch <emc.consultants@gmail.com> |
|---|---|
| Date | 2014-10-05 10:43 -0700 |
| Subject | Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <690c5e11-9357-49dd-903f-7106ced58201@googlegroups.com> |
| In reply to | #33703 |
On Sunday, October 5, 2014 4:42:59 AM UTC-4, Andrew Haley wrote:
> hughaguilar96@yahoo.com wrote:
>
> >
>
> > Wordlists are a bad design ("severely brain-damaged" in Ray Duncan's
>
> > words). This is because ALSO duplicates the 1st wid of the
>
> > search-order, which makes no sense.
>
>
>
> I don't like it much, but it doesn't seem like a show-stopper; it's
>
> an inconvenience.
>
... but wordlists can become easy to use:
AmForth <http://amforth.sourceforge.net/TG/Implementation.html> has introduced a deferred system word, called WLSCOPE, that selects which wordlist to add the created word to based upon its name.
For example, words beginning with underscore ('_'), can be put on a PRIVATE word list with no need for get-current / set-current wrapping.
Does any of the big name Forth implementations have anything similar?
Thanks, Enoch.
>
>
> > Forth is supposed to be context-free,
>
>
>
> Since when? Forth has plenty of global context, by design. Forth has
>
> never been a "pure" language in that sense.
>
>
>
> > Locals are a bad design too, mostly because LOCALS| takes its
>
> > parameters backwards.
>
>
>
> Which is why ANS provided the tools to define locals in any syntax you
>
> like. Given that there was insufficient common practice in this area
>
> at the time there was nothing else that ANS could have done.
>
>
>
> > In Forth-200x locals are a bad design because the locals to the
>
> > right of the | are not zeroed out.
>
>
>
> Eh? If you need a local to be zeroed, zero it. If you don't, don't:
>
> Forth provides the freedom you need.
>
>
>
> > Also, I don't think that locals are not welcome in the Forth
>
> > community --- this was true of Charles Moore who hates locals, and
>
> > it was true up through the era of Forth-83 (UR/Forth was Forth-83
>
> > and it did not have locals, although MFX written in UR/Forth did
>
> > have locals) --- but people realized that locals were a good thing
>
> > and they were clamoring for them in the early 1990s, which is why
>
> > ANS-Forth provided them. I used to be a purist in that I didn't use
>
> > locals at all (see my LowDraw.4th program that was written about 10
>
> > years prior to the novice package), but I came to realize that they
>
> > are useful --- so did everybody else.
>
>
>
> Not everyone: some Forthers use locals, some don't.
>
>
>
> Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-05 20:21 -0700 |
| Subject | Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <0cf773f7-8524-4426-be5f-7ce7d93d2c75@googlegroups.com> |
| In reply to | #33703 |
On Sunday, October 5, 2014 1:42:59 AM UTC-7, Andrew Haley wrote: > hughaguilar96@yahoo.com wrote: > > In Forth-200x locals are a bad design because the locals to the > > right of the | are not zeroed out. > > Eh? If you need a local to be zeroed, zero it. If you don't, don't: > Forth provides the freedom you need. I have gone over this repeatedly several times already --- like Sisyphus pushing that boulder up the hill. It is important for the system to behave consistently. If you don't initialize locals and globals to a known state, then your program will behave differently from one execution to another, or from one compilation to another. If the programmer forgets to explicitly initialize a variable before he uses it, the program may run correctly because by luck there was a value in the random garbage that it got initialized to that worked --- but this luck may run out at an awkward moment, like when the customer tries to run the program. This is programming-101 --- I would expect anybody with 6 months experience programming to know basic concepts such as the need to initialize to a known and consistent state. Over two decades ago you were on said in this thread? "Almost all of my Forth experience is with polyFORTH...." Now, in 2014, you still don't know basic programming ideas, such as the need for programs to be consistent from one run to the next and from one compilation to the next. Also, when I said that putting control-flow data on the parameter-stack was a bad idea, you were oblivious to why this would be, and you even continued to argue the point after I explained it. You have apparently never written a meta-compiling word, as you haven't noticed that when you write one you don't have access to the data on the parameter stack because there may or may not be control-flow data on top of it. You're an idiot! This is an indictment of Elizabeth Rather --- anybody who follows Elizabeth Rather must be an idiot, and if they aren't an idiot when they start, they will be pretty soon. In 1993, one year prior to ANS-Forth getting written in stone, Ray Duncan who is not an idiot described a crucial aspect of ANS-Forth as being "severely brain-damaged." After ANS-Forth came out, Ray Duncan gave up on Forth and moved on to other pursuits. Obviously, he had as much influence on the ANS-Forth committee as I have on the Forth-200x committee, which is zilch --- so he walked off. Two decades later, you are still here on C.L.F. and still just as ignorant of programming-101 concepts as you were in 1993. This is why I consider ANS-Forth to be a cult. Everybody who knew anything about programming was driven out, and those who knew nothing stayed for decades. Now here I am with one month of experience in VFX, and one week of that was spent writing a work-around for a bug in a crucial aspect of VFX (word-lists) that I need for my cross-compiler. I didn't have to waste time dinking around with stuff like this when I wrote MFX for Testra in UR/Forth (UR/Forth comes from Ray Duncan's company: LMI) --- LMI started producing Forth compilers about 30 years ago --- I would really expect a modern Forth system such as VFX to have fewer bugs, not more bugs, especially in regard to a fundamental aspect of Forth such as word-lists.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-06 03:58 -0500 |
| Subject | Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <zaidnb0N8LU8xK_JnZ2dnUU7-cmdnZ2d@supernews.com> |
| In reply to | #33712 |
hughaguilar96@yahoo.com wrote: > On Sunday, October 5, 2014 1:42:59 AM UTC-7, Andrew Haley wrote: >> hughaguilar96@yahoo.com wrote: >> > In Forth-200x locals are a bad design because the locals to the >> > right of the | are not zeroed out. >> >> Eh? If you need a local to be zeroed, zero it. If you don't, don't: >> Forth provides the freedom you need. > > I have gone over this repeatedly several times already --- like > Sisyphus pushing that boulder up the hill. > > It is important for the system to behave consistently. If you don't > initialize locals and globals to a known state, then your program > will behave differently from one execution to another, or from one > compilation to another. So, don't use uninitialized locals, then. It's your choice. > If the programmer forgets to explicitly initialize a variable before > he uses it, the program may run correctly because by luck there was > a value in the random garbage that it got initialized to that worked > --- but this luck may run out at an awkward moment, like when the > customer tries to run the program. Yes, that's true, but this is Forth, not Java. Forth doesn't force initialization on programmers: they have the freedom to shoot themselves in the foot if they wish. Anyway, I don't believe it. If a programmer does not expect local temporaries to be zeroed, why would they make this mistake? And why zero, anyway? Why not DEADBEEF or somesuch? > Over two decades ago you were on said in this thread? Eh? > "Almost all of my Forth experience is with polyFORTH...." Now, in > 2014, you still don't know basic programming ideas, such as the need > for programs to be consistent from one run to the next and from one > compilation to the next. Also, when I said that putting control-flow > data on the parameter-stack was a bad idea, you were oblivious to > why this would be, and you even continued to argue the point after I > explained it. I did, because your "explanation" was incorrect. The problem with your metacompiling words was not that the control flow stack was in your way, but that they were badly factored and far too long. The control flow stack did not force you to do that. > You have apparently never written a meta-compiling word, as you > haven't noticed that when you write one you don't have access to the > data on the parameter stack because there may or may not be > control-flow data on top of it. You're an idiot! This is an > indictment of Elizabeth Rather --- anybody who follows Elizabeth > Rather must be an idiot, and if they aren't an idiot when they > start, they will be pretty soon. Aha! It must have been when I was fitted with the implants. But why bother actually arguing the technical points when you can instead attack the person you're talking to? That would take some effort, I suppose. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-05 17:09 -0700 |
| Subject | Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <df692d5f-1af7-4c9c-88f5-b3ad11f475e6@googlegroups.com> |
| In reply to | #33699 |
On Saturday, October 4, 2014 9:14:07 PM UTC-7, hughag...@yahoo.com wrote:
> ...I have written a work-around for the bug in VFX!
Holey buckets! I found another bug in VFX --- DEFINITIONS doesn't work either (meta-compiled words end up in LOCALVARS rather than the expected word-list) --- this isn't really another bug, it is just another manifestation of the bug we have been discussing regarding LOCALVARS getting in the way
Here is a new version of my code with DEFINITIONS and GET-CONTEXT fixed so they will work inside of colon definitions at compile-time. This is only a slight upgrade from what I posted previously (once again, comments are removed for brevity).
: set-forth ( -- )
only forth definitions ;
: <get-context> ( -- wid )
get-order dup 1 < abort" *** GET-CONTEXT given empty search-order ***"
over >r \ r: -- top-wid
0 do drop loop \ --
r> ;
: <push-context> { wid -- }
get-order
wid swap 1+
set-order ;
: <pop-context> ( -- wid )
get-order dup 1 < abort" *** POP-CONTEXT given empty search-order ***"
swap >r 1-
set-order
r> ;
: <drop-context> ( -- )
<pop-context> drop ;
false value localvars#
false value expected#
: fill-localvars# ( -- )
[ <get-context> to expected# ]
1 2 3 locals| x y z |
[
<get-context> expected# <> [if]
<pop-context> to localvars#
<get-context> expected# <> [if] .( *** FILL-LOCALVARS# can't find EXPECTED# ***) abort [then]
localvars# <push-context> [then]
] ;
: push-underneath { wid -- }
<pop-context>
<get-context> wid <> if
wid <push-context> then
<push-context> ;
: replace-1st ( wid -- )
push-underneath <drop-context> ;
: <set-context> { wid anchor -- }
<get-context> anchor = if
wid anchor = if exit then
wid <push-context>
exit then
<get-context> localvars# = if
<pop-context>
<get-context> anchor = if
wid <push-context>
else
wid replace-1st then
<push-context>
exit then
wid replace-1st ;
: set-context ( wid -- )
forth-wordlist <set-context> ;
: get-context ( -- wid )
<get-context>
dup localvars# = if drop
<pop-context> <get-context>
swap <push-context> then ;
: definitions ( -- )
get-context set-current ;
: push-context { wid -- }
<get-context> localvars# = if
<pop-context> wid <push-context>
<push-context>
else
wid <push-context> then ;
: pop-context { -- wid }
<pop-context>
dup localvars# = if
<pop-context>
swap <push-context> then ;
: drop-context ( -- )
pop-context drop ;
char & comment \ this is for testing the word-list stuff
wordlist constant test1#
wordlist constant test2#
: test ( -- ) \ this tests SET-CONTEXT
[ cr .( TEST1# = ) test1# u. ]
[ cr .( TEST2# = ) test2# u. ]
[ cr .( FORTH-WORDLIST = ) forth-wordlist u. ]
[ set-forth order ]
[ get-context cr .( context = ) u. order ]
[ forth-wordlist set-context order ]
[ test1# set-context order ]
1 2 3 locals| x y z | [ order ]
[ get-context cr .( context = ) u. order ]
[ test1# push-context order ]
[ drop-context order ]
[ test1# set-context order ]
[ test2# set-context order ]
[ test1# push-context order ]
[ drop-context order ]
;
order
set-forth
: test-forth ( -- ) \ this tests FORTH
[ set-forth cr .( test-forth) order ]
[ forth order ]
1 2 3 locals| x y z | [ order ]
[ forth order ] \ this fails under VFX
;
order
set-forth
&
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2014-10-06 11:15 -0700 |
| Subject | Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <45d05d06-5acf-4792-96cd-ab32e411a18b@googlegroups.com> |
| In reply to | #33709 |
On Sunday, October 5, 2014 5:09:55 PM UTC-7, hughag...@yahoo.com wrote: > > Holey buckets! I found another bug in VFX --- DEFINITIONS doesn't > work either (meta-compiled words end up in LOCALVARS rather than the > expected word-list) --- this isn't really another bug, it is just > another manifestation of the bug we have been discussing regarding > LOCALVARS getting in the way > > Here is a new version of my code with DEFINITIONS and GET-CONTEXT > fixed so they will work inside of colon definitions at compile-time. > This is only a slight upgrade from what I posted previously (once > again, comments are removed for brevity). > Hugh, may I politely request that you _not_ remove comments for the sake of brevity. It would make learning much easier for me. In the course of my part-time studies, I have seen references to numerous Forth stacks: parameter, return, control, leave, float, etc. It is my impression that only the first two are omni-present, but that the others can provide useful work-arounds for more advanced coding techniques. Do you (or anyone else here) have any opinions on the use of one of the others for implementing locals, or perhaps even a dedicated local stack, if one doesn't already exist? Thanks, Mike
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web