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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-18 13:21 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <cNKdnXYe2Y48Mt_JnZ2dnUU7-TudnZ2d@supernews.com> |
| In reply to | #34010 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>
>>>>We've got too much of it already and the Basic Principle of Forth is
>>>>"Keep it simple!":
> ...
>>>>"It is very hard to apply. All the pressures, internal and external,
>>>>conspire to add features to your program. After all, it only takes a
>>>>half-dozen instructions, so why not? The only opposing pressure is the
>>>>Basic Principle, and if you ignore it, there is no opposing pressure."
>>>>[1]
> ...
>>> Sure, if you follow it, you arrive at colorForth, I guess. I don't
>>> arrive at colorForth in my Forth work, so I obviously don't agree with
>>> it.
>>
>>No, that does not follow. The Basic Principle also led to miniForth,
>>polyFORTH, and (indirectly) fig-FORTH and all its derivatives. It
>>does not only lead to one solution.
>
> 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?
Yes, of course. There are, as Chuck says, pressures, and it's mater
of striking the balance. As I understand what Chuck says, it is a way
of opposing the trend to ever-increasing complexity which plagues the
entire field. The difference with Forth is that the balance between
simplicity and features is at a different point: simplicity is
weighted much more heavily. And yes, that's a judgement call.
>>> 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.
True, but between us we might be able to get somewhere close, but IMO
we surely won't if we ignore the principle. It is what made Forth
unique.
> 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.
I agree with all that, but I am trying to encourage everyone to
concentrate on whether more features are really needed.
In once place I worked we use to call some features "WIBNIs", where a
WIBNI was short for "Wouldn't It Be Nice If..." WIBNIs should be
avoided like the plague; features should be added if they're *needed*.
And multiple locals declarations, even if occasionally nice to have,
are not necessary.
>>>>>>>>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.
We must agree to differ.
> What are "back-and-forth noise words"? And what do you mean with
> "work in the definition"?
"Back-and-forth noise" is just the normal use of English: you put a
stack item into a local only immediately to remove it. That's what I
mean by "work", even if a very clever compiler can detect that you
didn't really mean to move the item and leaves it where it was.
>>> Of course, in the past you have often made claims in the abstract,
>>> and any refutation of such a claim was answered by saying that I had
>>> misrepresented your claim (of course without making your claims any
>>> more concrete, just to keep them unrefutable). That's what I
>>> consider pointless.
>>
>>I take your point. So what then shall we do? If we have specific
>>examples we'll end up nitpicking them to death and not arriving at any
>>conclusion.
>
> I think the chance of arriving at a conclusion in a discussion between
> us is much higher when working with concrete examples than when
> working with abstract generalities.
But we'll only end up with a conclusion about those examples.
>>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.
It wouldn't prove anything though, would it? We'll only end up with a
conclusion about *that one example*. And that particular example does
not matter at all. It's a substantial effort for zero gain: all it
does is prove that some people will jump through hoops.
>>> 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.
Not for me. Let's move on.
>>-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.
We really do disagree about that, and it seems to me that a word which
fetches two bytes from two pointers represents a pretty easily
identifiable concept, as does a word which bumps two pointers.
> And do I really want to invent test cases for words that have no
> identifiable purpose?
I'm trying to get my head around what this implies. Are you really
saying that if you factor a word you have to test the factors, so that
is a pressure against factoring?
>>> 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,
No, I'm writing lots of prose in response to your lots of prose. I
don't need to justify my not attacking any of your 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.
There is no point. If no-one attacks your harder examples, it proves
that either
a. They are insoluble without locals
b. No-one has the time or motivation to work on them
c. They are so badly formulated that they resist understanding
without providing any way to choose between these possibilities. And
there is still the risk I alluded to that someone would come up with
even more gnarly code, ad nauseam. However, I have to concede that
something more gnarly than the example you came up with is pretty
unlikely.
> It also reduces the faith in the veracity of the claims that
> locals can always be eliminated by better factoring.
I have already said that locals are in a few cases useful or perhaps
even necessary, so "always" is a tilt against a straw man.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-18 08:44 -1000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <b5ydnbm0nJSXKN_JnZ2dnUU7-cednZ2d@supernews.com> |
| In reply to | #34013 |
On 10/18/14 8:21 AM, Andrew Haley wrote: >>>> 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? > Yes, of course. There are, as Chuck says, pressures, and it's mater > of striking the balance. As I understand what Chuck says, it is a way > of opposing the trend to ever-increasing complexity which plagues the > entire field. The difference with Forth is that the balance between > simplicity and features is at a different point: simplicity is > weighted much more heavily. And yes, that's a judgement call. > Actually, I don't find ColorForth advancing "simplicity" at all. It adds the complexity of color, edit-time processing, user interface issues, file sharing and maintenance difficulties, etc. 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-19 09:53 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <54438a32$0$6908$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #34014 |
In article <b5ydnbm0nJSXKN_JnZ2dnUU7-cednZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: > >Actually, I don't find ColorForth advancing "simplicity" at all. It adds >the complexity of color, edit-time processing, user interface issues, >file sharing and maintenance difficulties, etc. Indeed. Primitive rather then simple. As you may remember I made a tool to convert colorforth to something coded in ASCII, such that sources could be stored in source control. One shouldn't be forced to go through that. Having worked with both the SeaForth and the Ga144 development systems, I think the Seaforth system was superior. My impression was that GreenArrays couldn't use that for copyright reasons and settled for less. > >Cheers, >Elizabeth 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-20 12:48 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct20.144848@mips.complang.tuwien.ac.at> |
| In reply to | #34013 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>>>>We've got too much of it already and the Basic Principle of Forth is
>>>>>"Keep it simple!":
>> ...
>>>>>"It is very hard to apply. All the pressures, internal and external,
>>>>>conspire to add features to your program. After all, it only takes a
>>>>>half-dozen instructions, so why not? The only opposing pressure is the
>>>>>Basic Principle, and if you ignore it, there is no opposing pressure."
>>>>>[1]
>> ...
>>>> Sure, if you follow it, you arrive at colorForth, I guess. I don't
>>>> arrive at colorForth in my Forth work, so I obviously don't agree with
>>>> it.
>>>
>>>No, that does not follow. The Basic Principle also led to miniForth,
>>>polyFORTH, and (indirectly) fig-FORTH and all its derivatives. It
>>>does not only lead to one solution.
I doubt that Chuck Moore sees all of these systems as equally good and
valid solutions. It's a progression: First he did Forth, the
mini-Forth, then microForth, then cmForth, then machineForth, and now
colorForth. At every step he gave preference to his new design over
his old design, and he never returned to miniForth or PolyForth. He
did abandon the approach of leaving the Forth compiler/text
interpreter away completely (OKAD).
> There are, as Chuck says, pressures, and it's mater
>of striking the balance. As I understand what Chuck says, it is a way
>of opposing the trend to ever-increasing complexity which plagues the
>entire field. The difference with Forth is that the balance between
>simplicity and features is at a different point: simplicity is
>weighted much more heavily. And yes, that's a judgement call.
Yes, Charles Moore certainly did that, although, as the comment of
Elizabeth Rather shows, simplicity is in the eye of the beholder.
Another interesting thing in this respect is Richard Gabriel's
characterization of the Unix (Ken Thompson) philosophy
<http://en.wikipedia.org/wiki/Worse_is_better>, which Gabriel says
always values implementation simplicity above all else. One might
think that this would lead to similar results as the Forth (Chuck
Moore) philosophy, and indeed, early Unix is remarkably similar to
early Forth, but one difference in philosophy is that the Unix people
favour reusablility, whereas Chuck Moore pretty much rejects it. And
there are other differences.
>> 1) Capability: Not everyone is as capable as Charles Moore, Ken
>> Thompson, or Jochen Liedtke at finding simple solutions.
>
>True, but between us we might be able to get somewhere close, but IMO
>we surely won't if we ignore the principle.
Ok, but my point was not to ignore simplicity. Instead, I
contradicted the claim that you need an axiomatic Basic Principle to
keep things simple, because there is supposedly no other force acting
against complexity.
>In once place I worked we use to call some features "WIBNIs", where a
>WIBNI was short for "Wouldn't It Be Nice If..." WIBNIs should be
>avoided like the plague; features should be added if they're *needed*.
>And multiple locals declarations, even if occasionally nice to have,
>are not necessary.
N>R and NR> are not necessary, either, and I don't consider them nice
to have. Your reaction: "what's not to like?".
Sure, you can rewrite programs with multiple locals definitions in the
VFX style, and they become longer and harder to read and understand.
And of course shorter and easer to read and understand programs are
just nice to have and not really necessary, like most other things,
but I think that that multiple locals definition still lead to an
overall improvement.
>>>> A simple example is:
>>>>
>>>> : bla {: a b c d -- :}
>>>> d . a . b . c . ;
>>>>
>>>> Now one could write instead:
>>>>
>>>> : bla ( a b c d -- )
>>>> . {: a b c :} a . b . c . ;
>>>>
>>>> Is this an improvement? The source code certainly is longer and has
>>>> more tokens.
>>>
>>>They're both pretty unpleasant. You're asking me whether I prefer a
>>>pile of muck or a bucket of sick, and I think I'll decline. But in
>>>general the second case is marginally better because it uses fewer
>>>locals, IMO.
>>
>> But it's more work for the programmer. More characters. More tokens.
>> And therefore harder to understand.
>
>We must agree to differ.
Do you claim that it's not more characters and not more tokens?
>> What are "back-and-forth noise words"? And what do you mean with
>> "work in the definition"?
>
>"Back-and-forth noise" is just the normal use of English: you put a
>stack item into a local only immediately to remove it. That's what I
>mean by "work", even if a very clever compiler can detect that you
>didn't really mean to move the item and leaves it where it was.
So you mean something like static or dynamic executable code size from
a simple Forth compiler?
Why not write that clearly? Or if you mean something else, what do
you mean?
>>>> Of course, in the past you have often made claims in the abstract,
>>>> and any refutation of such a claim was answered by saying that I had
>>>> misrepresented your claim (of course without making your claims any
>>>> more concrete, just to keep them unrefutable). That's what I
>>>> consider pointless.
>>>
>>>I take your point. So what then shall we do? If we have specific
>>>examples we'll end up nitpicking them to death and not arriving at any
>>>conclusion.
>>
>> I think the chance of arriving at a conclusion in a discussion between
>> us is much higher when working with concrete examples than when
>> working with abstract generalities.
>
>But we'll only end up with a conclusion about those examples.
Sure, there are people who will see every counterexample to their
beliefs only as exceptions that prove the rule, but discussing with
such people is not going to be very productive anyway (and even less
if one discusses only about generalities with them), so that's not the
kind of people that we should be concerned with in considering how we
should discuss.
>> Yes, that's a claim I have read again and again, and I posted a
>> challenge to give the claimers a chance to prove it.
>
>It wouldn't prove anything though, would it?
Sure it would provide evidence supporting the claim, and a pretty
strong one at that, given that the other side selected the examples.
I did not use "prove" in the mathematical sense here.
BTW, if you don't want to refactor the existing words, the alternative
is to write a new implementation from scratch. The examples include
specifications and test cases.
>> I think "factoring" code into a separate word that does not represent
>> an identifiable concept (your @PAIR and STEP words) reduces, rather
>> than increases clarity.
>
>We really do disagree about that, and it seems to me that a word which
>fetches two bytes from two pointers represents a pretty easily
>identifiable concept
That's certainly not *one* concept, but even if it were, from your
description I would expect such a word to have the stack effect
( addr1 addr2 -- c1 c2 ), whereas your @pair has ( a1 a2 - a1 a2 c1 c2).
>as does a word which bumps two pointers.
Not one concept, either.
>> And do I really want to invent test cases for words that have no
>> identifiable purpose?
>
>I'm trying to get my head around what this implies. Are you really
>saying that if you factor a word you have to test the factors, so that
>is a pressure against factoring?
No. You claimed: "it is often useful to separate out factors, for
testing and clarity". If I don't test them, it's not useful to factor
them out for testing. And factoring out words that don't represent an
identifiable concept reduces, rather than increases clarity. So here
we have have a case where none the reasons you gave for factoring
apply (at least not for this factoring), and indeed there is a reason
not to.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-10-20 16:24 -0400 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <op.xn1pmnd1mk81un@localhost> |
| In reply to | #34030 |
On Mon, 20 Oct 2014 08:48:48 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > I doubt that Chuck Moore sees all of these systems as equally good and > valid solutions. It's a progression: First he did Forth, the > mini-Forth, then microForth, then cmForth, then machineForth, and now > colorForth. At every step he gave preference to his new design over > his old design, and he never returned to miniForth or PolyForth. He > did abandon the approach of leaving the Forth compiler/text > interpreter away completely (OKAD). When I read a statement like that, this is what I think about it. 1) Charles Moore has contined to search for what he believes is the most optimal solution for implementing Forth. 2) Charles Moore hasn't found that solution yet. Since he's the creator of Forth, I think that says something. BTW, you listed the Forths through which C.M. progressed and later referenced one that wasn't in your list of progessions: PolyForth. Where does it go in the list? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-20 10:30 -1000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <NtWdndCErbB17djJnZ2dnUU7-VudnZ2d@supernews.com> |
| In reply to | #34036 |
On 10/20/14 10:24 AM, Rod Pemberton wrote: > On Mon, 20 Oct 2014 08:48:48 -0400, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: > >> I doubt that Chuck Moore sees all of these systems as equally good and >> valid solutions. It's a progression: First he did Forth, the >> mini-Forth, then microForth, then cmForth, then machineForth, and now >> colorForth. At every step he gave preference to his new design over >> his old design, and he never returned to miniForth or PolyForth. He >> did abandon the approach of leaving the Forth compiler/text >> interpreter away completely (OKAD). > > When I read a statement like that, this is what I think about it. > > 1) Charles Moore has contined to search for what he believes > is the most optimal solution for implementing Forth. > > 2) Charles Moore hasn't found that solution yet. Since > he's the creator of Forth, I think that says something. What it says is that he is the type of creative person who is never satisfied with the current state of his work, but always seeks for something better. Sometimes what he finds is better, sometimes not, but the search goes on. > BTW, you listed the Forths through which C.M. progressed and > later referenced one that wasn't in your list of progessions: > PolyForth. Where does it go in the list? polyFORTH was after microFORTH and before cmForth. polyFORTH (and, for that matter, microFORTH) were collaborative efforts of the engineers at FORTH, Inc., including Chuck. Dean Sanderson was a major contributor to microFORTH, and was also on the team that produced polyFORTH (as was Greg Bailey and some other people). 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-20 16:23 -0700 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <9a4305ac-39d4-4a92-b243-8d1980ebc016@googlegroups.com> |
| In reply to | #34037 |
On Monday, October 20, 2014 1:30:34 PM UTC-7, Elizabeth D. Rather wrote: > polyFORTH was after microFORTH and before cmForth. polyFORTH (and, for > that matter, microFORTH) were collaborative efforts of the engineers at > FORTH, Inc., including Chuck. Dean Sanderson was a major contributor to > microFORTH, and was also on the team that produced polyFORTH (as was > Greg Bailey and some other people). Did Charles Moore leave Forth Inc. before or after the 16-bit x86 implementation of PolyForth? I have always been amazed that the implementers of the MS-DOS PolyForth were unable to figure out how the segment registers worked, and so they put the entire system in a single 64K segment. Did Charles Moore make this incredible blunder? Or, did Charles Moore write the previous version on a 64K machine, such as the PDP-11, and those who remained at Forth Inc. after he left ported it over to the MS-DOS computer --- and they just did a line-by-line port, so they still had the 64K limitation from the previous computer? I find it difficult to believe that Charles Moore could be smart enough to invent Forth, but not smart enough to grasp the concept of 8086 segmentation --- but sometimes people are smart in one area, but not smart in other areas.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 04:16 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <8tydnedGaJWeIdHJnZ2dnUU7-SWdnZ2d@supernews.com> |
| In reply to | #34030 |
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: >>> >>>>>>We've got too much of it already and the Basic Principle of Forth is >>>>>>"Keep it simple!": >>> ... >>>>>>"It is very hard to apply. All the pressures, internal and external, >>>>>>conspire to add features to your program. After all, it only takes a >>>>>>half-dozen instructions, so why not? The only opposing pressure is the >>>>>>Basic Principle, and if you ignore it, there is no opposing pressure." >>>>>>[1] >>> ... >>>>> Sure, if you follow it, you arrive at colorForth, I guess. I don't >>>>> arrive at colorForth in my Forth work, so I obviously don't agree with >>>>> it. >>>> >>>>No, that does not follow. The Basic Principle also led to miniForth, >>>>polyFORTH, and (indirectly) fig-FORTH and all its derivatives. It >>>>does not only lead to one solution. > > I doubt that Chuck Moore sees all of these systems as equally good and > valid solutions. It's a progression: First he did Forth, the > mini-Forth, then microForth, then cmForth, then machineForth, and now > colorForth. At every step he gave preference to his new design over > his old design, and he never returned to miniForth or PolyForth. He > did abandon the approach of leaving the Forth compiler/text > interpreter away completely (OKAD). Sure, that's probably so, but so what? Forth is the product of many people's efforts and opinions. >>> 1) Capability: Not everyone is as capable as Charles Moore, Ken >>> Thompson, or Jochen Liedtke at finding simple solutions. >> >>True, but between us we might be able to get somewhere close, but IMO >>we surely won't if we ignore the principle. > > Ok, but my point was not to ignore simplicity. Instead, I > contradicted the claim that you need an axiomatic Basic Principle to > keep things simple, because there is supposedly no other force acting > against complexity. Perhaps. It is certainly true that Forth takes a pretty extreme position on the complexity - features line, and its unique character is due to that position. It does mean that new language features should have a high bar to jump. >>In once place I worked we use to call some features "WIBNIs", where a >>WIBNI was short for "Wouldn't It Be Nice If..." WIBNIs should be >>avoided like the plague; features should be added if they're *needed*. >>And multiple locals declarations, even if occasionally nice to have, >>are not necessary. > > N>R and NR> are not necessary, either, and I don't consider them nice > to have. Your reaction: "what's not to like?". Indeed, and that was a judgement call. They are necessary IMO because of other parts of standard Forth. And they are standalone words which don't have the (IMO) dramatic effect on the language that locals do. (And I really needed them at the time for software transactional memory, so I knew for certain that they had uses beyond their initial motivation.) > Sure, you can rewrite programs with multiple locals definitions in the > VFX style, and they become longer and harder to read and understand. > And of course shorter and easer to read and understand programs are > just nice to have and not really necessary, like most other things, > but I think that that multiple locals definition still lead to an > overall improvement. I do not disagree. If you have words long enough really to need them, yes, multiple locals definitions do undoubtedly lead to an improvement. >>"Back-and-forth noise" is just the normal use of English: you put a >>stack item into a local only immediately to remove it. That's what I >>mean by "work", even if a very clever compiler can detect that you >>didn't really mean to move the item and leaves it where it was. > > So you mean something like static or dynamic executable code size from > a simple Forth compiler? > > Why not write that clearly? Or if you mean something else, what do > you mean? I give up! >>We really do disagree about that, and it seems to me that a word which >>fetches two bytes from two pointers represents a pretty easily >>identifiable concept > > That's certainly not *one* concept, but even if it were, from your > description I would expect such a word to have the stack effect > ( addr1 addr2 -- c1 c2 ), whereas your @pair has ( a1 a2 - a1 a2 c1 c2). Only if you dogmatically insist on the "a word must consume its arguments" rule at the expense of the caller. >>as does a word which bumps two pointers. > > Not one concept, either. Is so. But this is what I'm talking about: pointless nitpicking of minor details at the expense of the wider discussion. So you don't like my factoring. I don't like yours. >>> And do I really want to invent test cases for words that have no >>> identifiable purpose? >> >>I'm trying to get my head around what this implies. Are you really >>saying that if you factor a word you have to test the factors, so that >>is a pressure against factoring? > > No. You claimed: "it is often useful to separate out factors, for > testing and clarity". If I don't test them, it's not useful to factor > them out for testing. So don't then, then, but I would. Not all programmers work in the same way. > And factoring out words that don't represent an identifiable concept > reduces, rather than increases clarity. So here we have have a case > where none the reasons you gave for factoring apply (at least not > for this factoring), and indeed there is a reason not to. And there we must, again, agree to differ. I have no problem identifying what the words in question do and I don't think that clarity is reduced. But I'm not prepared to spend much effort defending this factoring: I suspect it's not ideal, and a better job could be done given some thought. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2014-10-26 11:32 +0200 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <89719209938433@frunobulax.edu> |
| In reply to | #34150 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes Re: uninitialized and implicitly initialized locals [.. discussion I want no part in ..] >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> N>R and NR> are not necessary, either, and I don't consider them nice >> to have. Your reaction: "what's not to like?". > Indeed, and that was a judgement call. They are necessary IMO because > of other parts of standard Forth. And they are standalone words which > don't have the (IMO) dramatic effect on the language that locals do. > (And I really needed them at the time for software transactional > memory, so I knew for certain that they had uses beyond their initial > motivation.) [..] I am disgusted that N>R and NR> ever got in the standard. Your reason to back them is not convincing (how many current systems allow transactional memory, why do they need a standardized N>R and NR> to provide it, what must-have features do N>R and NR> enable in a Standard Forth). -marcel
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-10-26 14:27 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <544d04a7.317551001@news.demon.co.uk> |
| In reply to | #34155 |
On Sun, 26 Oct 2014 11:32:14 +0200, mhx@iae.nl (Marcel Hendrix) wrote: >I am disgusted that N>R and NR> ever got in the standard. Your reason to >back them is not convincing (how many current systems allow transactional >memory, why do they need a standardized N>R and NR> to provide it, what >must-have features do N>R and NR> enable in a Standard Forth). Easily portable code that uses SAVE-INPUT and RESTORE-INPUT. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 13:56 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <jLqdneC_q99V3tDJnZ2dnUU7-bednZ2d@supernews.com> |
| In reply to | #34155 |
Marcel Hendrix <mhx@iae.nl> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes Re: uninitialized and implicitly initialized locals > [.. discussion I want no part in ..] >>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> N>R and NR> are not necessary, either, and I don't consider them nice >>> to have. Your reaction: "what's not to like?". > >> Indeed, and that was a judgement call. They are necessary IMO because >> of other parts of standard Forth. And they are standalone words which >> don't have the (IMO) dramatic effect on the language that locals do. >> (And I really needed them at the time for software transactional >> memory, so I knew for certain that they had uses beyond their initial >> motivation.) > [..] > > I am disgusted that N>R and NR> ever got in the standard. Your > reason to back them is not convincing (how many current systems > allow transactional memory, why do they need a standardized N>R and > NR> to provide it, what must-have features do N>R and NR> enable in > a Standard Forth). At the time, this was discussed quite thoroughly, and your response was > Sorry, I overlooked the crucial "variable number of". I can't find > a variable number of args in my sources, nor a reason why that should > be portable, but I have a sudden insight where this is going :-) > > Splendid idea! It seems to me that the original reason in the RFD was quite adequate. And the discussion was not patricularly controversial. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2014-10-26 20:32 +0200 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <13711509938433@frunobulax.edu> |
| In reply to | #34165 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes Re: uninitialized and implicitly initialized locals > Marcel Hendrix <mhx@iae.nl> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes Re: uninitialized and implicitly initialized locals [..] > At the time, this was discussed quite thoroughly, and your response > was >> Sorry, I overlooked the crucial "variable number of". I can't find >> a variable number of args in my sources, nor a reason why that should >> be portable, but I have a sudden insight where this is going :-) >> Splendid idea! > It seems to me that the original reason in the RFD was quite adequate. > And the discussion was not patricularly controversial. I guess my sarcasm was lost on you. Serves me right. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 16:18 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <wdKdnTE9dba8-NDJnZ2dnUU7-UWdnZ2d@supernews.com> |
| In reply to | #34173 |
Marcel Hendrix <mhx@iae.nl> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes Re: uninitialized and implicitly initialized locals > >> Marcel Hendrix <mhx@iae.nl> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes Re: uninitialized and implicitly initialized locals > [..] >> At the time, this was discussed quite thoroughly, and your response >> was > >>> Sorry, I overlooked the crucial "variable number of". I can't find >>> a variable number of args in my sources, nor a reason why that should >>> be portable, but I have a sudden insight where this is going :-) > >>> Splendid idea! > >> It seems to me that the original reason in the RFD was quite adequate. >> And the discussion was not patricularly controversial. > > I guess my sarcasm was lost on you. Serves me right. Yes, it does. If you had a serious objection you should have expressed it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-26 15:05 -0700 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <104927e2-6a9a-4367-893f-3a66190f114d@googlegroups.com> |
| In reply to | #34155 |
On Sunday, October 26, 2014 3:32:16 AM UTC-7, Marcel Hendrix wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes Re: uninitialized and implicitly initialized locals
> [.. discussion I want no part in ..]
> >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> >> N>R and NR> are not necessary, either, and I don't consider them nice
> >> to have. Your reaction: "what's not to like?".
>
> > Indeed, and that was a judgement call. They are necessary IMO because
> > of other parts of standard Forth. And they are standalone words which
> > don't have the (IMO) dramatic effect on the language that locals do.
> > (And I really needed them at the time for software transactional
> > memory, so I knew for certain that they had uses beyond their initial
> > motivation.)
> [..]
>
> I am disgusted that N>R and NR> ever got in the standard. Your reason to
> back them is not convincing (how many current systems allow transactional
> memory, why do they need a standardized N>R and NR> to provide it, what
> must-have features do N>R and NR> enable in a Standard Forth).
N>R and NR> were introduced immediately after Leon Wagner killed my ALLOCATION RfD. AFAIK, the purpose of N>R and NR> was that Leon wanted to allow the feebs to do something creative and to succeed with an RfD, to prove that he is not such a hard-case as he may have appeared by killing my ALLOCATION RfD --- N>R and NR> served this purpose because they take about 5 minutes to implement in ANS-Forth, and they're useless --- so Leon gets to prove that he is tolerant of feebs, and simultaneously prove that everybody outside of Forth Inc. is in fact feeble-minded, which is a double-win for Forth Inc!
Just now I wrote N>R and NR> in ANS-Forth and timed myself --- it was less than 5 minutes. Here they are:
macro: n>r ( numbers... count -- )
begin ?dup while swap >r 1- repeat ;
macro: nr> ( count -- numbers... )
begin ?dup while r> swap 1- repeat ;
You need MACRO: from the novice package, but it is written in ANS-Forth too --- so this is trivial to implement in ANS-Forth --- whether or not I will include this in the next novice package release, I haven't decided, as this is somewhat below novice-level in terms of difficulty of implementation, and completely useless.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 17:53 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <v-CdnWH2MJ_I5tDJnZ2dnUVZ8hGdnZ2d@supernews.com> |
| In reply to | #34188 |
hughaguilar96@yahoo.com wrote: > > N>R and NR> were introduced immediately after Leon Wagner killed my > ALLOCATION RfD. Post hoc, ergo propter hoc. Must be true, then. > AFAIK, the purpose of N>R and NR> was that Leon wanted to allow the > feebs to do something creative and to succeed with an RfD, to prove > that he is not such a hard-case as he may have appeared by killing > my ALLOCATION RfD Your ALLOCATION RfD died because most people thought that it did not provide any new capability (because an application can provide the functionality trivially if it needs it) and that in some systems ALLOCATION would have a significant overhead. Anyone who wants to check this can read the discussion at https://groups.yahoo.com/neo/groups/forth200x/conversations/topics/448 Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-26 16:30 -0700 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <39623bd1-d499-41cb-9292-77801a81099e@googlegroups.com> |
| In reply to | #34191 |
On Sunday, October 26, 2014 3:53:10 PM UTC-7, Andrew Haley wrote: > Your ALLOCATION RfD died because most people thought that it did not > provide any new capability (because an application can provide the > functionality trivially if it needs it) and that in some systems > ALLOCATION would have a significant overhead. I implemented ALLOCATION in the novice package. Anybody can download this and see it. Some of my programs depend upon having ALLOCATION (it is used by CLONE-NODE that has to know how big the node is so it can make a copy, without knowing what type of data the node is). I wouldn't really describe ALLOCATION as being "trivial" --- that sounds like troll-talk to me --- on the other hand, N>R and NR> really are trivial; two lines of code that can be implemented and tested in 2 to 5 minutes, depending upon the typing speed of the programmer. ALLOCATION only has significant overhead (an extra cell in every allocated block to hold the size), because this data is redundant --- the heap is internally holding this data already, but not making it available to the programmer --- if my RfD had gone though, then there wouldn't have been any redundancy because the data already held would be made available to the programmer without requiring the programmer to hold onto that data himself. > Anyone who wants to check this can read the discussion at > https://groups.yahoo.com/neo/groups/forth200x/conversations/topics/448 What people will read in that discussion, is that I had support until Leon killed it, and then everybody began pretending that they had been against it all along, so that they wouldn't offend Leon. This is what Leon Wagner said: <quote> I don't support this feature and would likely not implement it. Other than the nice discussion of what to name it, I see no compelling reason for its actual use. ... For hosted systems that use the heap management of the underlying OS, the internal information is "under the hood" and not available to us. This means that each and every call to ALLOCATE would have allocate additional space, retain the size, and fudge the pointers returned by ALLOCATE and used by FREE. Now *that* does seem wasteful. </quote> His argument essentially is that he doesn't know how to implement a heap, so he is going to rely on GLIBC for their heap. Anton Ertl agrees, that Forth will forever be hanging on the coattails of C: <quote> This weaker guarantee allows a cheaper implementation of ALLOCATED in some cases (those cases where the internals of the implementation of ALLOCATE are available). But given that apparently most hosted Forth systems use the C library's malloc()/free()/realloc() for implementing ALLOCATE/FREE/RESIZE, and the C library does not provide an equivalent of ALLOCATED, I guess that most Forth systems won't implement ALLOCATED by accessing the internals, and therefore either won't implement ALLOCATED or will implement it in an expensive way (as ALLOCATION). </quote> The whole thing seems rather pathetic --- the Forth-200x committee has to ask the GLIBC implementers for permission to include useful and obvious features in the Forth-200x standard --- because nobody on the Forth-200x committee knows how to implement a heap.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-10-27 01:45 -0400 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <op.xodjlyksmk81un@localhost> |
| In reply to | #34194 |
On Sun, 26 Oct 2014 19:30:11 -0400, <hughaguilar96@yahoo.com> wrote: > On Sunday, October 26, 2014 3:53:10 PM UTC-7, Andrew Haley wrote: >> Your ALLOCATION RfD died because most people thought that it did not >> provide any new capability (because an application can provide the >> functionality trivially if it needs it) and that in some systems >> ALLOCATION would have a significant overhead. > > I implemented ALLOCATION in the novice package. Hugh, it's clear that you believe you are rational. So, at this point, it should be logical to you that you only have a few choices: 1) build momentum for it here and elsewhere by demonstrating it's usefulness in code you post 2) forget about it in it's entirety 3) continue to use it in your code but stop pushing it onto others 4) continue to use it in your code, continue whining, and continue pushing I'd like to move you away from choice #4 and onto #1, #2, or #3. I've mentioned this before, perhaps stated differently. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-27 12:21 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <YMidnQVZbLed4tPJnZ2dnUVZ8kmdnZ2d@supernews.com> |
| In reply to | #34194 |
hughaguilar96@yahoo.com wrote: > On Sunday, October 26, 2014 3:53:10 PM UTC-7, Andrew Haley wrote: >> Your ALLOCATION RfD died because most people thought that it did not >> provide any new capability (because an application can provide the >> functionality trivially if it needs it) and that in some systems >> ALLOCATION would have a significant overhead. > >> Anyone who wants to check this can read the discussion at >> https://groups.yahoo.com/neo/groups/forth200x/conversations/topics/448 > > What people will read in that discussion, is that I had support > until Leon killed it, and then everybody began pretending that they > had been against it all along, so that they wouldn't offend Leon. > > This is what Leon Wagner said: > > <quote> > I don't support this feature and would likely not implement > it. Other than the nice discussion of what to name it, I see no > compelling reason for its actual use. > ... > For hosted systems that use the heap management of the underlying > OS, the internal information is "under the hood" and not available > to us. This means that each and every call to ALLOCATE would have > allocate additional space, retain the size, and fudge the pointers > returned by ALLOCATE and used by FREE. Now *that* does seem > wasteful. > </quote> > > His argument essentially is that he doesn't know how to implement a > heap, so he is going to rely on GLIBC for their heap. Anton Ertl > agrees, that Forth will forever be hanging on the coattails of C: glibc's malloc is good, and in particular scales well on multi- threaded systems. Writing something equally performant in Forth would be pointless, especially if the only reason to do so is to support ALLOCATION . > The whole thing seems rather pathetic --- the Forth-200x committee > has to ask the GLIBC implementers for permission to include useful > and obvious features in the Forth-200x standard --- because nobody > on the Forth-200x committee knows how to implement a heap. That's really not the point. No Forth implementor should have to write their own heap code just because of ALLOCATION . Mitch Bradley, certainly no poodle of Leon's or anyone else, explained all this. Your proposal failed on purely technical grounds. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 17:57 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <v-CdnWD2MJ_u4dDJnZ2dnUVZ8hGdnZ2d@supernews.com> |
| In reply to | #34155 |
Marcel Hendrix <mhx@iae.nl> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes Re: uninitialized and implicitly initialized locals > [.. discussion I want no part in ..] >>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> N>R and NR> are not necessary, either, and I don't consider them nice >>> to have. Your reaction: "what's not to like?". > >> Indeed, and that was a judgement call. They are necessary IMO because >> of other parts of standard Forth. And they are standalone words which >> don't have the (IMO) dramatic effect on the language that locals do. >> (And I really needed them at the time for software transactional >> memory, so I knew for certain that they had uses beyond their initial >> motivation.) > [..] > > I am disgusted that N>R and NR> ever got in the standard. Your reason to > back them is not convincing (how many current systems allow transactional > memory, I missed this question. All of them, as far as I am aware; or at least all systems with support for multi-threading. > why do they need a standardized N>R and NR> to provide it, what > must-have features do N>R and NR> enable in a Standard Forth). Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2014-10-06 20:55 +0100 |
| Subject | Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <m0us48$7dk$1@dont-email.me> |
| In reply to | #33709 |
On 06/10/2014 01:09, hughaguilar96@yahoo.com wrote:
> On Saturday, October 4, 2014 9:14:07 PM UTC-7, hughag...@yahoo.com wrote:
>> ...I have written a work-around for the bug in VFX!
A couple of fairly minor comments.
>
> false value expected#
>
> : fill-localvars# ( -- )
> [ <get-context> to expected# ]
> 1 2 3 locals| x y z |
> [
> <get-context> expected# <> [if]
> <pop-context> to localvars#
> <get-context> expected# <> [if] .( *** FILL-LOCALVARS# can't find EXPECTED# ***) abort [then]
> localvars# <push-context> [then]
> ] ;
Presumably the above is only executed once so you could put a marker
round it and forget it e.g. (untested)
marker forget-this
<get-context> value expected#
: fill-localvars#
1 2 3 locals| a b c |
... etc ;
fill-localvars#
forget-this
etc
>
> wordlist constant test1#
> wordlist constant test2#
>
> : test ( -- ) \ this tests SET-CONTEXT
> [ cr .( TEST1# = ) test1# u. ]
> [ cr .( TEST2# = ) test2# u. ]
> [ cr .( FORTH-WORDLIST = ) forth-wordlist u. ]
> [ set-forth order ]
> [ get-context cr .( context = ) u. order ]
> [ forth-wordlist set-context order ]
> [ test1# set-context order ]
> 1 2 3 locals| x y z | [ order ]
> [ get-context cr .( context = ) u. order ]
> [ test1# push-context order ]
> [ drop-context order ]
> [ test1# set-context order ]
> [ test2# set-context order ]
> [ test1# push-context order ]
> [ drop-context order ]
> ;
>
This doesn't execute fill-localvars# and hence not all of <set-context>
--
Gerry
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web