Re: FORTH levels

John Passaniti wrote:
John Doty wrote:
It's funny how you carefully manage to find a way to misinterpret the point I'm trying to make.

I'm not sure why you blame me for misinterpreting your points when it is the quality of your arguments that drives my interpretation. No matter, as your reply indicates, I didn't misinterpret you. What I failed to do was endlessly and tediously make the same semantic distinctions you do.

You endlessly and tediously recast my points into your world view, which I do not share, and in which my opinions are indeed meaningless.


Again, your model of programming as an activity of programmers fails. Most working on a collaborative project do not choose the programming language they are using: it is thrust upon them by the needs of the collaboration.

Sorry, I don't get your word salad.

Today, I am doing some programming. I would like to be doing this in LSE64: I think it's a good match to this problem. However, I have a firm request from my collaborators that I should use C here. C is, in this case, thrust upon me by the needs of the collaboration: LSE64 is not a possible choice.

> ...

Indeed. And I am saying that the problem is that there is not a language with a user-friendly syntax and Forth-like model of computation. There is no reason this should be so: let's work on fixing it rather than denying it, OK?

There is no denial here. There is strong disagreement as to what the problem is.

You seem to think the problem is syntax-- that once Forth is "user friendly" that a rich and vibrant community will spontaneously form around it.

Wrong article. "A problem", not "the problem".

Yet, I can think of plenty of examples where the opposite was true. When Iverson and Hui came up with J-- in part to remove APL's special character set and make it more "user friendly" not much of a community formed around it. Perl is in many senses a very user unfriendly language, filled with quirky syntax and questionable semantics, yet a very strong community formed around it.

Perl is strange. I wouldn't know where to start writing a Perl script, yet I have repeatedly customized spicepp.pl to accomplish shifting goals. And people who are by not by any reasonable stretch of the term "programmers" seem to take to Perl. I offer no explanation, just observations. Understanding this might help us with our problem.


The problem I see in Forth isn't in syntax or semantics. The problem is that I can't reliably share code between Forths. We see it "in the small" here in comp.lang.forth all the time. Someone posts a blob of Forth code, and then shortly after, someone else writes "you used the word foobar, but that's not in my Forth." Then we hear "oh, you need this toolbelt" or "that's a nonstandard word included in my Forth" or "oh yeah, I forgot to include that."

That's indeed another problem.


Yet when you look at other language newsgroups, you don't see this. In part, this is because there is often a single canonical language implementation. But even when there isn't (such as C), it's rare to see this.

That to me is the fundamental problem Forth has with respect to building a community. For those people who choose to be part of the community, there needs to be standards. There needs to be ways to describe and resolve dependencies.

And that needs to be pretty automatic.

There needs to be ways that people can contribute code on a deeper level than tossing it on a site like Taygeta and saying "good luck." To have a community, you need ways not just to share code, but to document it. You need ways to allow people to run test suites in a standardized manner so they can have confidence that the code does what it claims. There needs to be ways to install that code locally, handling versioning and namespace issues.

I agree completely.


These are the kinds of things that matter. It's the plumbing that allows a community to form. And when you look at *every* successful programming language, you see these kinds of things supporting the community.

You are saying that you are comfortable with explicitly telling the computer what to do, instead of letting the language deduce what you want.

If I want that, I use an assembler, not Forth. And in truth, if I *really* want machinery that does exactly what I want it to do, I design custom hardware. You're fooling yourself if you believe Forth is "explicit". It's no more explicit than C.

What you want is irrelevant. The issue is what Forth provides.

Please provide an example where Forth does something-- anything-- that is not explicit. I can't think of anything like C's type coercions, C's keeping track of the size of objects for pointer math. Again, provide an example of anything in Forth that isn't explicit.

: add1 1 +

What is "32767 add1" going to yield? If I write it in assembly language, I know, because I choose the data encoding explicitly. Even C gives me more control here.


You are saying that you understand the stack; that it isn't just an arbitrary feature of the language, but something integral to it.

Here we disagree. The stack is an implementation technique for trivially evaluating RPN. But RPN does not require a visible stack, any more than any language requires a visible stack to rebuild its semantic trees from its flat expression.

Then please put your money where your mouth is. If the stack is a mere implementation detail (and not a tool the programmer can and should exploit), then I would expect that LSE64 would show the world that a visible stack wasn't necessary.

Been thinking about that.


Yet, I see stack manipulation words in your lexicon. If the stack is an implementation detail, why wouldn't you march forward into the future and eliminate it from the lexicon. You seem fond of forcing your users into other activities, and you seem to think that stack manipulation should be replaced with named variables. So why the stack manipulation words in the lexicon?

Because that reflects my thinking of ~4 years ago, and were copied from the original LSE and Standard Forth (LSE didn't have "over"). These discussions have changed some things in my mind. They haven't made it into the code yet, and they're still evolving. I probably won't call the result LSE anymore.


Perhaps more to the point, if a visible stack has no (or little) value to you, then why are you fixated on a RPN notation for your language? Of what value does RPN have to end user if they don't have explicit control over the stack? Why not just go infix, and instantly make your language more familiar to the vast number of programmers out there?

Can't I go with both? RPN for cases where you want to see things explicitly in order, infix for when readability is more important. Mathematica has five different forms for expression input, and that's very helpful.


Again the hermit programmer model. As I have repeated said, Forth fits hermit programmers well. It fits collaborations poorly.

Which has nothing to do with the language itself-- or at least you have failed to demonstrate the connection. Sorry, repeating yourself endlessly doesn't make your claims any more true. Examples would be nice, but that would require you know Forth:

I know a particular dialect of Forth extremely well.

But you don't know the predominate language that 98% of the programmers on the planet recognize as Forth.

98% of the programmers on the planet wouldn't be able to tell the difference.


Or at least, you don't know it practically, since you do no coding in Forth.

Typical of your sophistry. Use a different definition from mine, and then try to reason from it.

Sorry, I don't have to accept your definitions when those definitions serve only to obfuscate.

But they don't obfuscate: they just don't fit your world view. More denial.

And I'm sorry that I don't play your silly game of endlessly qualifying Forth with prefixes like "traditional" or "Standard" or whatnot.

Is ColorForth Forth? Chuck Moore seems to think so. Is that a "silly game".


But hey, let's play your game. Okay, you know a particular dialect of a language in the Forth family extremely well. That statement says nothing about your experience with "traditional" or "Standard" Forth. It would be like someone who was a Postscript expert but who didn't have any serious experience with Forth coming in comp.lang.forth and pontificating about what is wrong with Forth. No, the best he can do is to say "I find this valuable in Postscript and it's missing from Forth."

And yet users have left Forth in droves. That is a fact. You may disagree with my interpretation, but you can't deny the fact. Something is wrong, probably several things, and I appreciate all attempts to repair the damage, even those which don't address my interpretation of the problem. We can learn from progress, but stagnation has few lessons to teach.


So you are placing yourself in the set of inexperienced Forthers and arrive at an evaluation of "clearer code" from that inexperience.

No. Truthfully, I don't think I was *ever* really inexperienced in the sense I was trying to get there. I studied Elizabeth's papers years before I got my hands on an implementation. I'd used METASYMBOL, which some identify as ancestral to Forth. I took a look at Jon Sachs' design for STOIC (and I wish I'd thought these issues out at the time: I could have been a better reviewer). I maintained Bob Frankston's ECD basic, whose foundation was kind of a cross between Forth and Lisp. I implemented a text markup language in ECD's editor language, which was kind of a cross between Forth and TECO. I owned one of those wonderful HP RPN calculators. So I think I had an awful lot of relevant background right from the beginning when I started using LSE.

But you haven't used Forth. You've used ancestors and antecedents of Forth. You've played with languages that had Forth-like features. And gosh, you even owned a RPN calculator.

That's like saying that you've played every flight simulator and are expert at them all. But you don't have any real flight time. Well guess what-- I don't want to go up in a plane with you.

I understand the set of values experienced Forthers take. In many ways, I share them. However, I have found them to be a barrier to collaboration. I cannot ignore this problem.

Let's break this nonsense down:

1. You understand the set of values of experienced Forthers. This means Forth programmers using "traditional" or "Standard" Forths.

There are few others left. There a few left period.


2. You have said you don't have direct knowledge of "traditional" or "Standard" Forth.

Oh, come on. I've played around with gforth. It's just a lot more complexity for a modest gain in capability relative to LSE. If it had a serious user community, I'd be using it.


3. Yet despite not having actual experience in the language used by those in number 1, you have found those values are a barrier to collaboration.

Explain.

Observation. I have seen traditional Forth disappear from astronomy. Indeed, from where I was, it seemed LSE held out longer (it's still in use in one application).

I never said that, and in fact one of the things I like about LSE is that it forces factoring. The newbie code I've referred to was highly factored.

Illustrate. You've said that you prefer a style of coding where people use named variables. Your language doesn't support locals, so one would presume this "highly factored code" from newbies uses named variables.

Indeed.

DIRECT : -1 ;CCD !
SPEC : 1 ;CCD !
=SSET : ;T1 ! ;=SP ! ;=SL ! ;=SC ! ;=SIP ! ;T1 @
=DSET : ;=DP ! ;=DL ! ;=DC ! ;=DIP !
=PSET : ;CCD @ .DUP IFPZ =SSET IFN =DSET
=CLK : ;CCD @ .DUP IFPZ =SCLK IFN =DCLK
=READOUT : PWHEN "LF 0 -1 1 1 =PSET =CLK

All words whose names start with ; are variables (community convention).

DIRECT selects the direct imaging CCD.
SPEC selects the spectroscopy CCD.
=SSET sets up operating parameters for the spectroscopy CCD.
=DSET sets up operating parameters for the direct CCD.
=PSET sets up operating parameters for whichever CCD is selected.
=CLK operates the clocks to readout the selected CCD.
=READOUT prints a timestamp, reads out the selected CCD using default parameters.

Pretty simple and klunky, no? That's the style. Lots of duplication, selected through ;CCD. Communication between high level acquisition and low level driver functions through static parameter sets. I don't expect you to like it, but it worked and a bunch of people found it comprehensible. Indeed, the scientist in charge of this project (not a programmer!) thought this kind of code unusually comprehensible.


And then when you've shown examples to illustrate the point, show us not only that the code is merely "clearer" but show that it is *better* than an equivalent solution in Forth.

I don't think any explanation would make sense with your wordview. And the people who did this didn't leave a rationale for the approach: they just did it, and they and its users found it comprehensible and highly effective. When I inherited it, I found it comprehensible, too (and then I proceeded to mess it up, I think).


Instead, we should pretend that Forth is just another flavor of Algol with a different syntax-- let's just treat the stack as an unfortunate design choice when Forth was created.

No. Algol is not what I'm after. We already have C: we do not need another extended Algol.

This reply is not very helpful. Instead of telling me what we don't need, tell me what we do.

( a add1 ) : a 1 +

and then you hit a key in the editor and it mutates to:

add1(a) : (a+1)

and a different key mutates it back.

Or maybe something completely different. Forth used to be about surprises, radically different code doing things never thought of. Show me a new idea.


I asked a pointed question-- is the stack in Forth an unfortunate design choice that should not have been made visible to the programmer. Answer the question, and then answer what a RPN-based language that doesn't have a visible stack looks like to the programmer. To me, it sounds like you want a RPN version of C.

Or maybe more like an RPN version of Python. Or maybe not RPN. But critically:

1. Interactive.
2. Based on the iron.
3. Acceptable to ordinary users.

C fails (1), Python fails (2), Forth fails (3). We can choose any combination of two right now, today, so there seems to be no fundamental incompatibility of these requirements. (3) is the most difficult, as things like C and Perl pass this test, and that's hard to understand. That's no excuse for not trying, though.


Those are Forth. Use "traditional Forth" or "Standard Forth" if that's what you mean. Be clear.

The forum sets the context. If we were at Intellasys, "Forth" might mean "ColorForth." If we were sitting in your office, "Forth" might mean LSE64. We're not in either place. We're in a newsgroup that has a long history of discussing "traditional" and "Standard" Forth. We have no need to prefix Forth except when that shared context isn't valid.

I know you wish it wasn't so. Too bad.

Your opinion. But we *do* get discussions of other Forths here: that they don't fit your worldview doesn't make them absent.


They aren't the only things that need fixing. But if the design drives users away, you can't get community.

Claim without evidence. Boring.

Eh? How you gonna have community without users?

--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor necessary to establish practical, real world truth. Those who attempt to use logic for that purpose are abusing it.
.