Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #34030
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: uninitialized and implicitly initialized locals |
| Date | 2014-10-20 12:48 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2014Oct20.144848@mips.complang.tuwien.ac.at> (permalink) |
| References | (5 earlier) <3dSdnTQ6X5oRAaPJnZ2dnUU7-XOdnZ2d@supernews.com> <2014Oct16.141939@mips.complang.tuwien.ac.at> <GNKdnUPWhZo1RN3JnZ2dnUU7-eOdnZ2d@supernews.com> <2014Oct18.145533@mips.complang.tuwien.ac.at> <cNKdnXYe2Y48Mt_JnZ2dnUU7-TudnZ2d@supernews.com> |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>>>>We've got too much of it already and the Basic Principle of Forth is
>>>>>"Keep it simple!":
>> ...
>>>>>"It is very hard to apply. All the pressures, internal and external,
>>>>>conspire to add features to your program. After all, it only takes a
>>>>>half-dozen instructions, so why not? The only opposing pressure is the
>>>>>Basic Principle, and if you ignore it, there is no opposing pressure."
>>>>>[1]
>> ...
>>>> Sure, if you follow it, you arrive at colorForth, I guess. I don't
>>>> arrive at colorForth in my Forth work, so I obviously don't agree with
>>>> it.
>>>
>>>No, that does not follow. The Basic Principle also led to miniForth,
>>>polyFORTH, and (indirectly) fig-FORTH and all its derivatives. It
>>>does not only lead to one solution.
I doubt that Chuck Moore sees all of these systems as equally good and
valid solutions. It's a progression: First he did Forth, the
mini-Forth, then microForth, then cmForth, then machineForth, and now
colorForth. At every step he gave preference to his new design over
his old design, and he never returned to miniForth or PolyForth. He
did abandon the approach of leaving the Forth compiler/text
interpreter away completely (OKAD).
> There are, as Chuck says, pressures, and it's mater
>of striking the balance. As I understand what Chuck says, it is a way
>of opposing the trend to ever-increasing complexity which plagues the
>entire field. The difference with Forth is that the balance between
>simplicity and features is at a different point: simplicity is
>weighted much more heavily. And yes, that's a judgement call.
Yes, Charles Moore certainly did that, although, as the comment of
Elizabeth Rather shows, simplicity is in the eye of the beholder.
Another interesting thing in this respect is Richard Gabriel's
characterization of the Unix (Ken Thompson) philosophy
<http://en.wikipedia.org/wiki/Worse_is_better>, which Gabriel says
always values implementation simplicity above all else. One might
think that this would lead to similar results as the Forth (Chuck
Moore) philosophy, and indeed, early Unix is remarkably similar to
early Forth, but one difference in philosophy is that the Unix people
favour reusablility, whereas Chuck Moore pretty much rejects it. And
there are other differences.
>> 1) Capability: Not everyone is as capable as Charles Moore, Ken
>> Thompson, or Jochen Liedtke at finding simple solutions.
>
>True, but between us we might be able to get somewhere close, but IMO
>we surely won't if we ignore the principle.
Ok, but my point was not to ignore simplicity. Instead, I
contradicted the claim that you need an axiomatic Basic Principle to
keep things simple, because there is supposedly no other force acting
against complexity.
>In once place I worked we use to call some features "WIBNIs", where a
>WIBNI was short for "Wouldn't It Be Nice If..." WIBNIs should be
>avoided like the plague; features should be added if they're *needed*.
>And multiple locals declarations, even if occasionally nice to have,
>are not necessary.
N>R and NR> are not necessary, either, and I don't consider them nice
to have. Your reaction: "what's not to like?".
Sure, you can rewrite programs with multiple locals definitions in the
VFX style, and they become longer and harder to read and understand.
And of course shorter and easer to read and understand programs are
just nice to have and not really necessary, like most other things,
but I think that that multiple locals definition still lead to an
overall improvement.
>>>> A simple example is:
>>>>
>>>> : bla {: a b c d -- :}
>>>> d . a . b . c . ;
>>>>
>>>> Now one could write instead:
>>>>
>>>> : bla ( a b c d -- )
>>>> . {: a b c :} a . b . c . ;
>>>>
>>>> Is this an improvement? The source code certainly is longer and has
>>>> more tokens.
>>>
>>>They're both pretty unpleasant. You're asking me whether I prefer a
>>>pile of muck or a bucket of sick, and I think I'll decline. But in
>>>general the second case is marginally better because it uses fewer
>>>locals, IMO.
>>
>> But it's more work for the programmer. More characters. More tokens.
>> And therefore harder to understand.
>
>We must agree to differ.
Do you claim that it's not more characters and not more tokens?
>> What are "back-and-forth noise words"? And what do you mean with
>> "work in the definition"?
>
>"Back-and-forth noise" is just the normal use of English: you put a
>stack item into a local only immediately to remove it. That's what I
>mean by "work", even if a very clever compiler can detect that you
>didn't really mean to move the item and leaves it where it was.
So you mean something like static or dynamic executable code size from
a simple Forth compiler?
Why not write that clearly? Or if you mean something else, what do
you mean?
>>>> Of course, in the past you have often made claims in the abstract,
>>>> and any refutation of such a claim was answered by saying that I had
>>>> misrepresented your claim (of course without making your claims any
>>>> more concrete, just to keep them unrefutable). That's what I
>>>> consider pointless.
>>>
>>>I take your point. So what then shall we do? If we have specific
>>>examples we'll end up nitpicking them to death and not arriving at any
>>>conclusion.
>>
>> I think the chance of arriving at a conclusion in a discussion between
>> us is much higher when working with concrete examples than when
>> working with abstract generalities.
>
>But we'll only end up with a conclusion about those examples.
Sure, there are people who will see every counterexample to their
beliefs only as exceptions that prove the rule, but discussing with
such people is not going to be very productive anyway (and even less
if one discusses only about generalities with them), so that's not the
kind of people that we should be concerned with in considering how we
should discuss.
>> Yes, that's a claim I have read again and again, and I posted a
>> challenge to give the claimers a chance to prove it.
>
>It wouldn't prove anything though, would it?
Sure it would provide evidence supporting the claim, and a pretty
strong one at that, given that the other side selected the examples.
I did not use "prove" in the mathematical sense here.
BTW, if you don't want to refactor the existing words, the alternative
is to write a new implementation from scratch. The examples include
specifications and test cases.
>> I think "factoring" code into a separate word that does not represent
>> an identifiable concept (your @PAIR and STEP words) reduces, rather
>> than increases clarity.
>
>We really do disagree about that, and it seems to me that a word which
>fetches two bytes from two pointers represents a pretty easily
>identifiable concept
That's certainly not *one* concept, but even if it were, from your
description I would expect such a word to have the stack effect
( addr1 addr2 -- c1 c2 ), whereas your @pair has ( a1 a2 - a1 a2 c1 c2).
>as does a word which bumps two pointers.
Not one concept, either.
>> And do I really want to invent test cases for words that have no
>> identifiable purpose?
>
>I'm trying to get my head around what this implies. Are you really
>saying that if you factor a word you have to test the factors, so that
>is a pressure against factoring?
No. You claimed: "it is often useful to separate out factors, for
testing and clarity". If I don't test them, it's not useful to factor
them out for testing. And factoring out words that don't represent an
identifiable concept reduces, rather than increases clarity. So here
we have have a case where none the reasons you gave for factoring
apply (at least not for this factoring), and indeed there is a reason
not to.
- 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 2014: http://www.euroforth.org/ef14/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Why smudge? hughaguilar96@yahoo.com - 2014-09-30 19:25 -0700
Re: Why smudge? november.nihal@gmail.com - 2014-10-01 08:54 -0700
Re: Why smudge? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-01 19:09 +0000
Re: Why smudge? november.nihal@gmail.com - 2014-10-01 10:16 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-01 18:54 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 15:31 -0700
Re: Why smudge? Michael Barry <barrym95838@yahoo.com> - 2014-10-02 16:35 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 17:02 -0700
Re: Why smudge? Michael Barry <barrym95838@yahoo.com> - 2014-10-02 17:51 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 18:50 -0700
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-04 00:30 +0100
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-03 17:40 -0700
Re: Why smudge? Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-10-03 23:00 -0700
Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-04 21:14 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:42 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Enoch <emc.consultants@gmail.com> - 2014-10-05 10:43 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-05 20:21 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-06 03:58 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-05 17:09 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Michael Barry <barrym95838@yahoo.com> - 2014-10-06 11:15 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-06 18:52 -0700
More ranting Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-07 03:48 -0500
Re: More ranting albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-07 12:43 +0000
Re: More ranting Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:23 +0200
Re: More ranting "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-16 01:03 -0400
Re: More ranting Just Ian <superian@gmail.com> - 2014-10-16 07:14 -0700
Re: More ranting Michael Barry <barrym95838@yahoo.com> - 2014-10-16 13:23 -0700
uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 15:36 +0000
Re: uninitialized and implicitly initialized locals (was: More ranting) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 22:15 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) mhx@iae.nl - 2014-10-07 15:07 -0700
Re: uninitialized and implicitly initialized locals (was: More ranting) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:11 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 13:25 +0000
Re: uninitialized and implicitly initialized locals (was: More ranting) hughaguilar96@yahoo.com - 2014-10-09 16:22 -0700
Re: uninitialized and implicitly initialized locals (was: More ranting) "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 21:58 -0400
Re: uninitialized and implicitly initialized locals (was: More ranting) mhx@iae.nl (Marcel Hendrix) - 2014-10-12 11:18 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 12:35 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-07 15:27 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 12:56 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 08:24 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 15:32 +0000
Simplified automatic scoping (was: uninitialized ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 16:06 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 11:57 -0500
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 12:18 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 14:19 +0000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-09 14:42 -0700
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 14:07 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-09 10:44 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-10 16:03 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-10 13:35 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 10:53 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 11:34 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-15 12:44 +0000
Re: uninitialized and implicitly initialized locals albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-15 14:34 +0000
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-15 15:03 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-15 11:10 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-16 12:19 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-17 03:56 -0500
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-17 07:48 -1000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-17 19:26 -0700
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-18 12:55 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-18 13:21 -0500
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-18 08:44 -1000
Re: uninitialized and implicitly initialized locals albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-19 09:53 +0000
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-20 12:48 +0000
Re: uninitialized and implicitly initialized locals "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-20 16:24 -0400
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-20 10:30 -1000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-20 16:23 -0700
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 04:16 -0500
Re: uninitialized and implicitly initialized locals mhx@iae.nl (Marcel Hendrix) - 2014-10-26 11:32 +0200
Re: uninitialized and implicitly initialized locals stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-26 14:27 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 13:56 -0500
Re: uninitialized and implicitly initialized locals mhx@iae.nl (Marcel Hendrix) - 2014-10-26 20:32 +0200
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 16:18 -0500
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-26 15:05 -0700
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 17:53 -0500
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-26 16:30 -0700
Re: uninitialized and implicitly initialized locals "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-27 01:45 -0400
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-27 12:21 -0500
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 17:57 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-06 20:55 +0100
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-06 16:05 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-09 07:36 +0100
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-10 01:52 +0000
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-09 19:56 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:11 -0400
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-05 11:05 +0100
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-05 19:48 -0700
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-06 07:53 +0100
Re: Why smudge? "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 21:29 -1000
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-09 15:16 -0700
Re: Why smudge? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-16 01:03 -0400
csiph-web