Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33943
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: uninitialized and implicitly initialized locals |
| Date | 2014-10-16 12:19 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2014Oct16.141939@mips.complang.tuwien.ac.at> (permalink) |
| References | (5 earlier) <R5ydnXUuLoNtu6XJnZ2dnUU7-X2dnZ2d@supernews.com> <2014Oct11.125348@mips.complang.tuwien.ac.at> <2_CdnedZqtY0MKfJnZ2dnUU7-VOdnZ2d@supernews.com> <2014Oct15.144442@mips.complang.tuwien.ac.at> <3dSdnTQ6X5oRAaPJnZ2dnUU7-XOdnZ2d@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:
[...]
>Ten lines more is too much, especially if it leads to
>something like
>
> IF {: a b :} else a . THEN
>
>compiling. i.e. it's ten more lines and it's still not really right.
It's a very way to deal with the problem. It allows to compile
correct programs, and also allows you to shoot yourself in the foot.
Compared to the "one definition with uninitialized locals" approach it
does not miss anything; E.g., if I transcribe the example above for
this approach, I get:
{: | a b :} IF TO b TO a ELSE a . THEN
and that would also be accepted by the compiler, and the code would be
longer, and the programmer needs to reverse the local names for the
TOs.
If you reverse the branches of the IF structure above, then the
define-on-initialization approach would not compile, while the
define-uninitialized approach still would. But the error checking is
not the reason to go for such an implementation; the reason to go for
such an implementation is so that you can run programs written in that
style, and to allow easier reading and writing of programs: No
redundancy of having to mention the locals both in the definition and
in the initialization, and no reversal of the initialization.
If you want to error-check the program, you can do a more elaborate
implementation, or you can just compile the program on a Forth system
with such an implementation, like Gforth (where the scoping takes 65
SLOC, plus maybe some prerequisistes).
BTW, "changes in ten lines" does not mean "ten more lines".
>But any
>further locals syntax is just more locals syntax, IMO. We've got too
>much of it already and the Basic Principle of Forth is "Keep it
>simple!":
>
>"As the number of capabilities you add to a program increases, the
>complexity of the program increases exponentially. The problem of
>maintaining compatibility among these capabilities, to say nothing of
>some sort of internal consistency in the program, can easily get out
>of hand. You can avoid this if you apply the Basic Principle. You may
>be acquainted with an operating system that ignored the Basic
>Principle.
>
>"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]
>
>The most important consequence of this princple is that the burden of
>evidence is *on the person proposing an addition* to Forth to show
>that there is a great advantage. But not every Forth user agrees with
>the Basic Principle.
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. In my view the real opposing forces are implementation and
maintenance cost, so I don't need to invent a Basic Principle to
strive for simplicity. I then have to balance functionality, ease of
use etc. against complexity (and its consequents implementation and
maintenance cost).
In the present case, an implementation with define-on-initialization
is easier to use and (without scoping) has comparable (probably even
less) complexity than an implementation with define-uninitialized
locals.
>What I'm afraid of, of course, is more badly-factored Forth
>code using more locals. And, horrors, people coming to Forth and
>thinking that's what it's supposed to look like.
Looking at what my students produce, some of them produce badly
factored code without locals, and some of them produce nicely factored
code with locals. I have not done a statistical evaluation, but from
what I saw, there does not seem to be a correlation between use of
locals and bad factoring; I guess that I did not see it because the
cases where the factoring is so hard that you give up if you have the
easy way out (locals) are relatively rare, whereas those people who
factor badly factor all their code badly.
>>>>>A locals declaration is not a
>>>>>stack comment, and in this form it encourages people to put all args
>>>>>in locals, even those which need no local. This is very bad.
[...]
>> Why is that "very bad"?
>
>Because it's unnecessary. Do I have to explain why moving a stack
>item into a local and back onto the stack, where that is only needed
>because of the locals-as-stack-comment syntax, is a bad thing?
Yes.
>Why
>adding more work into a definition is a bad thing?
More work for whom?
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.
>> But actually, this was not a comment about the desirability of
>> factoring in general, but about the properties of the specific word at
>> hand.
>
>Right. Which is what I am trying to get away from; arguing about a
>specific word is pointless.
Not at all. Specific examples are useful to illustrate points. In
this case you pointed out that that word could be factored, and I
pointed out that the data flow in this example is not convoluted
enough to really need locals in the loop, and, I think, not anywhere;
which means that it is probably not a good example of locals use.
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.
>But, IMO, any word which is much longer than than the magical "seven,
>plus or minus two" words may well be in need of some attention.
You would unfactor a three-word definition?
As for longer definitions, your strcmp factoring example demonstrates
the folly of such a pure numbers-based factoring approach: The
resulting factors make no sense on their own, and you introduce an
additional IF structure that makes understanding the whole more
difficult.
>>>> The others do, although I mentioned them here to show that the claims
>>>> of the people who write "factoring makes locals unnecessary" are just
>>>> hot air.
>>>
>>>But we all know how this game works: more and more extreme examples
>>>until people give up from boredom or exhaustion.
>>
>> You should not attribute your discussion style to others.
>
>I think you're being unfair: I can't remember ever trying to score
>points by challenging people to solve problems and then declaring
>those people to be full of "hot air" when they failed to do so. (But
>perhaps I have forgotten doing so; I've been here a long time, and my
>behaviour has not always been what I aspire to.)
The tactic you described earlier ("more and more extreme examples")
was one of moving the goalposts. That's not quite what you did;
instead, you made the goalposts sufficiently undefined that for any
shot at them, you could then claim that the goal was not there.
What you described here is reacting to a claim by challenging the
claimer to demonstrate the claim on an example. I don't see anything
unfair about that in general (although some may use it in unfair
ways).
>>>That is true. Passing XTs is, in general, something I would avoid
>>>unless the XT really varies at runtime. So, I prefer
>>>
>>> 0 foo n <map-array + map-array>
>>>
>>>to
>>>
>>> 0 foo n ['] + map-array
>>
>> Yes, in this case this works nicely, but
>>
>> 1) It cannot be used interpretively, which is not so nice.
>
>Shrug. I think that other people worry about that much more than I
>do. Throwaway definitions cost nothing.
They cost at least a bit of code. In some usage patterns, that is
significant for me. And I guess, for others, too, or we would not
have such a capable interpretation mode as we have (with all the
headaches about interpretation semantics or state-smartness, etc.).
If words such as <map-array ... map-array> were more frequent, maybe
we should have a way to put the rest of the line in a colon definition
and execute it and forget it right away, like some non-standard Forth
systems have. Say:
% 0 a 5 <map-array + map-array> .
- 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