[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gforth] Another single-char name conflict
From: |
Ethan Gardener |
Subject: |
[gforth] Another single-char name conflict |
Date: |
Sat, 06 Jul 2019 11:46:31 +0100 |
User-agent: |
Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 |
I found another unexpected single-character name, `l`, defined in
current/locate1.fs:100:3 . This time, I've compiled a crude test to check, by
seeing "redefined" messages, what 1-character names are exposed. The code is
below, I reserve no rights. Using it, I found several 1-character names
exposed in the forth vocabulary at startup. I'm aware some names are expected
to conflict, but the redefined warnings are a little worrying when I don't know
what functionality I'm locking myself out of. (Charles Moore wrote of `i`
having different meanings: to the editor it's "insert"; in counted loops it's
the index.) I found the conflict by loading current/blocked.fs which defines
`l` in the forth vocabulary. (I'm using blocked temporarily, I got fed up with
switching to other editors on my kindle fire and my own in-forth file editor
turned out to be a bad design.)
In latest gforth on Android, the following 1-character names appear:
current/locate1.fs: b g l n
current/mini-oof-2.fs: m o
arm/gforth/site-forth/starta.fs: t
Code:
\ Removed from list:
\ standard 1-char words,
\ `k`, `{`,
\ closing brackets.
\ Documents referenced for standard:
\ Forth Programmers Handbook,
\ DPANS94. Documents checked by eye only.
: " ;
: $ ;
: % ;
: & ;
: a ;
: b ;
: c ;
: d ;
: e ;
: f ;
: g ;
: h ;
: l ;
: m ;
: n ;
: o ;
: p ;
: q ;
: r ;
: s ;
: t ;
: u ;
: v ;
: w ;
: x ;
: y ;
: z ;
: ^ ;
: _ ;
: ` ;
: | ;
: ~ ;
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [gforth] Another single-char name conflict,
Ethan Gardener <=