Andrew Haley wrote:
> John Doty
whispertel.losetheh.net> wrote:>> Andrew Haley wrote:
>
>>>> It's not a popularity contest between Standard Forth and LSE64: I
>>>> have no delusions that either will ever be popular in its present
>>>> form. But the popularity of the Forth *approach* does matter, in the
>>>> sense that its 21st century unfamiliarity makes it difficult to
>>>> introduce into new projects. I wish that *some* Forth dialect would
>>>> become popular, but I see none that has much of a prospect right
>>>> now.
>>> You don't get to have it both ways: either it's a popularity contest
>>> or it isn't.
>
>> Oh, quit your sophistry. I said popularity matters, I never said it
>> was a contest.
>
> You denied my comparison of the popularity of LSE64 and Forth because
> "it's not a popularity contest." If popularity comparisons between
> Forth and LSE64 are irrelevant, so are such comparisons between Forth
> and anything else.
Non sequitur.
>
>> Is there a popularity contest between C and Python? Not as far as
>> I'm concerned: both are familiar enough in the wide technical world
>> to be usable in projects on their merits. They're both in the
>> toolkit. But Forth isn't in most toolkits any more.
>
>>>>> Forth needs to handle these different data types to be a reasonably
>>>>> complete language for programming a machine. However, you
>>>>> apparently insist that Forth is to handle these types we must add a
>>>>> type system and all that involves; yet, at the same time, you
>>>>> complain about Standard Forth being bloated. I guess this is good
>>>>> bloat not bad bloat ...
>>>> It seems to me that a type system would be less bloat that a
>>>> confusing matrix of typed cells and operators. Certainly less
>>>> perceptual load. Think of it as factoring, although of a kind alien
>>>> to Forth's traditional relentless proceduralism. It allows you to
>>>> separate data representation from algorithm (or not, as needed).
>>> I don't think it would be less bloated. Handling a type system in a
>>> language like Forth would be really complicated.
>
>> Not to the user. Think application, not implementation.
>
> No. Both are important. The fact that the implementation is easily
> understood, and simple, is of substantial value and indeed is one of
> Forth's special features.
Only of a particular implementation. In Standard Forth, you're not
supposed to do things in ways that depend on the implementation,
remember? Except it's really doublethink and crimestop: the
implementation shows through in various places, and you have to pay
attention.
> The fact that every user can understand how
> the whole system works gives tremendous power to the user.
If the user is also the author of the system, I agree. But most users
don't want to do that.
> Besides, I
> don't think that strongly typed Forth really would necessarily be
> easier for the user. Some things would be easier, but some things
> wouldn't.
Example?
>
>> The days when the compiler had to sit on a 4k target are over. Self
>> hosting is rarely an advantage anymore. And for the few cases where
>> it is, a nice stripped-down Forth is fine. One size does not fit
>> all.
>
> It's about the space in people's heads, not the space in the computer.
Yes. Now quit thinking like a systems programmer and think like an user.
> Simple systems are better because they're easier to understand and
> more reliable.
"Simple" to a user is about getting the language to reflect the problem
space, not about seeing the language's implementation.
> Forth has never been about black boxes.
Empty ideology. Programming is *always* about black boxes. Even if you
design your own processors, you essentially treat the components as
black boxes. The key thing is to be able to concentrate on the
*relevant* details and ignore the irrelevant ones.
> If you're
> looking for a black box language, it might be a good idea to look
> somewhere else.
I'm looking for a user friendly interactive language on a concrete
foundation.
>
>>> It's possible to generate an arbitrary number of words of different
>>> types on the stack at runtime, so it would be very hard
>>> (impossible?) to do type inference statically without greatly
>>> restricting the language.
>
>> Apparently not: StrongForth is proof of principle here.
>
> I don't think so. I doubt very much that StrongForth can do it
> either, because I don't think it's possible. As a rather contrived
> example, what is the type of
>
> random 1 and if 2 else 2.0e0 then
>
> ?
I think that's a fine example of insane, useless code. Laying a
requirement on the language to support such things is ridiculous.
>
> You'd have to massively restrict the subset of allowable Forth
> programs to make static typing work.
Massively of utterances subset restrict real languages. With helps
communication.
> You'd have to disallow many
> perfectly reasonable Forth programs if the type inference engine
> couldn't figure out the types.
I think such restrictions would make Forth much more readable to
ordinary users. That's a huge issue.
>
>>> Also, it would be very un-Forth in that it would be doing a lot
>>> "under the table": operators like + would do different things
>>> depending on context. This is a big conceptual shift for Forth,
>>> and (IMO) it loses one of Forth's great advantages.
>
>> While I am not a fan of operator overloading willy-nilly (as in bad
>> C++ code), it seems unreasonable to have to keep track of data
>> encoding details in an algorithm, especially if the code is intended
>> to be portable/reusable. In any case, the world has gone to types
>> and overloading: anything else is user-hostile these days.
>
>> It also depends on what you mean by "different".
>
> Different depending on type.
You didn't answer the question. 1 1 + behaves the same way regardless of
the type "1" has, no?
>
>> What "+" does in any computer language is different from what it
>> does in the real number system. In most Forth dialects, the details
>> of what "+" does depends on the hardware, so it already does
>> "different things depending on context". On the other hand, 1 1 + 2
>> = is generally true regardless of data encoding.
>
>> If you were really concerned about the language doing "different
>> things depending on context", you'd be as adamantly opposed to the
>> text interpreter as I am.
>
> No, I wouldn't be. The text interpreter is a program, as is the
> compiler.
You're thinking implementation again, not language. Is Forth truly a
language, or is it just a programmable code generator?
> Each program processes a text and does something as a
> result. These results are different because the programs do different
> things. I don't see what's wrong with that, as I've said before.
I think a text written partly in Haitian Creole and partly in Parisian
French would be extremely hard to read, even for someone fluent in both.
Highly correlated vocabulary but different grammar.
>
> However, I am opposed to the interpreter doing different things
> depending on STATE. This is a hangover from early Forths which the
> standard didn't obsolete.
>
>> The text interpreter creates a very user-unfriendly set of
>> differences depending on context. Overloading isn't nearly as bad:
>> decades of experience with other languages show that ordinary
>> overloading of arithmetic operators is well understood by users as
>> long as it's done fairly conservatively.
>
> Sure, but it's a very different approach to that of Forth, where the
> type is attached to the operation, not the data.
Are you denying that StrongForth is Forth?
> You are describing
> something like a reverse polish ALGOL, which might have its merits,
> but it's a very different kind of animal.
The merits are what matter. Arbitrary classification does not.
>
> I suspect that such a language wouldn't satisfy anyone. Those who
> like strongly typed ALGOLs wouldn't use it because it's reverse
> polish, and those who like Forth wouldn't like it because it's strongly
> typed. I suspect the overlap, people who did like it, would be very
> small.
OK, what would you do to create a user friendly interactive language on
a concrete foundation, understanding that the users who could benefit
here have almost completely abandoned Forth as it currently exists?
>
>>>> The last I looked, gforth's documented vocabulary exceeded 1000 words.
>>>> That's just plain too much for most people who have problems to focus on.
>>> No argument there either; gforth is an example of a "maxi" Forth
>>> system. There have always been small and large Forths. Extremely
>>> small Forths can't be standard, because even just the core has too
>>> many words for them. There's nothing wrong with them because of that.
>
>> The trouble is, the standard encourages this bloat by having the
>> vocabulary. Other languages get their power from libraries, which
>> reduces the perceptual overload on the user and encourages library
>> development.
>
> What's the perceptual difference between a vocabulary (a set of words)
> and a library? I don't get it.
The difference is that the library isn't part of the language. It often
doesn't even come with the language: you get it elsewhere. If you omit
loading it, you don't get it. The reference docs don't include library
functions. So the user gets a clear idea of what's fundamental and
what's added on.
>
>>> People don't discuss the things you'd like to see discussed in the
>>> way you'd like to see, so they must be brainwashed; after all, if
>>> they had not been brainwashed they would be discussing the things
>>> you'd like to see discussed. Obviously.
>
>> No, they appear brainwashed because they trot out the same tired old
>> falsehoods in denial of the sorry situation.
>
> That's just a restatement of the same thing: they disagree with you,
> so what they are saying must be falsehoods and in denial.
"C's popularity is due to powerful institutional backing". Simply wrong:
in the 70's the institutions were behind PL/I, in the 80's, Ada. C got
in through the back door because users found it useful and
comprehensible. Forth got in that way too, but later users found it too
unproductive and threw it back out into the cold.
>
>>> In any case, I don't think that's true. We have spent ages here
>>> discussing nonstandard language ideas. There's nothing wrong with
>>> that.
>
>> It would really help if you would consistently use "Standard Forth" to
>> refer to that specifically, and "Forth" to refer to the wider Forth
>> world.
>
> I admit that I have been a bit inconsistent about this, but I'm not
> going to extend "Forth" in my postings to languages not called Forth.
> I'll include all the ancestors of Standard Forth, polyFORTH,
> fig-FORTH, but not STOIC, PostScript, etc, because they are too
> different in implementation and in language.
ColorForth? StrongForth? And what did old Will say about the rose?
> Not every reverse polish
> language is Forth.
I know of no Forth dialect that's really reverse polish. A real reverse
polish dialect would probably be more readable.
>
>> Part of Forth's problem is the misidentification of the badly flawed
>> standard with the valuable Forth technique.
>
>>> There is no doubt that, if there were no attempt at backwards
>>> compatibility, Standard Forth would be a cleaner and better language;
>>> I don't think anyone would dispute that. It's probably true of every
>>> programming language standard. For example, ISO C has implicit int
>>> and non-prototype function declarations. Everyone has old baggage.
>
>> Yes, but C has a good reason: there are billions of lines of
>> published code, widely used.
>
> I rather suspect that people have plenty of lines of Forth, too.
Not published.
> People like Elizabeth and Steve Pelc have told you so, lots of times,
> but rather than accept their answers you just assumed they were lying
> to you.
No, I don't assume they're lying. It doesn't matter whether they are
lying or not. What matters is that this code base is unpublished.
> Whether this code is published or not is a complete red
> herring.
No, it's a central issue. Consider my interest in Python: I don't like
Python as a language at all. But it gets my attention because it
attracts users who publish useful code. And in a useful sense, simple
things stay simple, too (although it's not as concrete as Forth). That's
real application leverage. And clearly, that's what gets other people's
attention too:
http://xkcd.com/353/
;-)
