Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33600 > unrolled thread
| Started by | hughaguilar96@yahoo.com |
|---|---|
| First post | 2014-09-30 19:25 -0700 |
| Last post | 2014-10-16 01:03 -0400 |
| Articles | 20 on this page of 91 — 16 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-08 16:06 +0000 |
| Subject | Simplified automatic scoping (was: uninitialized ...) |
| Message-ID | <2014Oct8.180623@mips.complang.tuwien.ac.at> |
| In reply to | #33763 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> 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.
I already discussed the code generation side of a simple
implementation of that idea in
<2014Oct7.173637@mips.complang.tuwien.ac.at>. Concerning the
automatic scoping,
<http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz> shows a
somewhat elaborate and quite precise way of how to do this. Here I
present a simpler approach:
The local is visible from the definition of the local until the end of
the colon definition. That lets some locals live longer than
described in the paper above earlier proposal (and one could argue
that the local will then be visible in places where it should not be
visible), but compared to the current situation of defining all the
locals at the start and letting them all be visible during the whole
definition, it is still an improvement.
For standardizing, I would suggest allowing different visibility
variants, from something block-structure-like to the simple approach
above. Yes, a weak standard is not nice, but at least in this case it
is something that shows up in compilation.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-08 11:57 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <N_OdnXwI08V58ajJnZ2dnUVZ8nadnZ2d@supernews.com> |
| In reply to | #33763 |
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. >>> Does someone really *want* to create an uninitialized local, or is it >>> just that the programming language does not support what the >>> programmer really wants, and the uninitialized local is a workaround >>> for that? E.g., in Forth-2012 the uninitialized local is a workaround >>> for disallowing to define locals everywhere in a definition. >> >>So that's OK, then. Well, it's not OK, it's all we have at present. > > And before, all we had in the standard were initialized locals. > >>I'm not going to argue about the programmer convenience of being able >>to declare locals as required, but it's not that easy for the >>implementation and it brings up some tricky issues to do with >>lifetimes. (Which I know you have an answer to in gforth.) >> >>All other things being equal, simple implementations are better than >>complex ones, and locals aren't important enough to justify making >>implementations any more complex than they are at present. IMO, YMMV. > > Well, uninitialized locals make Gforth more complex than it is at > present, and they provide exactly zero benefit. Where was your > defense of simple implementations when the addition of uninitialized > locals was being discussed? Firstly, I was not aware that there was any problem with implementing uninitialized locals. As for the rest, Lord knows I tried -- and you were there -- but IMO the whole syntax is a disaster. IIRC I argued very strongly against it one year, but when it came back a year later I gave up because I was told that it was successfully used in many Forth projects, and I didn't think I had the support of the committee. It is wrong in many ways, of which uninitialized locals are a fairly minor part. >>> So the harm of uninitialized locals to the programmer is that he may >>> make errors that would be caught (as "undefined word") if the locals >>> were defined later, where they are properly initialized. >> >>Sure, but I do not have to remind you that this is Forth: your bullet, >>gun, and foot. Initialized locals are already provided, and if you >>prefer to initialize locals, add all of them to the initialized locals >>list with whatever constant you prefer as the initial value. The >>problem is already solved. > > No, by defining a local and initializing it to a dummy value before > you know the proper initial value, you will not catch a to-early read > of the local. This problem is not at all solved in Forth-2012. And in what way will an initialized local catch a too-early read of a local? (I'm assuming we're not talking about multiple locals blocks, but the single one that we have.) > Anyway, if you think that the existance of initialized locals solves > the problem, what problem is solved by uninitialized locals? I think it's for compatibility with existing usage, isn't it? Because there is only one locals block in a word, you have to declare them all at the top, and you don't have initial values for them yet. >>> The harm to the language is that it allows restrictions such as >>> "only one locals definition in a colon definition" and "no locals >>> definition inside control structures" to persist. >> >>Yes. But OTOH, I'm not in favour of asking Forth implementations to >>do extra work to support that. > > But you were in favour of asking Forth implementations to do extra > work to support uninitialized locals? Why? No, absolutely not. Because I was beyond caring; the proposal could not be saved. It was already so hopelessly baroque that it was not worth the effort. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-08 12:18 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <OY-dnSPHi8lI7KjJnZ2dnUVZ7tWdnZ2d@supernews.com> |
| In reply to | #33766 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> >>>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. I just read your paper, and it looks rather complex to me. If you have vanother stack you need yet another stack pointer (we already have three!) and you have to be able to allocate that stack somehow for every thread. Also, the compiler has to keep track of lifetimes at control flow joins and splits. >>>All other things being equal, simple implementations are better than >>>complex ones, and locals aren't important enough to justify making >>>implementations any more complex than they are at present. IMO, YMMV. >> >> Well, uninitialized locals make Gforth more complex than it is at >> present, and they provide exactly zero benefit. Where was your >> defense of simple implementations when the addition of uninitialized >> locals was being discussed? > > Firstly, I was not aware that there was any problem with implementing > uninitialized locals. And having read your paper, I'm still not aware that there is any problem implementing uninitialized locals. In your notation, the runtime action is 0DEADBEEF >L (or DUP >L, to taste) for each local, which is more complex than just >L , but not very much more so. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-09 14:19 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct9.161959@mips.complang.tuwien.ac.at> |
| In reply to | #33768 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>
>>>>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.
>
>I just read your paper, and it looks rather complex to me.
It is. Therefore I have outlined simpler approaches in
<2014Oct8.180623@mips.complang.tuwien.ac.at> (and
<2014Oct7.173637@mips.complang.tuwien.ac.at>).
For anybody who wants to know what's in the paper, it can be found at
<http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz>.
> If you
>have vanother stack you need yet another stack pointer (we already
>have three!) and you have to be able to allocate that stack somehow
>for every thread.
The locals stack is not tied to the automatic scoping at all. You can
have a locals stack without automatic scoping, and you can have
automatic scoping without locals stack. There are two reasons for the
locals stack:
1) Alignment of FP locals. If we kept locals on the return stack, we
would have to FP-align the return stack in a lot of places. On 32-bit
machines this costs padding space on the return stack and, if we want
to minimize padding, extra complexity.
2) Lift the Forth-94 restructions on combining return stack usage and
locals usage without introducing a lot of complexity.
>Also, the compiler has to keep track of lifetimes
>at control flow joins and splits.
In the approach described in the paper, the lifetime is determined by
the visibility, so that comes automatic with the scoping.
In the approach described in
<2014Oct7.173637@mips.complang.tuwien.ac.at>, all locals have space
reserved for them from the first local definition until the end of the
definition, and there is no need to keep track of the lifetimes.
>>> Well, uninitialized locals make Gforth more complex than it is at
>>> present, and they provide exactly zero benefit.
...
>And having read your paper, I'm still not aware that there is any
>problem implementing uninitialized locals. In your notation, the
>runtime action is 0DEADBEEF >L (or DUP >L, to taste) for each local,
>which is more complex than just >L , but not very much more so.
Yes, the code generation of the non-initialization increases the
complexity only slightly once you are there (but it does increase it).
Supporting the additional syntax is more effort. Still nothing
unsurmountable, but given that it provides 0 benefit ...
Looking at code for { (and {:) without and with the "uninitialized
locals" part, that additional complexity is actually significant:
Hayes [hayes92] already mentioned the possibility of uninitialized
locals, but implemented only the part without uninitialized locals and
left uninitialized locals as an "exercise to the reader".
When I created a downloadable form of his work
<http://www.complang.tuwien.ac.at/forth/anslocal.fs>, I considered
implementing the | part as suggested, but did not pull it through.
The result takes 21 lines of code, including >IN manipulation (which
is not present in some of the variants below).
I also did not implement | in Gforth (which uses quite a different
implementation approach); I think the reason is that in both cases the
additional complexity appeared excessive.
Stephen Pelc's "reference implementation" of {: with |
<http://www.forth200x.org/locals-v5.txt> assumes a magic word BUILDLV
whose implementation is not provided, and then still needs 55 lines of
code.
My first attempt at a reference implementation based on (LOCAL)
<http://www.forth200x.org/reference-implementations/extended-locals.fs>
takes 44 lines of code, and would be even longer if we used WORD and
>IN like anslocal.fs (instead, we use PARSE-NAME).
I later forgot about that implementation and made another one, this
time finding a better approach, resulting in 23 lines of code
<http://www.forth200x.org/reference-implementations/locals.fs>. But
as discussed in <2013Oct30.180302@mips.complang.tuwien.ac.at>, this
version would be longer if it used WORD and >IN like anslocal.fs.
Maybe I should write a version of anslocal.fs with PARSE-NAME to show
the real difference.
@Article{hayes92,
author = "John R. Hayes",
title = "User-Defined Local Variable Syntax with {ANS Forth}",
journal = sigforth,
year = "1992",
volume = "4",
number = "2",
OPTpages = "19, 20, 26",
annote = "Shows how to define a nice locals syntax using the ANS
Forth locals wordset."
}
- 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/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-09 14:42 -0700 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <74df2d2c-132e-4903-8357-d4a019b7ac1c@googlegroups.com> |
| In reply to | #33786 |
On Thursday, October 9, 2014 8:26:25 AM UTC-7, Anton Ertl wrote: > There are two reasons for the > locals stack: > > 1) Alignment of FP locals. If we kept locals on the return stack, we > would have to FP-align the return stack in a lot of places. On 32-bit > machines this costs padding space on the return stack and, if we want > to minimize padding, extra complexity. > > 2) Lift the Forth-94 restructions on combining return stack usage and > locals usage without introducing a lot of complexity. I'm impressed! Also, in the previous post you said: "Uninitialized locals are the only part that's wrong in the proposal that I am aware of." You are admitting that you were wrong when you implemented uninitialized locals! Very few people will ever admit that they were wrong about anything. Way to be!!! This should be our new motto on C.L.F: memegenerator.net/instance/53401411 Strictly speaking though, uninitialized locals aren't the "only part that's wrong," because we also have #2 above: locals "may" be on the return stack, and hence we have that weird restriction about how all >R data has to be removed when any local variable is accessed.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-09 14:07 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct9.160722@mips.complang.tuwien.ac.at> |
| In reply to | #33766 |
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>.
>It is wrong in many ways, of which uninitialized locals are a fairly
>minor part.
Uninitialized locals are the only part that's wrong in the proposal
that I am aware of.
>>>> So the harm of uninitialized locals to the programmer is that he may
>>>> make errors that would be caught (as "undefined word") if the locals
>>>> were defined later, where they are properly initialized.
>>>
>>>Sure, but I do not have to remind you that this is Forth: your bullet,
>>>gun, and foot. Initialized locals are already provided, and if you
>>>prefer to initialize locals, add all of them to the initialized locals
>>>list with whatever constant you prefer as the initial value. The
>>>problem is already solved.
>>
>> No, by defining a local and initializing it to a dummy value before
>> you know the proper initial value, you will not catch a to-early read
>> of the local. This problem is not at all solved in Forth-2012.
>
>And in what way will an initialized local catch a too-early read of a
>local? (I'm assuming we're not talking about multiple locals blocks,
>but the single one that we have.)
It was you who claimed that initialized locals solve the problem that
arises from the restriction to one locals definition that you want to
uphold. I pointed out that it did not. So you have to answer your
question yourself.
>> Anyway, if you think that the existance of initialized locals solves
>> the problem, what problem is solved by uninitialized locals?
>
>I think it's for compatibility with existing usage, isn't it? Because
>there is only one locals block in a word, you have to declare them all
>at the top, and you don't have initial values for them yet.
It's a solution to a problem that we created ourselves with this
restriction (actually, the Forth-94 TC created it, we just upheld it).
Better get rid of the restriction and therefore the problem, then we
don't need that solution.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-09 10:44 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <FL2dncik_pHsMKvJnZ2dnUU7-RmdnZ2d@supernews.com> |
| In reply to | #33784 |
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.
>>It is wrong in many ways, of which uninitialized locals are a fairly
>>minor part.
>
> Uninitialized locals are the only part that's wrong in the proposal
> that I am aware of.
The part I really object to is the dummy return values (effectively a
comment) on the right hand side of the "--". They are misleading.
With those included, and the implication that the locals declaration
be used instead of a stack comment, the whole proposal is so ugly that
I no longer care. This is what I objected to, at length, when the
proposal was on the table.
>>>>> So the harm of uninitialized locals to the programmer is that he may
>>>>> make errors that would be caught (as "undefined word") if the locals
>>>>> were defined later, where they are properly initialized.
>>>>
>>>>Sure, but I do not have to remind you that this is Forth: your bullet,
>>>>gun, and foot. Initialized locals are already provided, and if you
>>>>prefer to initialize locals, add all of them to the initialized locals
>>>>list with whatever constant you prefer as the initial value. The
>>>>problem is already solved.
>>>
>>> No, by defining a local and initializing it to a dummy value before
>>> you know the proper initial value, you will not catch a to-early read
>>> of the local. This problem is not at all solved in Forth-2012.
>>
>>And in what way will an initialized local catch a too-early read of a
>>local? (I'm assuming we're not talking about multiple locals blocks,
>>but the single one that we have.)
>
> It was you who claimed that initialized locals solve the problem that
> arises from the restriction to one locals definition that you want to
> uphold.
It does. It's a way of declaring locals that may be defined later.
That's the problem it solves. But that's nothing to do with a
too-early read of a local.
> I pointed out that it did not. So you have to answer your question
> yourself.
I no longer have any idea what you are talking about.
>>> Anyway, if you think that the existance of initialized locals solves
>>> the problem, what problem is solved by uninitialized locals?
>>
>>I think it's for compatibility with existing usage, isn't it? Because
>>there is only one locals block in a word, you have to declare them all
>>at the top, and you don't have initial values for them yet.
>
> It's a solution to a problem that we created ourselves with this
> restriction (actually, the Forth-94 TC created it, we just upheld
> it).
Yes.
> Better get rid of the restriction and therefore the problem, then we
> don't need that solution.
I don't think so. Look at this:
: strcmp {: addr1 u1 addr2 u2 -- n :}
addr1 addr2
u1 u2 min 0
?do {: s1 s2 :}
s1 c@ s2 c@ -
?dup-if
unloop exit
then
s1 char+ s2 char+
loop
2drop
u1 u2 - ;
It is obvious to anyone skilled in the art that this word needs to be
refactored, and with that refactoring the need for the inner locals
declaration goes away.
Given a word -STR ( a1 a2 u), which does the inner comparison, this
becomes:
: @pair ( a1 a2 - a1 a2 c1 c2) over c@ over c@ ;
: step ( a1 a2 - a1' a2') swap 1+ swap 1+ ;
: -str ( a1 a2 u - n)
0 do
@pair - ?dup if unloop exit then
step
loop
2drop 0 ;
: strcmp {: addr1 u1 addr2 u2 -- n :}
addr1 addr2
u1 u2 min
-str ?dup if exit then
u1 u2 - ;
And with a bit more work the need for any locals goes away altogether.
(Untested, and probably buggy. But you get the idea.)
The question in my mind is whether there is ever a word not in need of
refactoring which needs multiple locals declarations.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-10 16:03 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct10.180311@mips.complang.tuwien.ac.at> |
| In reply to | #33788 |
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. To me it seems that implementing this simple
approach is very little effort. Or do you mean to write that locals
are not worth any effort.
>The part I really object to is the dummy return values (effectively a
>comment) on the right hand side of the "--". They are misleading.
When you know the notation, they are not misleading, but convenient.
Do you really think that
: strcmp ( addr1 u1 addr2 u2 -- n )
{: addr1 u1 addr2 u2 :}
... ;
is an improvement over
: strcmp {: addr1 u1 addr2 u2 -- n :}
... ;
?
>>>>>> So the harm of uninitialized locals to the programmer is that he may
>>>>>> make errors that would be caught (as "undefined word") if the locals
>>>>>> were defined later, where they are properly initialized.
>>>>>
>>>>>Sure, but I do not have to remind you that this is Forth: your bullet,
>>>>>gun, and foot. Initialized locals are already provided, and if you
>>>>>prefer to initialize locals, add all of them to the initialized locals
>>>>>list with whatever constant you prefer as the initial value. The
>>>>>problem is already solved.
>>>>
>>>> No, by defining a local and initializing it to a dummy value before
>>>> you know the proper initial value, you will not catch a to-early read
>>>> of the local. This problem is not at all solved in Forth-2012.
>>>
>>>And in what way will an initialized local catch a too-early read of a
>>>local? (I'm assuming we're not talking about multiple locals blocks,
>>>but the single one that we have.)
>>
>> It was you who claimed that initialized locals solve the problem that
>> arises from the restriction to one locals definition that you want to
>> uphold.
>
>It does. It's a way of declaring locals that may be defined later.
>That's the problem it solves. But that's nothing to do with a
>too-early read of a local.
Yes, that's what I pointed out. Initialized locals while still
allowing only one locals definition are not a solution to that
problem.
>> I pointed out that it did not. So you have to answer your question
>> yourself.
>
>I no longer have any idea what you are talking about.
First you claimed "Initialized locals are already provided [...]. The
problem is already solved." (full quote above). Later you asked "And
in what way will an initialized local catch a too-early read of a
local?" I.e., problem not already solved. Everything quoted above.
I am not to lazy to trim quotes, these quotes are included because
they provide the context.
>I don't think so. Look at this:
>
>: strcmp {: addr1 u1 addr2 u2 -- n :}
> addr1 addr2
> u1 u2 min 0
> ?do {: s1 s2 :}
> s1 c@ s2 c@ -
> ?dup-if
> unloop exit
> then
> s1 char+ s2 char+
> loop
> 2drop
> u1 u2 - ;
>
>It is obvious to anyone skilled in the art that this word needs to be
>refactored, and with that refactoring the need for the inner locals
>declaration goes away.
>
>Given a word -STR ( a1 a2 u), which does the inner comparison, this
>becomes:
>
>: @pair ( a1 a2 - a1 a2 c1 c2) over c@ over c@ ;
>: step ( a1 a2 - a1' a2') swap 1+ swap 1+ ;
>
>: -str ( a1 a2 u - n)
> 0 do
> @pair - ?dup if unloop exit then
> step
> loop
> 2drop 0 ;
>
>: strcmp {: addr1 u1 addr2 u2 -- n :}
> addr1 addr2
> u1 u2 min
> -str ?dup if exit then
> u1 u2 - ;
>
>And with a bit more work the need for any locals goes away altogether.
I would like to see the result.
Anyway, concerning your factored solution, I find it pretty horrible
in many respects, but there's no accounting for tastes.
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:
: strcmp {: addr1 u1 addr2 u2 -- n :}
addr1 addr2
u1 u2 min 0
?do ( s1 s2 )
over c@ over c@ -
?dup-if
nip nip unloop exit
then
over char+ over char+
loop
2drop
u1 u2 - ;
But this is actually just an example demonstrating the
single-assignment style over one that uses TO on locals:
: strcmp {: addr1 u1 addr2 u2 -- n :}
u1 u2 min 0
?do
addr1 c@ addr2 c@ -
?dup-if
unloop exit
then
addr1 char+ TO addr1
addr2 char+ TO addr2
loop
u1 u2 - ;
The original purpose was not to demonstrate the need for inner locals.
I could now search for one example where I used it in production code,
but examples from production code have the problem that they are
usually hard to understand without a ton of context.
>The question in my mind is whether there is ever a word not in need of
>refactoring which needs multiple locals declarations.
If there is not, there is no need for uninitialized locals, either. I
note that you used no uninitialized locals in your version of strcmp,
but you used the "--" feature:-).
I guess if I take the trouble to search for production code with
multiple locals definitions, and challenge you to refactor them, the
result will be equally deafening silence as for my repeated challanges
to refactor locals-containing code in a better way without locals (and
two of the examples are really much too big). Here's the challenge
from two years ago <2012Oct16.134654@mips.complang.tuwien.ac.at>:
|Concerning factoring, it helps in some cases, but not always. I put
|up some cases where I could not come up with a factoring that
|eliminates locals here as a challenge
|<2003Jan25.154659@a0.complang.tuwien.ac.at>
|<a3j4aa$a23$1@news.tuwien.ac.at>
|<2009Sep10.122914@mips.complang.tuwien.ac.at>, but nobody has taken up
|the challenge.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-10 13:35 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <R5ydnXUuLoNtu6XJnZ2dnUU7-X2dnZ2d@supernews.com> |
| In reply to | #33820 |
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.
> To me it seems that implementing this simple approach is very little
> effort. Or do you mean to write that locals are not worth any
> effort.
They're not worth any further effort. The only reason we have such an
elaborate system as we have now is that some vendors want to keep some
customers who don't get it (and will probably never get it) happy.
IMO.
>>The part I really object to is the dummy return values (effectively a
>>comment) on the right hand side of the "--". They are misleading.
>
> When you know the notation, they are not misleading, but convenient.
>
> Do you really think that
>
> : strcmp ( addr1 u1 addr2 u2 -- n )
> {: addr1 u1 addr2 u2 :}
> ... ;
>
> is an improvement over
>
> : strcmp {: addr1 u1 addr2 u2 -- n :}
> ... ;
>
> ?
Yes although I would not do either. 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.
> Anyway, concerning your factored solution, I find it pretty horrible
> in many respects, but there's no accounting for tastes.
>
> 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!
>>The question in my mind is whether there is ever a word not in need of
>>refactoring which needs multiple locals declarations.
>
> If there is not, there is no need for uninitialized locals, either.
That follows.
> I note that you used no uninitialized locals in your version of
> strcmp, but you used the "--" feature:-).
I copied it from you. I did not and would not write such a thing
myself.
> I guess if I take the trouble to search for production code with
> multiple locals definitions, and challenge you to refactor them, the
> result will be equally deafening silence as for my repeated challanges
> to refactor locals-containing code in a better way without locals (and
> two of the examples are really much too big)
Probably. Like you, I have at least one job already.
> Here's the challenge from two years ago
> <2012Oct16.134654@mips.complang.tuwien.ac.at>:
>
> |Concerning factoring, it helps in some cases, but not always. I put
> |up some cases where I could not come up with a factoring that
> |eliminates locals here as a challenge
> |<2003Jan25.154659@a0.complang.tuwien.ac.at>
> |<a3j4aa$a23$1@news.tuwien.ac.at>
> |<2009Sep10.122914@mips.complang.tuwien.ac.at>, but nobody has taken up
> |the challenge.
My news server can't find the first two. The last one doesn't seem to
use multiple locals declarations.
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 ` ; ;
Or, perhaps better:
: <map-array ` cells ` over ` + ` swap ` do ` i ` @ ; immediate
: map-array> ` cell ` +loop ; immediate
Of course there will always be examples of (rather contrived?)
problems which resist nice factoring. The point with Forth, as
always, is to find a solution which is nicely factored, and if that
means taking a different approach from the one you first thought of,
so be it.
Incidentally, I have on at least one occasion here had to resort to
locals, but that's pretty rare, and not something which requires an
elaborate locals facility. So no, I am not saying that there is never
any need for locals.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-11 10:53 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct11.125348@mips.complang.tuwien.ac.at> |
| In reply to | #33822 |
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.
>> To me it seems that implementing this simple approach is very little
>> effort. Or do you mean to write that locals are not worth any
>> effort.
>
>They're not worth any further effort.
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.
Anyway, my guess is that one could lift that restriction with about 10
lines of code, but of course that depends on what the original code
looks like.
>>>The part I really object to is the dummy return values (effectively a
>>>comment) on the right hand side of the "--". They are misleading.
>>
>> When you know the notation, they are not misleading, but convenient.
>>
>> Do you really think that
>>
>> : strcmp ( addr1 u1 addr2 u2 -- n )
>> {: addr1 u1 addr2 u2 :}
>> ... ;
>>
>> is an improvement over
>>
>> : strcmp {: addr1 u1 addr2 u2 -- n :}
>> ... ;
>>
>> ?
>
>Yes although I would not do either.
Well, to anyone skilled in the art code redundancy in is bad.
>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?
>> 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.
>> I guess if I take the trouble to search for production code with
>> multiple locals definitions, and challenge you to refactor them, the
>> result will be equally deafening silence as for my repeated challanges
>> to refactor locals-containing code in a better way without locals (and
>> two of the examples are really much too big)
>
>Probably. Like you, I have at least one job already.
Then I will not search for them.
>> Here's the challenge from two years ago
>> <2012Oct16.134654@mips.complang.tuwien.ac.at>:
>>
>> |Concerning factoring, it helps in some cases, but not always. I put
>> |up some cases where I could not come up with a factoring that
>> |eliminates locals here as a challenge
>> |<2003Jan25.154659@a0.complang.tuwien.ac.at>
>> |<a3j4aa$a23$1@news.tuwien.ac.at>
>> |<2009Sep10.122914@mips.complang.tuwien.ac.at>, but nobody has taken up
>> |the challenge.
>
>My news server can't find the first two.
You can look them up on google through
<http://www.complang.tuwien.ac.at/anton/search.html> (but works only
with JavaScript).
>The last one doesn't seem to
>use multiple locals declarations.
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.
>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 ... ;
Not so nice.
>Or, perhaps better:
>
>: <map-array ` cells ` over ` + ` swap ` do ` i ` @ ; immediate
>: map-array> ` cell ` +loop ; immediate
Used like
: foo ... <map-array + map-array> ... ;
Neither is usable interpretively, unlike the original MAP-ARRAY.
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. You circumvent this by passing the xt at a different time
level in your first variant, and by not passing an xt at all in the
latter variant.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-12 11:34 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2_CdnedZqtY0MKfJnZ2dnUU7-VOdnZ2d@supernews.com> |
| In reply to | #33841 |
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? It's an opinion. Just like "not that hard" was an opinion. There's not much argument about how to do it. >>> To me it seems that implementing this simple approach is very little >>> effort. Or do you mean to write that locals are not worth any >>> effort. >> >>They're not worth any further effort. > > 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. > Anyway, my guess is that one could lift that restriction with about 10 > lines of code, but of course that depends on what the original code > looks like. Okay, fair enough. >>Yes although I would not do either. > > Well, to anyone skilled in the art code redundancy in is bad. I absolutely agree, but it's the lesser of two evils. IMO. >>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. >>> 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. >>> Here's the challenge from two years ago >>> <2012Oct16.134654@mips.complang.tuwien.ac.at>: >>> >>> |Concerning factoring, it helps in some cases, but not always. I put >>> |up some cases where I could not come up with a factoring that >>> |eliminates locals here as a challenge >>> |<2003Jan25.154659@a0.complang.tuwien.ac.at> >>> |<a3j4aa$a23$1@news.tuwien.ac.at> >>> |<2009Sep10.122914@mips.complang.tuwien.ac.at>, but nobody has taken up >>> |the challenge. >> >>My news server can't find the first two. > > You can look them up on google through > <http://www.complang.tuwien.ac.at/anton/search.html> (but works only > with JavaScript). That is so weird. I wonder why that didn't work before. Anyway, got it now. >>The last one doesn't seem to use multiple locals declarations. > > 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. 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. But factoring surely at least *reduces* the need for multiple locals declarations, because one can factor out an inner block. Well, modulo things which make factoring problematic such as UNLOOP . Why are the exponential and fixed-point notations not factored out of F>BUF-RDP-TRY , anyway? >>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 ... ; > Not so nice. > >>Or, perhaps better: >> >>: <map-array ` cells ` over ` + ` swap ` do ` i ` @ ; immediate >>: map-array> ` cell ` +loop ; immediate > > Used like > > : foo ... <map-array + map-array> ... ; > > Neither is usable interpretively, unlike the original MAP-ARRAY. The first one is, surely. Unless your definition of "interpretive use" excludes throwaway definitions, and I can't imagine why it would. > 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. This is cumbersome for *portable* Forth code, but for the kind of turnkey application Forth has shined at it doesn't matter. > You circumvent this by passing the xt at a different time level in > your first variant, and by not passing an xt at all in the latter > variant. 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 LISPers might like that kind of thing, I suppose. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-15 12:44 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct15.144442@mips.complang.tuwien.ac.at> |
| In reply to | #33861 |
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/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-15 14:34 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <543e85f5$0$15842$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #33910 |
In article <2014Oct15.144442@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
<SNIP>
>
>>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.
Suddenly I seem to understand this better.
Is it true that
EVALUATE
is equivalent to
' INTERPRET EXECUTE-PARSING
?
>
>-
>--
>M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-15 15:03 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct15.170356@mips.complang.tuwien.ac.at> |
| In reply to | #33912 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>Suddenly I seem to understand this better.
>Is it true that
> EVALUATE
>is equivalent to
> ' INTERPRET EXECUTE-PARSING
>?
Yes. The definition of EVALUATE in Gforth is:
: evaluate ( ... addr u -- ... ) \ core,block
\G [... documentation ...]
['] interpret execute-parsing ;
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-15 11:10 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <3dSdnTQ6X5oRAaPJnZ2dnUU7-XOdnZ2d@supernews.com> |
| In reply to | #33910 |
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:
>>>>> 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.
I see. 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.
>>> 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.
Sorry, I was referring more to the current locals proposal, which
seems to encourage the use of locals where not needed. 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.
>>> 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.
Indeed. 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.
>>>>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"?
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? Why
adding more work into a definition is a bad thing?
>>>>> 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.
Of course.
> 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.
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. There
are exceptions to this, especially low-complexity words which are just
lists of items with no control structures.
>>> 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.)
>>> 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.
Perhaps that is a fair criticism, yes. It's a matter of degree.
>>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.
> 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.
It has, but IMHO xt-passing should be reserved for those cases: it is
not appropriate for more general use.
Andrew.
[1] From _The Evolution Of Forth_
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-16 12:19 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct16.141939@mips.complang.tuwien.ac.at> |
| In reply to | #33921 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-17 03:56 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <GNKdnUPWhZo1RN3JnZ2dnUU7-eOdnZ2d@supernews.com> |
| In reply to | #33943 |
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.
> BTW, "changes in ten lines" does not mean "ten more lines".
OK, my mistake.
>>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.
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.
> 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. You miss the point
about what gives Forth its unique character. It's not about the
stack: it's about the Basic Principle. colorForth is not the only
possibility, it's one possibility, for one area of application.
>>>>>>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.
Any Forth word which has to manipulate more than three stack items may
fall prey to "stack noise" problems, as we've noted here many times
before. It's time to look at why that word is being called with so
many parameters, and look at its call site to see if it has similar
problems. And it probably will have.
>>> 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.
> 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.
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.)
So how can we use examples as a way to establish principles and
general rules of thumb?
>>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?
No: the "seven, plus or minus two" is a *maximium*.
> 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. -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.
>>>>> 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.
I try not to over-state my claims, especially about style. That
necessarily means that they are hedged with "if"s and "but"s: there
are few hard and fast rules about how to program in any language. So
of course the goalposts are somewhat undefined.
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. You must know that trying to fix such a
piece of code is such a substantial undertaking that few will attempt
it, and those who could do a good job are probably too busy to do so.
> 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.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-17 07:48 -1000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <JrKdnVaTUqH_y9zJnZ2dnUU7-cednZ2d@supernews.com> |
| In reply to | #33972 |
On 10/16/14 10:56 PM, Andrew Haley wrote: > 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.) > > So how can we use examples as a way to establish principles and > general rules of thumb? > >>> >>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? > No: the "seven, plus or minus two" is a*maximium*. > This exchange encapsulates nicely why I have rarely seen a case where locals were useful. The major example that stands out in my mind is the problem of Windows calls, with many arguments all of which are known by standardized names. These are usually definitions that are not logically complex, but must wrestle with all those arguments. Locals are very useful in that case, and the overhead of actually executing the call will vastly overshadows the cost of having the locals frame. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-17 19:26 -0700 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <a4b21efa-ac12-4dad-96ca-0cbe661b538b@googlegroups.com> |
| In reply to | #33983 |
On Friday, October 17, 2014 10:48:20 AM UTC-7, Elizabeth D. Rather wrote: > This exchange encapsulates nicely why I have rarely seen a case where > locals were useful. In SwiftForth-v2 (that I paid over $400 for), locals didn't work. The (LOCAL) word would crash the system when it was used. So, you have not only rarely seen a case where locals were useful, but you have never seen a case where locals were used at all --- or you would have noticed the problem with (LOCAL) crashing SwiftForth. LOL --- you're so funny! --- the way that you pretend to be an expert on subjects that you know exactly nothing about...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-18 12:55 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct18.145533@mips.complang.tuwien.ac.at> |
| In reply to | #33972 |
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/
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web