Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33910
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: uninitialized and implicitly initialized locals |
| Date | 2014-10-15 12:44 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2014Oct15.144442@mips.complang.tuwien.ac.at> (permalink) |
| References | (6 earlier) <FL2dncik_pHsMKvJnZ2dnUU7-RmdnZ2d@supernews.com> <2014Oct10.180311@mips.complang.tuwien.ac.at> <R5ydnXUuLoNtu6XJnZ2dnUU7-X2dnZ2d@supernews.com> <2014Oct11.125348@mips.complang.tuwien.ac.at> <2_CdnedZqtY0MKfJnZ2dnUU7-VOdnZ2d@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:
>>>>>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>>>>>> On the other hand, if someone really wants to create an
>>>>>>>>>>>uninitialized local I can't see much harm in it.
>>>>>>>>>>
>>>>>>>>>> The benefit of defining a local where it is properly initialized is
>>>>>>>>>> that every read from the local produces a proper value. You cannot
>>>>>>>>>> read the uninitialized value.
>>>>>>>>>
>>>>>>>>>I'm not going to argue with that advantage, but it's hard to do that
>>>>>>>>>if you're only allowed to define locals in one place.
>>>>>>>>
>>>>>>>> Lifting that restriction is not that hard.
>>>>>>>
>>>>>>>Ummm. I don't think that you can really say so for all
>>>>>>>implementations.
>>>>>>
>>>>>> Sure I can: For all implementations lifting that restriction is not
>>>>>> that hard.
>>>>>>
>>>>>> To support that claim, I have outlined how to do it in
>>>>>> <2014Oct7.173637@mips.complang.tuwien.ac.at> and
>>>>>> <2014Oct8.180623@mips.complang.tuwien.ac.at>.
>>>>>
>>>>>Hmmm. I suppose "not that hard" is in the eye of the beholder.
>>>>>Locals are not such a big deal that it's worth so much effort.
>>>>
>>>> How much effort is it? With such a statement, you surely have a
>>>> number for that.
>>>
>>>How many "not that hard"s are there in a "big deal effort", I wonder.
>>
>> Please answer the question.
>
>What for?
So that others can come to their own judgement of whether it is worth
the effort. E.g., if you think it takes changes in ten lines, but
that it's not worth that effort, your statement is more about what you
think the value of the change is, whereas if you think it takes
changes in 10000 lines, it's more a statement about what you think the
effort is.
>> Ah, ok. It's not that it is "so much effort", it's that it is any
>> effort at all, i.e., this is just a restatement of your dislike of
>> locals.
>
>Not exactly, no. It's not dislike per se: as I've said before, locals
>seem to me to be associated with unfactored code, and the more they
>are used the worse that is. Therefore, any syntax which postively
>encouarages an "all or nothing" approach to locals will, in the main,
>make code worse.
How does allowing defining locals in multiple places encourage an
all-or-nothing approach? Requiring that all locals are defined in one
definition seems to be much more all-or-nothing to me.
>> Well, to anyone skilled in the art code redundancy in is bad.
>
>I absolutely agree, but it's the lesser of two evils. IMO.
Anyone agreeing with you has the option of not using the "--" part in
such cases.
>>>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?
>
>This should surely be obvious. People are being encouraged to put
>items in locals, even when there is no need to do so.
Why is that "very bad"?
>>>> Yes, in this example one can do without the inner locals relatively
>>>> easily, because there are only two cells permanently alive in the
>>>> loop. No need for any factoring:
>>>
>>>Well-factored words are the goal, not something to be avoided!
>>
>> Sure, but your version is not *well*-factored code.
>
>Perhaps not, but you are rather avoiding the point. You are saying
>"there is no need for factoring", and though factoring is a scarce
>resource that might be used up, or something to avoid. I don't know
>why you are talking like that.
If the factoring is so bad that the code without factoring is better
than the code with factoring (as in this case), then yes, this
factoring is something to avoid.
But actually, this was not a comment about the desirability of
factoring in general, but about the properties of the specific word at
hand.
>> 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. If anyone
had solved these examples and I would have come up with additional
ones, then your complaint would have a real basis. But as it is,
these examples have been around for a decade, and there has been very
little effort gone into factoring them, while claims about factoring
making locals unnecessary have been repeated pretty often during that
time.
Anyway, these are the most extreme examples I have from real-world
code, so I am unlikely to come up with new examples.
>If I were to look at
>something monstrous like F>BUF-RDP-TRY it'd take me half a day just to
>figure out how it works.
Yes, it's an ugly and complex word. Somehow starting with simple
words would not be challenging, and prove nothing, would it?
>Why are the exponential and fixed-point notations not factored out of
>F>BUF-RDP-TRY , anyway?
I can only guess now, 12 years later: Maybe the two factors would have
had too many parameters and would not stand for an identifyable
concept (already F>BUF-RDP-TRY has that problem).
>>>MAP-ARRAY is an example of something that could easily and more
>>>efficiently and more idiomatically be done with a compiling word, like
>>>so:
>>>
>>>: ` postpone postpone ; immediate
>>>: map-array ( xt) >r
>>> :
>>> ` cells ` over ` + ` swap ` do
>>> ` i ` @ r> compile,
>>> ` cell ` +loop ` ; ;
>>
>> Used like
>>
>> : foo ... [ ' + ] map-array ... ;
>>
>> instead of
>>
>> : foo ... ['] + map-array ... ;
>
>Eh? No. Used like
>
>' + map-array +array
>
>then
>
>: foo ... +array ... ;
Ok. Is cumbersome for one-shot uses of map-array, but allows reusing
the code in other cases; but actually it's even cumbersome if the
defined word is used in several places.
>> What I find interesting in the original MAP-ARRAY, though, is that,
>> for such a simple word, the restrictions on combining the return stack
>> and DO loops make it really cumbersome to write such a word without
>> locals.
>
>That is true, and is a real disadvantage. Forths I have used have
>allowed access to the third item on the return stack, but even if not
>it's possible to add a primitive to do so.
In Gforth you could use J for that. But preferring to use such
system-specific and not easily comprehensible code elevates the
avoidance of locals to an end in and of itself.
I remember the horribly unfactored code that Wil Baden posted for
compression or encryption or such, all without locals. Maybe he did
it to show that locals-freedom does not guarantee good factoring, but
he actually seemed pretty serious to me.
>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.
2) Xt-passing has turned out to be a useful factoring technique.
E.g., consider SAVE-INPUT RESTORE-INPUT with all the many ways that
RESTORE-INPUT can fail, compared to properly nesting words like
EVALUATE. Now EVALUATE always INTERPRETs the string, so for doing
something else we have EXECUTE-PARSING ( ... xt -- ... ). And that
principle has been applied to other problems.
- 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