Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #25031
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Adding NTs or making XTs the only opaque Forth type |
| Date | 2013-08-06 07:01 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2013Aug6.090159@mips.complang.tuwien.ac.at> (permalink) |
| References | <ktp0gt$mif$1@dont-email.me> |
"Alex McDonald" <blog@rivadpm.com> writes:
> the TC's unwritten
>intention, expressed by Elizabeth Rather, that an xt as a single opaque
>type.
It's unclear what that means, however, if there was such an intent at
all. A few interpretations that come to mind:
1) They did not like the words for dealing with headers in systems
like fig-Forth: There you have one header with name field, link field
code field, and parameter field, and words for going from one field to
the next. To go from the name field to the parameter field, you had
to do something like "1 TRAVERSE LFA> >PFA". I think it's very likely
that this is what Elizabeth Rather is remembering, and I think we can
find consensus that we do not want this kind of design.
2) They did not standardize stuff like NT>STRING, because that would
have required putting an NT in the standard, and they (or at least
some of them) did not want to go there.
3) Each named word has one xt and that represents everything about it.
If that was the unwritten intent, it directly contradicts the written
intent of supporting different implementation approaches, including
ones where interpretation semantics and compilation semantics are
associated with different xts (which is reflected in the normative
specification of FIND and maybe other places). And it is incompatible
with the specification of COMPILE, (one can destandardize the xts of
S" and TO to work around that, but that's incompatible with this
version of the claimed intent).
4) A named word can have several parts, and each one of them is
represented by an xt (but there can be several xts associated with a
named word).
>Systems that would be adversely affected are Gforth 0.7.0 and lxf/ntf.
The fact that there are several systems that cannot satisfy Stephen
Pelc's nt=xt requirement without significant changes deep in their
bowels makes me suspect that there are more.
>Stephen points out that, even though it might potentially be an expensive
>operation to find the header, the cost is immaterial given that this is a
>tools feature where operation cost is not as important.
I have used access to the name of the word in application contexts. I
would expect that NT>STRING would be used that way, too. So
perfomance of NT>STRING is relevant.
>> Given that this stuff is already used in practice according to the
>> responses, maybe the way to go forward is to get a CfV version out at
>> some point (so that the spec does not change anymore), and then let
>> user demand do its magic. If there are several systems that implement
>> your proposal, and programs that use it, maybe even the most
>> fundamentalist "nts are evil" advocate will see the value of the
>> proposal eventually. After all, they can console themselves with "my
>> system does it better".
>
>I suspect that Stephen would take the opposite position and the lack of
>consensus would simply move to the CfV with his as a major voice of
>dissent. Stephen makes a living out of his product, and changes cost him
>real money.
But allowing nt!=xt would not require a change in his product, as
nt=xt would be allowed. By contrast, requiring nt=xt would require a
changes in other products, and he has said so in this discussion. I
guess he is so nonchalant about that because it's not his product that
would be affected. If it was his product he would use
"disenfrenchise" in every posting.
- 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 2013: http://www.euroforth.org/ef13/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
Adding NTs or making XTs the only opaque Forth type "Alex McDonald" <blog@rivadpm.com> - 2013-08-05 21:11 +0100
Re: Adding NTs or making XTs the only opaque Forth type anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-06 07:01 +0000
Re: Adding NTs or making XTs the only opaque Forth type stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-06 16:10 +0000
Re: Adding NTs or making XTs the only opaque Forth type Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-06 22:22 +0200
Re: Adding NTs or making XTs the only opaque Forth type stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-06 15:54 +0000
Re: Adding NTs or making XTs the only opaque Forth type albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-06 17:43 +0000
Re: Adding NTs or making XTs the only opaque Forth type "Elizabeth D. Rather" <erather@forth.com> - 2013-08-06 13:16 -1000
Re: Adding NTs or making XTs the only opaque Forth type "Elizabeth D. Rather" <erather@forth.com> - 2013-08-06 13:55 -1000
Re: Adding NTs or making XTs the only opaque Forth type Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-07 02:33 +0200
Re: Adding NTs or making XTs the only opaque Forth type "Alex McDonald" <blog@rivadpm.com> - 2013-08-07 16:29 +0100
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-07 10:54 -0500
Re: Adding NTs or making XTs the only opaque Forth type "Alex McDonald" <blog@rivadpm.com> - 2013-08-07 17:10 +0100
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-07 12:06 -0500
Re: Adding NTs or making XTs the only opaque Forth type "Alex McDonald" <blog@rivadpm.com> - 2013-08-07 18:43 +0100
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-07 12:47 -0500
Re: Adding NTs or making XTs the only opaque Forth type "Alex McDonald" <blog@rivadpm.com> - 2013-08-07 19:14 +0100
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-07 15:13 -0500
Re: Adding NTs or making XTs the only opaque Forth type "Alex McDonald" <blog@rivadpm.com> - 2013-08-07 23:09 +0100
Re: Adding NTs or making XTs the only opaque Forth type anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-08 13:45 +0000
Re: Adding NTs or making XTs the only opaque Forth type "Alex McDonald" <blog@rivadpm.com> - 2013-08-08 15:41 +0100
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-08 10:29 -0500
Re: Adding NTs or making XTs the only opaque Forth type anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-08 16:15 +0000
Re: Adding NTs or making XTs the only opaque Forth type Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-08 19:25 +0200
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-08 14:05 -0500
Re: Adding NTs or making XTs the only opaque Forth type anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-12 16:28 +0000
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-12 12:44 -0500
Re: Adding NTs or making XTs the only opaque Forth type anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-13 07:08 +0000
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-13 03:40 -0500
Re: Adding NTs or making XTs the only opaque Forth type anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-13 09:47 +0000
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-13 05:55 -0500
Re: Adding NTs or making XTs the only opaque Forth type anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-13 12:18 +0000
Re: Adding NTs or making XTs the only opaque Forth type Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-13 10:32 -0500
csiph-web