How to fix FIG? (was: What's wrong with FIG ?)
Doug Philips
sec...@msdsws.enet.dec.com (Strong datatypes for weak minds.) writes:
+ keep the
+general look and feel of Forth Dimensions but drop back to printing
+it more cheaply on newsprint or something (a la Nuts and Volts or
+Covox documentation).
That is a sentiment I generally agree with. As I recall, the new slick
format was considered necessary for newstand sales. Have I somewhere
missed a report on how the newstand stuff is doing? If so, please remind
me with a pointer. If not, please post the information. But, even
if newstand sales have been good, surely there are less flashy/expensive
ways to make the magazine saleable???
+I am not one to "defect" a la Koopman nor one that fails to appreciate
+the valiant efforts of those who put in a lot of hard work to keep FIG
+alive. Know however that the situation of the prices increases versus
+the perceived signal-to-noise ratio of 4D is ticking off the Forth
+community at large and they're not going to put up with it for much
+longer; now all an estranged cowboy has to do for a fix is reach as
+far as the latest issue of Embedded Systems magazine.
I agree here too. I don't recall seeing any reply to this... Perhaps I
should print it off and mail it to FIG for comment?
Ok, there is a student rate now, but how many student subscribers
are there? and what are the renewal rates, student and otherwise?
-Doug
---
Preferred: d...@willett.pgh.pa.us Ok: {pitt,sei}!willett!dwp
Jack J. Woehr
>That is a sentiment I generally agree with. As I recall, the new slick
>format was considered necessary for newstand sales. Have I somewhere
>missed a report on how the newstand stuff is doing? If so, please remind
>me with a pointer. If not, please post the information. But, even
>if newstand sales have been good, surely there are less flashy/expensive
>ways to make the magazine saleable???
Newsstand sales have pretty much only occurred at one newsstand:
Computer Literacy Bookstore in the Valley. This is one of those efforts
that never got anyone to push behind it and went nowhere much.
>+I am not one to "defect" a la Koopman nor one that fails to appreciate
>+the valiant efforts of those who put in a lot of hard work to keep FIG
>+alive. Know however that the situation of the prices increases versus
>+the perceived signal-to-noise ratio of 4D is ticking off the Forth
>+community at large and they're not going to put up with it for much
>+longer; now all an estranged cowboy has to do for a fix is reach as
>+far as the latest issue of Embedded Systems magazine.
Your criticism is noted. We of the Forth Interest Group Board of
Directors are bailing the boat as fast as possibly, albeit not always
in the same direction :-) We are supposed to have another meeting this
month, online, to continue the effort we started. Suffice it to say that
if we break the pattern and it turns out that this Board and its new
members manage to accomplish more than talk, you will start seeing
changes in the magazine with the new volume.
Right now, the issue really is, will there be a Forth Interest
Group after Volume XIV of the magazine? I wish I could say for sure that
the answer is, "Yes", but I can't in good conscience. It's up to y'all.
Get them slackers to subscribe and we can improve things! There ain't
nothing wrong with FIG right now that 1,000 new members wouldn't cure,
and that damn fast, you petcha by yumpin' yiminy!
=jax=
--
# jax@well.{UUCP,sf.ca.us} # # Member, # # Vice President, #
# du!isis!koscej!jax # # X3J14 TC # # Forth Interest Group #
# JAX on GEnie # # for ANS # # P.O. Box 8231 #
# SYSOP RCFB (303) 278-0364 # # Forth # # San Jose CA 95155 #
Chris Waters
>B.RODRIGUEZ2 [Brad] at 20:33 EDT
>
>Chris Waters writes:
> > ...carnal knowledge of the headers, threading mechanism, etc.,
> > is required to build debugging tools, but not to write apps.
> > Even metaprogrammatic apps.
>I beg to differ. My expert system, which represents rules as Forth words, has
>a 'trace' option which allows the user to observe which rules are firing.
>This requires the ability to print the header.
Sounds like a debugging tool to me! :-)
This is right on the edge, I'll admit, between being a debugging tool
and being part of the app. But the fact is that this may not work in
existing 79 or 83 standard Forth systems.
Which is something that a lot of people are ignoring: these various
techniques that people complain about dpANS making illegal. They're
*ALREADY* illegal in the existing Forth standards. Yet that doesn't
seem to have stopped anyone from *using* these techniques. Why do you
imagine that the situation will be any different when dpANS becomes
official? Actually, dpANS makes a *LOT* of things possible in a
portable fashion which were *NOT* possible with earlier standards. Such
as locals, CATCH & THROW, file input, etc.
>I also have had frequent need for knowledge of the threading mechanism, e.g.,
>to write dual-action or redefinable words. Now, I _don't_ expect this ever to
>be portable, but I wanted to make the point that some real applications _do_
>use this 'carnal knowledge.'
Yes, just as many non-Forth applications for, say, the PC make use of
carnal knowledge of the PC's BIOS and hardware.
Actually, I've written dual-action and redefinable words in pure
standard high-level Forth. It may not be quite as efficient as, say,
writing vectoring code with ;CODE, but it certainly can be done in a
thread-independent manner. *If* portability is a concern.
Personally, what I try to do, when writing code in *any* language, is
use all the machine/OS/whatever dependencies I want. But I keep them
isolated from the main body of code, in separate modules.
It means that my apps take a little work to port, but they usually run
better too. Portability almost *always* implies a performance loss.
In any case, separate headers and various threading techniques are
common existing Forth practice. So any attempt to legislate these out
of existence is almost certainly doomed to failure.
But now, for a bit of a left turn in topic:
Brad mentioned that it looks like dpANS forbids using R> DROP to
terminate a calling word. (And I agree, it looks that way.) Now,
*this* is something that will work in *every* Forth system I've ever
seen (and I've seen some pretty strange ones). So, I'd really like to
know if the committee just forbid this on general principles? Or if
there was actually some solid justification.
Unless there's a damn good reason, y'all can count me as a vote for
making this a legal technique in standard Forth.
Right now (at least in Basis17), it says about a colon definition:
( i*x -- j*x ) ( R: -- sys )
I.e. a colon definition has an unspecified effect on the parameter
stack, and adds an unspecified amount of data to the return stack. This
could easily be changed to:
( i*x -- j*x ) ( R: -- x )
I.e. a colon definition has an unspecified effect on the parameter
stack, and adds ONE CELL to the return stack. And viola! We may not
know what that cell is, but we can certainly discard it. :-)
(May need some clarification about what that cell is: a magic cookie
that identifies the calling routine through some unspecifed mechanism.)
I think it's doable--any comments? Has the TC considered and rejected
this already?
--
Chris Waters | the insane don't | NOBODY for President!
xt...@netcom.COM| need disclaimers | Because Nobody's perfect!!
Mitch Bradley
Regarding the "R> DROP" and/or UNNEST proposal:
I expect that some implementations of local variables will want to use
the return stack for the "cleanup on exit" behavior. Obviously, there
are other ways to implement this behavior, but the return stack technique
is certainly common.
Also, pushing error interception frames on the return stack is the common
implementation technique for CATCH / THROW . Entitling R> DROP is
antithetical to that technique.
Finally, entitling R> DROP might prevent tail recursion elimination.
Mitch