Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #34010
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: uninitialized and implicitly initialized locals |
| Date | 2014-10-18 12:55 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2014Oct18.145533@mips.complang.tuwien.ac.at> (permalink) |
| References | (5 earlier) <2_CdnedZqtY0MKfJnZ2dnUU7-VOdnZ2d@supernews.com> <2014Oct15.144442@mips.complang.tuwien.ac.at> <3dSdnTQ6X5oRAaPJnZ2dnUU7-XOdnZ2d@supernews.com> <2014Oct16.141939@mips.complang.tuwien.ac.at> <GNKdnUPWhZo1RN3JnZ2dnUU7-eOdnZ2d@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:
>>>>>>>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.
>
>Yes, it is. I take yoir point, but from a language point of view it
>is so strange that it is not fit for standardization, IMO. IMO, if
>we're going to have a feature like this it has to be right.
In the simple form it's not any wronger than now-standard
uninitialized locals, and, unlike uninitialized locals, it allows
programs written on right systems to work.
Anyway, for now I would be happy if more systems implemented multiple
locals definitions, whether in the simple or in the right form.
>>>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.
How is that possible?
Actually, if I really give simplicity priority over everything else, I
don't arrive at ColorForth, I arrive at the empty program. So even
Chuck Moore allows features to come in the way of his Basic Principle.
Is it really a principle, then?
>> 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).
>
>That's what everyone says, even of C and Java.
Well, obviously that does not lead to one solution, either. There are
people who went more for simplicity in C (e.g., Ken Thompson), and
others who did so less (e.g., Richard Stallman, although he is
actually a Lisper). I think that there are several factors involved:
1) Capability: Not everyone is as capable as Charles Moore, Ken
Thompson, or Jochen Liedtke at finding simple solutions.
2) Capacity: If you can afford to spend more effort, you may decide
that the feature is worth the effort (up to your budget). The
problem, of course, is, that it is hard to predict the effort.
3) You may consider certain features more important, and others less,
than other people do, producing different results.
>>>>>>>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?
>
>More work in the definition. More back-and-forth noise words. More
>locals.
>
>> 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.
What are "back-and-forth noise words"? And what do you mean with
"work in the definition"?
>>>> 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.
>
>That is perhaps true; I chose it only because I needed an example of
>locals, and I rather hoped that it would be suitable. The problem
>with arguing about a specific word is that we very quickly get bogged
>down in irrelevancies.
Sure, that can happen. If one party notices that and both are
interested in a productive discussion, that part of the discussion
will stop, and the discussion will continue with more productive
parts.
>> 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.
>IMO, almost any example of locals use which is long enough really to
>need locals will be so complex that it is in dire need of refactoring,
>so the need for locals will be reduced in many cases. (There are
>counter-examples, as I said earlier.)
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.
BTW, I agree that F>BUF-RDP-TRY may be quite a lot of work to
understand before you can do anything. The solution is probably to
replace REPRESENT with a more capable way (or several) to convert
floating-point numbers into strings, and then we can probably do a
nicely factored F.RDP.
The other challenge program <a3j4aa$a23$1@news.tuwien.ac.at> is
probably easier to understand.
>> 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.
>
>I don't believe that the IF really makes the whole more difficult to
>understand.
It does. Maybe "understand" is the wrong word. I originally wrote
"analyze", but that seemed to technical for what I had in mind.
Anyway, the additional IF requires to think about two paths for, e.g.,
checking the stack depth, and whether the stack depth along these
paths matches. For me that makes things significantly harder.
>-STR compares two strings of the same length and returns
>the first difference: it is C's memcmp(), more or less. The only
>reason for factoring is not necessarily that a word is useful on its
>own: it is often useful to separate out factors, for testing and
>clarity, even when you are certain they will not make sense on their
>own.
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. And do I really want to invent test cases for
words that have no identifiable purpose?
>>>>>> 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.
>
>Of course I might adjust my opinion when other opinions are presented
>to me. That's how it's supposed to work.
Ok, if you adjusted your opinion, you gave no indication of it.
Instead you wrote that I had misrepresented your claim.
>I try not to over-state my claims, especially about style. That
>necessarily means that they are hedged with "if"s and "but"s
Not that I noticed. Maybe these "if"s and "but"s are present in your
mind, but you don't write them out, resulting in claims that cry out
to be refuted. Afterwards you claim that the claim was
misrepresented.
>My claim about "more and more extreme examples" examples stands, and I
>have evidence: the example you provided was mind-bogglingly complex,
>and simply to declare victory because you'd written the Gordian Knot
>of Forth words is rather childish. You have merely succeded in
>writing a word which is so complex that nobody can refactor it because
>nobody can understand it.
I understood it when I wrote it. I am pretty sure I will understand
it again when I look at it for some time. And this is production
code, not something written to be ununderstandable.
Anyway, given that this example was included in the first challenge of
this kind I put up, it is not at all evidence for your claim, which
was about harder claims coming after you had solved the first ones.
>> 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).
>
>"Unfair" isn't the point, because anyone can use that tactic, so in
>that sense it is fair. The question is whether it is a useful thing
>to do, and whether any of this heat can be turned into light.
I think it is, already. The fact that you prefer to write lots of
prose to justify not attacking the two harder examples, as well as
nobody else attacking them in over ten years shows that removing the
locals by factoring is not easy. So it's not just a failure on my
part. It also reduces the faith in the veracity of the claims that
locals can always be eliminated by better factoring.
- 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