Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #47362 > unrolled thread

How could have I factored this better?

Back to article view | Back to comp.lang.forth

Contents

  How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-20 13:09 -0700
    Re: How could have I factored this better? rickman <gnuarm@gmail.com> - 2016-05-20 16:18 -0400
      Re: How could have I factored this better? "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 10:25 -1000
        Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-20 13:39 -0700
      Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-20 21:33 -0400
    Re: How could have I factored this better? "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 10:23 -1000
    Re: How could have I factored this better? Paul Rubin <no.email@nospam.invalid> - 2016-05-20 15:44 -0700
      Re: How could have I factored this better? "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 14:38 -1000
        Re: How could have I factored this better? Paul Rubin <no.email@nospam.invalid> - 2016-05-20 17:49 -0700
          Re: How could have I factored this better? "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 14:57 -1000
            Re: How could have I factored this better? Paul Rubin <no.email@nospam.invalid> - 2016-05-20 18:34 -0700
              Re: How could have I factored this better? "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 16:00 -1000
                Re: How could have I factored this better? Paul Rubin <no.email@nospam.invalid> - 2016-05-20 20:08 -0700
                  Re: How could have I factored this better? "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 17:24 -1000
                  Re: How could have I factored this better? hughaguilar96@gmail.com - 2016-05-21 18:15 -0700
              Re: How could have I factored this better? Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-21 10:01 +0000
            Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-20 22:15 -0400
              Re: How could have I factored this better? "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 16:46 -1000
              Re: How could have I factored this better? hughaguilar96@gmail.com - 2016-05-21 18:36 -0700
                Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-21 22:51 -0400
                  Re: How could have I factored this better? hughaguilar96@gmail.com - 2016-05-21 22:23 -0700
        Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-20 22:43 -0400
      Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-20 22:19 -0400
    Re: How could have I factored this better? "WJ" <w_a_x_man@yahoo.com> - 2016-05-21 22:02 +0000
      Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-21 22:30 -0400
        Re: How could have I factored this better? humptydumpty <ouatubi@gmail.com> - 2016-05-21 19:40 -0700
    Re: How could have I factored this better? humptydumpty <ouatubi@gmail.com> - 2016-05-21 19:38 -0700
      Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-21 23:06 -0400
        Re: How could have I factored this better? Paul Rubin <no.email@nospam.invalid> - 2016-05-21 20:59 -0700
          Re: How could have I factored this better? Darin Murphy <murphy.darin@gmail.com> - 2016-05-22 03:30 -0400
            Re: How could have I factored this better? "Elizabeth D. Rather" <erather@forth.com> - 2016-05-21 23:14 -1000
    Re: How could have I factored this better? humptydumpty <ouatubi@gmail.com> - 2016-05-27 03:54 -0700

Page 1 of 2  [1] 2  Next page →

#47362 — How could have I factored this better?

Hi everybody. I created the following program and would like to know how I could have factored and documented it better.

: star  ( n -- ) 42 emit ;
: not-positive-integer   ." ERROR - Value not a positive integer!" ;
: positive-integer?  ( n -- error or n ) dup 1 < if not-positive-integer drop then ;
: stars  ( n -- ) positive-integer? begin dup 0 > while 1 - star repeat drop ;
: solid-box-stars   ( column row -- ) positive-integer? cr begin dup 0 > while >r dup stars r> 1 - cr repeat drop drop ;

Examples, suggestions and advice are welcomed as always. Take care now.

[toc] | [next] | [standalone]

#47363

On 5/20/2016 4:09 PM, Darin Murphy wrote:
> Hi everybody. I created the following program and would like to know how I could have factored and documented it better.
>
> : star  ( n -- ) 42 emit ;
> : not-positive-integer   ." ERROR - Value not a positive integer!" ;
> : positive-integer?  ( n -- error or n ) dup 1 < if not-positive-integer drop then ;
> : stars  ( n -- ) positive-integer? begin dup 0 > while 1 - star repeat drop ;
> : solid-box-stars   ( column row -- ) positive-integer? cr begin dup 0 > while >r dup stars r> 1 - cr repeat drop drop ;
>
> Examples, suggestions and advice are welcomed as always. Take care now.

I don't know about factoring, but positive-integer? either returns the 
value given, or returns nothing.  The latter will cause an error in 
stars won't it?  You neeed to use abort rather than drop or otherwise 
change the control flow.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#47365

On 5/20/16 10:18 AM, rickman wrote:
> On 5/20/2016 4:09 PM, Darin Murphy wrote:
>> Hi everybody. I created the following program and would like to know
>> how I could have factored and documented it better.
>>
>> : star  ( n -- ) 42 emit ;
>> : not-positive-integer   ." ERROR - Value not a positive integer!" ;
>> : positive-integer?  ( n -- error or n ) dup 1 < if
>> not-positive-integer drop then ;
>> : stars  ( n -- ) positive-integer? begin dup 0 > while 1 - star
>> repeat drop ;
>> : solid-box-stars   ( column row -- ) positive-integer? cr begin dup 0
>> > while >r dup stars r> 1 - cr repeat drop drop ;
>>
>> Examples, suggestions and advice are welcomed as always. Take care now.
>
> I don't know about factoring, but positive-integer? either returns the
> value given, or returns nothing.  The latter will cause an error in
> stars won't it?  You neeed to use abort rather than drop or otherwise
> change the control flow.

Better still, use ABORT" rather than a separate definition just to 
display the message.

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]

#47366

Thanks Mrs. Rather, I'll create it with "Do...Loops" and see how it looks. Also I'll look in to how to use "Abort" as well.
Take care now.

[toc] | [prev] | [next] | [standalone]

#47378

rickman <gnuarm@gmail.com> Wrote in message:
> On 5/20/2016 4:09 PM, Darin Murphy wrote:
>> Hi everybody. I created the following program and would like to know how I could have factored and documented it better.
>>
>> : star  ( n -- ) 42 emit ;
>> : not-positive-integer   ." ERROR - Value not a positive integer!" ;
>> : positive-integer?  ( n -- error or n ) dup 1 < if not-positive-integer drop then ;
>> : stars  ( n -- ) positive-integer? begin dup 0 > while 1 - star repeat drop ;
>> : solid-box-stars   ( column row -- ) positive-integer? cr begin dup 0 > while >r dup stars r> 1 - cr repeat drop drop ;
>>
>> Examples, suggestions and advice are welcomed as always. Take care now.
> 
> I don't know about factoring, but positive-integer? either returns the 
> value given, or returns nothing.  The latter will cause an error in 
> stars won't it?  You neeed to use abort rather than drop or otherwise 
> change the control flow.
> 
> -- 
> 
> Rick C
> 

Thanks Rick! Sorry I didn't see your message before Mrs. Rather's.
 I'll look into using "abort" again.

Take care now,
-- 
Darin Murphy


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#47364

On 5/20/16 10:09 AM, Darin Murphy wrote:
> Hi everybody. I created the following program and would like to know how I could have factored and documented it better.
>
> : star  ( n -- ) 42 emit ;
> : not-positive-integer   ." ERROR - Value not a positive integer!" ;
> : positive-integer?  ( n -- error or n ) dup 1 < if not-positive-integer drop then ;
> : stars  ( n -- ) positive-integer? begin dup 0 > while 1 - star repeat drop ;
> : solid-box-stars   ( column row -- ) positive-integer? cr begin dup 0 > while >r dup stars r> 1 - cr repeat drop drop ;
>
> Examples, suggestions and advice are welcomed as always. Take care now.

My first suggestion is to re-write it using DO ... LOOP (or one of its 
variants). Compare the two and see which you like better. Usually when 
you know how many times you want to do something it's cleaner to use 
finite loops (DO ... ) rather than indefinite loops. Indefinite loops 
are most valuable when you want to keep doing something as long as a 
situation exists, or until something happens.

Your definition of star would be more readable if you use CHAR * or ." 
*" rather than 42 emit.

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]

#47370

Darin Murphy <murphy.darin@gmail.com> writes:
> Hi everybody. I created the following program and would like to know
> how I could have factored and documented it better.

Here's my version, which possibly uses some gforth words:

    : checkneg ( n -- ) 0 < abort" need a non-negative integer" ;
    : star  ( -- ) '*' emit ;
    : stars ( n -- ) dup checkneg 0 ?do star loop ;
    : solid-box-stars { cols rows } cr
        cols checkneg
        rows checkneg
        rows 0 ?do
            cols stars cr
        loop ;


Differences from yours:

1. The stack comment in your STAR word is ( n -- ) but should be ( -- )
2. I used ABORT to break out of the error check since the number
   is invalid and there's no way to continue.  In a bigger program
   you might want to catch the error with CATCH.
3. I checked for < 0 instead of < 1, since it seems perfectly ok to
   me to print zero stars without it being an error.  That meant 
   changing the loops to ?DO.  The repeat/while stuff was clumsy.
4. I used gforth locals for the args to solid-box-stars.  Maybe
   that's controversial but it avoids some stack juggling, assuming
   you want the interface to stay what you wrote.

[toc] | [prev] | [next] | [standalone]

#47375

On 5/20/16 12:44 PM, Paul Rubin wrote:
> Darin Murphy <murphy.darin@gmail.com> writes:
>> Hi everybody. I created the following program and would like to know
>> how I could have factored and documented it better.
>
> Here's my version, which possibly uses some gforth words:
>
>     : checkneg ( n -- ) 0 < abort" need a non-negative integer" ;
>     : star  ( -- ) '*' emit ;
>     : stars ( n -- ) dup checkneg 0 ?do star loop ;
>     : solid-box-stars { cols rows } cr
>         cols checkneg
>         rows checkneg
>         rows 0 ?do
>             cols stars cr
>         loop ;
>
>
> Differences from yours:
>
> 1. The stack comment in your STAR word is ( n -- ) but should be ( -- )
> 2. I used ABORT to break out of the error check since the number
>    is invalid and there's no way to continue.  In a bigger program
>    you might want to catch the error with CATCH.
> 3. I checked for < 0 instead of < 1, since it seems perfectly ok to
>    me to print zero stars without it being an error.  That meant
>    changing the loops to ?DO.  The repeat/while stuff was clumsy.
> 4. I used gforth locals for the args to solid-box-stars.  Maybe
>    that's controversial but it avoids some stack juggling, assuming
>    you want the interface to stay what you wrote.
>

I don't see that the locals contributed anything. In fact, this is 
shorter, and avoids the need for code to manage the locals frame.

     : checkneg ( n -- ) 0 < abort" need a non-negative integer" ;
     : star  ( -- ) '*' emit ;
     : stars ( n -- ) dup checkneg 0 ?do star loop ;
     : solid-box-stars ( cols rows ) cr
         dup checkneg 0 ?do
             dup stars cr
         loop drop ;

In a real-world application, you should know where your arguments are 
coming from, and whether it's possible that one may be illegal. Often 
they're not; for example, if the boundaries of your box are specified in 
variables somewhere, the appropriate place to check would be where the 
variables are filled; thereafter, you know you have legal parameters.

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]

#47376

"Elizabeth D. Rather" <erather@forth.com> writes:
> I don't see that the locals contributed anything. In fact, this is
> shorter, and avoids the need for code to manage the locals frame.

I'm not sure what you mean about "code to manage the locals frame" but
yeah, your version of solid-box-stars should work ok.  I'd take a little
issue with it only checking one of the args, since as you say, inputs
should be checked when they are supplied in the first place.  Therefore,
those checks have the nature of assertions, that signal that something
has gone expectedly wrong.  Checking just one of the args on the
observation that the other one is checked in another place in the code
is sort of ok since the other place is just 2 lines away.  But in
general, we put assertions in code because experience tells us that our
observations and reasoning aren't always reliable.  So if both of those
words have preconditions and we're into checking such things, it seems
ok to me to check in both places.

[toc] | [prev] | [next] | [standalone]

#47377

On 5/20/16 2:49 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> I don't see that the locals contributed anything. In fact, this is
>> shorter, and avoids the need for code to manage the locals frame.

When you declare locals, a locals fram

> I'm not sure what you mean about "code to manage the locals frame" but
> yeah, your version of solid-box-stars should work ok.  I'd take a little
> issue with it only checking one of the args, since as you say, inputs
> should be checked when they are supplied in the first place.  Therefore,
> those checks have the nature of assertions, that signal that something
> has gone expectedly wrong.  Checking just one of the args on the
> observation that the other one is checked in another place in the code
> is sort of ok since the other place is just 2 lines away.  But in
> general, we put assertions in code because experience tells us that our
> observations and reasoning aren't always reliable.  So if both of those
> words have preconditions and we're into checking such things, it seems
> ok to me to check in both places.

To me, the question of whether to check the row length in stars or 
solid-box-stars depends on whether stars might be called from somewhere 
else. If it's only used by solid-box-stars, I agree, both args should be 
checked there. There's no point in checking twice, but there's no 
guarantee that you mightn't find a use for stars elsewhere. In other 
words, these decisions should be made in the context of the application 
design, although that's hard to do with these little examples.

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]

#47379

"Elizabeth D. Rather" <erather@forth.com> writes:
>>> shorter, and avoids the need for code to manage the locals frame.
> When you declare locals, a locals fram

Do you mean extra code generated by the compiler?  In this particular
case the locals could go in registers, but either way I don't see a big
deal unless we're short of code space or something.

> To me, the question of whether to check the row length in stars or
> solid-box-stars depends on whether stars might be called from
> somewhere else.

Reasonable enough.  In this case stars appeared intended as a directly
usable word rather than a factor of solid-box-stars.  But my impression
is that Forth programs tend to not use anything except possibly naming
conventions to prevent words from being globally usable.

[toc] | [prev] | [next] | [standalone]

#47380

On 5/20/16 3:34 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>>> shorter, and avoids the need for code to manage the locals frame.
>> When you declare locals, a locals fram
>
> Do you mean extra code generated by the compiler?  In this particular
> case the locals could go in registers, but either way I don't see a big
> deal unless we're short of code space or something.

I don't know how the gForth compiler handles locals. You might look a 
the compiled code both ways and compare. But usually there's some setup 
involved. I avoid locals unless there's a significant advantage to be 
gained.

>> To me, the question of whether to check the row length in stars or
>> solid-box-stars depends on whether stars might be called from
>> somewhere else.
>
> Reasonable enough.  In this case stars appeared intended as a directly
> usable word rather than a factor of solid-box-stars.  But my impression
> is that Forth programs tend to not use anything except possibly naming
> conventions to prevent words from being globally usable.

That's right. Reusability is a good thing. If you're a solo programmer, 
you should be able to manage your programs. If you're in a team, the 
team should be able to communicate: "hey, do any of you have a word that 
does this thing?" If so, you LOCATE it and have a look.

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]

#47387

"Elizabeth D. Rather" <erather@forth.com> writes:
> I don't know how the gForth compiler handles locals.

It's an interpreter and it uses a locals stack, so there's a bit of
overhead to what I did.

>> Forth programs tend to not use anything except possibly naming
>> conventions to prevent words from being globally usable.
> That's right. Reusability is a good thing. If you're a solo
> programmer, you should be able to manage your programs....

Sure.  Part of managing programs is being able to change the interface
to a word and quickly find all the places that call it so you can fix
the calls, and be sure that you can't have missed any.  One way to do
that is limit the word's visibility so that it can only be called from a
specific part of the program.  Of course can still use the word
somewhere else if you decide to.  You just have to update the visibility
(export the word from a module or whatever) first.  Forth lets you do
this with word lists.

[toc] | [prev] | [next] | [standalone]

#47390

On 5/20/16 5:08 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> I don't know how the gForth compiler handles locals.
>
> It's an interpreter and it uses a locals stack, so there's a bit of
> overhead to what I did.
>
>>> Forth programs tend to not use anything except possibly naming
>>> conventions to prevent words from being globally usable.
>> That's right. Reusability is a good thing. If you're a solo
>> programmer, you should be able to manage your programs....
>
> Sure.  Part of managing programs is being able to change the interface
> to a word and quickly find all the places that call it so you can fix
> the calls, and be sure that you can't have missed any.  One way to do
> that is limit the word's visibility so that it can only be called from a
> specific part of the program.  Of course can still use the word
> somewhere else if you decide to.  You just have to update the visibility
> (export the word from a module or whatever) first.  Forth lets you do
> this with word lists.
>
True.

-- 
==================================================
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]

#47412

On Friday, May 20, 2016 at 8:08:12 PM UTC-7, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
> > I don't know how the gForth compiler handles locals.
> 
> It's an interpreter and it uses a locals stack, so there's a bit of
> overhead to what I did.
> 
> >> Forth programs tend to not use anything except possibly naming
> >> conventions to prevent words from being globally usable.
> > That's right. Reusability is a good thing. If you're a solo
> > programmer, you should be able to manage your programs....
> 
> Sure.  Part of managing programs is being able to change the interface
> to a word and quickly find all the places that call it so you can fix
> the calls, and be sure that you can't have missed any.  One way to do
> that is limit the word's visibility so that it can only be called from a
> specific part of the program.  Of course can still use the word
> somewhere else if you decide to.  You just have to update the visibility
> (export the word from a module or whatever) first.  Forth lets you do
> this with word lists.

I don't think word-lists are useful for this.

In MFX I had defined a new flag in the header similar to the smudge-flag except that it was a smudge-ready flag. The word LOCAL set this flag. The word END-MODULE traversed the dictionary and set the smudge-flag in every word with the smudge-ready flag set, and also unset the smudge-ready flag for that word (so it wouldn't be found by END-MODULE again). So, all the LOCAL words in the module were local to the module and not visible outside of the module.

My language will allow the programmer to examine an xt and determine various attributes of the word (which word-list it was defined in, immediate or not, smudge-flag set or not, smudge-ready flag set or not), and also to change these attributes --- this is trivial to implement --- this is also necessary for a cross-compiler (although LOCAL and END-MODULE are useful in any large program).

[toc] | [prev] | [next] | [standalone]

#47404

On 2016-05-21, Paul Rubin <no.email@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>>> shorter, and avoids the need for code to manage the locals frame.
>> When you declare locals, a locals fram
>
> Do you mean extra code generated by the compiler?  In this particular
> case the locals could go in registers, but either way I don't see a big
> deal unless we're short of code space or something.
>
>> To me, the question of whether to check the row length in stars or
>> solid-box-stars depends on whether stars might be called from
>> somewhere else.
>
> Reasonable enough.  In this case stars appeared intended as a directly
> usable word rather than a factor of solid-box-stars.  But my impression
> is that Forth programs tend to not use anything except possibly naming
> conventions to prevent words from being globally usable.

Forth has wordlist, which represent namespaces. (Actually ciforth has
NAMESPACE that gives a name to a wordlist.) They are being used in
larger programs. The use to separate the words from an assembler
is very common.

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]

#47381

"Elizabeth D. Rather" <erather@forth.com> Wrote in message:
> On 5/20/16 2:49 PM, Paul Rubin wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> I don't see that the locals contributed anything. In fact, this is
>>> shorter, and avoids the need for code to manage the locals frame.
> 
> When you declare locals, a locals fram
> 
>> I'm not sure what you mean about "code to manage the locals frame" but
>> yeah, your version of solid-box-stars should work ok.  I'd take a little
>> issue with it only checking one of the args, since as you say, inputs
>> should be checked when they are supplied in the first place.  Therefore,
>> those checks have the nature of assertions, that signal that something
>> has gone expectedly wrong.  Checking just one of the args on the
>> observation that the other one is checked in another place in the code
>> is sort of ok since the other place is just 2 lines away.  But in
>> general, we put assertions in code because experience tells us that our
>> observations and reasoning aren't always reliable.  So if both of those
>> words have preconditions and we're into checking such things, it seems
>> ok to me to check in both places.
> 
> To me, the question of whether to check the row length in stars or 
> solid-box-stars depends on whether stars might be called from somewhere 
> else. If it's only used by solid-box-stars, I agree, both args should be 
> checked there. There's no point in checking twice, but there's no 
> guarantee that you mightn't find a use for stars elsewhere. In other 
> words, these decisions should be made in the context of the application 
> design, although that's hard to do with these little examples.
> 
> 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."
> ==================================================
> 

Okay. Here's my factored version, using the suggests given:

: star  ( -- ) ." *" ;
: stars  ( n -- ) dup 1 < abort" value not a positive integer!" 0
 do star loop ;
: solid-box-stars ( column row -- ) dup 1 < abort" value not a
 positive integer!" 0 do dup cr stars loop drop ;

The reason I did 1 < because the problem in the book asked for a
 box of stars and 0 in either place wouldn't create a box shape of
 anything. For documentation purposes I should have broken up
 solid-box-stars to look like this?

: solid-box-stars ( column row -- ) dup 1 < abort" value not a
 positive integer!" 
                                                                  
       0 do dup cr stars loop drop ;

Just trying to learn good documentation and factoring as early as
 possible, so they will become habits by the time I start working
 on larger programs.  Thanks again for all of the suggestions and
 advice.

Take care now,
-- 
Darin Murphy


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#47386

On 5/20/16 4:15 PM, Darin Murphy wrote:
> "Elizabeth D. Rather" <erather@forth.com> Wrote in message:
>> On 5/20/16 2:49 PM, Paul Rubin wrote:
>>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>>> I don't see that the locals contributed anything. In fact, this is
>>>> shorter, and avoids the need for code to manage the locals frame.
>>
>> When you declare locals, a locals fram
>>
>>> I'm not sure what you mean about "code to manage the locals frame" but
>>> yeah, your version of solid-box-stars should work ok.  I'd take a little
>>> issue with it only checking one of the args, since as you say, inputs
>>> should be checked when they are supplied in the first place.  Therefore,
>>> those checks have the nature of assertions, that signal that something
>>> has gone expectedly wrong.  Checking just one of the args on the
>>> observation that the other one is checked in another place in the code
>>> is sort of ok since the other place is just 2 lines away.  But in
>>> general, we put assertions in code because experience tells us that our
>>> observations and reasoning aren't always reliable.  So if both of those
>>> words have preconditions and we're into checking such things, it seems
>>> ok to me to check in both places.
>>
>> To me, the question of whether to check the row length in stars or
>> solid-box-stars depends on whether stars might be called from somewhere
>> else. If it's only used by solid-box-stars, I agree, both args should be
>> checked there. There's no point in checking twice, but there's no
>> guarantee that you mightn't find a use for stars elsewhere. In other
>> words, these decisions should be made in the context of the application
>> design, although that's hard to do with these little examples.
>>
>> 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."
>> ==================================================
>>
>
> Okay. Here's my factored version, using the suggests given:
>
> : star  ( -- ) ." *" ;
> : stars  ( n -- ) dup 1 < abort" value not a positive integer!" 0
>  do star loop ;
> : solid-box-stars ( column row -- ) dup 1 < abort" value not a
>  positive integer!" 0 do dup cr stars loop drop ;
>
> The reason I did 1 < because the problem in the book asked for a
>  box of stars and 0 in either place wouldn't create a box shape of
>  anything.

It's worse than that: 0 would have caused a runaway loop from 0 to 0 
through the entire range of 32 or 64 bit numbers! That is why Paul used 
?DO (which checks for that problem). It's really your option, whether to 
include 0 in the range check or use ?DO. You don't need to do both.

> For documentation purposes I should have broken up
>  solid-box-stars to look like this?
>
> : solid-box-stars ( column row -- ) dup 1 < abort" value not a
>  positive integer!"
>
>        0 do dup cr stars loop drop ;

Well, I don't care for the error message breaking over a line or the 
blank line before 0 do, but I do like starting definitions at the left 
margin and indenting subsequent lines. These stylistic issues are an 
individual thing, but one should find a style you like and follow it 
consistently. A programming shop should have a shop-wide set of 
guidelines that all the programmers follow; this makes it much easier to 
share code, because everyone's style is about the same. FORTH, Inc. 
publishes its style guidelines in all its manuals. You'll see one in the 
back of Application Techniques.

> Just trying to learn good documentation and factoring as early as
>  possible, so they will become habits by the time I start working
>  on larger programs.  Thanks again for all of the suggestions and
>  advice.

A good plan. You're off to a great start!

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]

#47413

On Friday, May 20, 2016 at 7:15:57 PM UTC-7, Darin Murphy wrote:
> Just trying to learn good documentation and factoring as early as
>  possible, so they will become habits by the time I start working
>  on larger programs.  

You should not factor just for the sake of factoring, or because you expect somebody on c.l.f. to say: "Good job on factoring!"

You should factor because it helps you to debug your programs. Factor out a piece of code because it does one thing and this can be tested easily for correctness. Test it to make sure it works. Now if your higher-level code is not working, you know that the bug is not in this low-level function (because you've already tested it) and hence the bug must be int eh high-level function (hopefully it is short enough that you can spot the bug) --- what you want to avoid is the situation where you have a big function (I've seen C functions that were 100 lines long!) and it doesn't work, and you have no idea where the bug is --- C programmers will single-step through their mondo-function repeatedly until they find the bug, but this is tedious and time-consuming.

You should really get going on a non-trivial program --- I think that you are ready --- you aren't learning much from these tiny trivial programs; you'll just get bored because they aren't interesting (it is not that big of a thrill to make a box of asterisks on the screen). Think of something that is interesting to you and try it; your first program may have a lot of flaws, but if it works then you can feel proud, and your second effort will have fewer flaws. My first-ever non-trivial Forth program (when I was 18) was a master-key system for Kwikset locks --- I wrote this on the Commodore Vic-20 in HES-Forth --- you could try that one.

[toc] | [prev] | [next] | [standalone]

#47418

hughaguilar96@gmail.com Wrote in message:
> On Friday, May 20, 2016 at 7:15:57 PM UTC-7, Darin Murphy wrote:
>> Just trying to learn good documentation and factoring as early as
>>  possible, so they will become habits by the time I start working
>>  on larger programs.  
> 
> You should not factor just for the sake of factoring, or because you expect somebody on c.l.f. to say: "Good job on factoring!"

Thank you Hugh for first explaining your view on "factoring" and I
 agree that these little programs probably don't need factoring. 
 I am trying to understand what factoring is, when factoring is
 needed and most of all how to factor, in regards to computer
 programs and forth specifically.  Also I wouldn't expect any one
 to compliment me on factoring such a small program. Only to point
 out what I am doing incorrectly and give me some suggestions or
 examples.
 
 
> You should really get going on a non-trivial program --- I think that you are ready --- you aren't learning much from these tiny trivial programs;

Thank you also for your belief that I've grown enough to work on
 something non-trivial, but I feel that I still need more time
 working with the small programs before moving on to something
 less trivial.  Now your suggestion for me to move to something
 non-trivial does lead me to a post I was going to do on asking
 what everyone thought was what defines a program as a
 non-trivial.  I am guessing from my limited experience that it is
 a program that takes many small trivial snippets or functions and
 connects them together to form a more complicated program or
 function.  What do you think?  Anyway, Hugh thanks again for
 giving me your observations and guidance.

Take care now, 
-- 
Darin Murphy


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web