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

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

Best teaching methodology for Forths?

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

Contents

  Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:16 +0200
    Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-03 23:21 -0800
      Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-04 12:37 -0800
    Re: Best teaching methodology for Forths? november.nihal@gmail.com - 2016-03-04 03:25 -0800
      Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-04 14:30 +0200
        Re: Best teaching methodology for Forths? november.nihal@gmail.com - 2016-03-04 07:36 -0800
          Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-04 19:09 +0000
          Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:53 +0200
        Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-04 11:11 -0800
          Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:54 +0200
            Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 13:59 -0500
              Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:56 +0000
                Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 17:16 -0800
                  Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 20:54 -0500
                    Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 18:25 -0800
                      Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-09 18:26 -0800
                        Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-10 23:09 -0800
                          Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-11 03:39 -0800
                            Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-12 17:57 -0800
                              Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-13 08:25 -0700
                                Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-13 11:30 -0700
                                Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-13 14:06 -0700
              Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-07 16:28 -0800
                Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-07 19:39 -0500
                  Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 22:13 +0000
                    Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-09 01:18 +0000
                      Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-08 20:41 -0500
                        Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-10 22:33 -0800
                          Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-10 23:17 -0800
                          Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-13 14:41 -0700
                            Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-13 17:26 -0700
                              Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-13 21:46 -1000
                                Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 08:12 -0700
                                Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-14 17:45 +0000
                                  Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-14 14:11 -1000
                                    Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-15 01:13 -0700
                              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 08:55 -0700
                                Re: Best teaching methodology for Forths? Julian Fondren <ayrnieu@gmail.com> - 2016-03-15 03:16 -0700
                              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-16 16:13 -0700
                            Re: Best teaching methodology for Forths? "WJ" <w_a_x_man@yahoo.com> - 2016-03-26 22:11 +0000
                            Re: Best teaching methodology for Forths? "WJ" <w_a_x_man@yahoo.com> - 2016-03-26 22:15 +0000
    Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-04 12:42 -0500
      Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-04 19:16 +0000
        Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-04 15:22 -0500
        Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:58 +0200
          Re: Best teaching methodology for Forths? "HAA" <someone@microsoft.com> - 2016-03-09 10:07 +1100
    Re: Best teaching methodology for Forths? IanYellowley <iany99@gmail.com> - 2016-03-04 13:57 -0800
      Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-04 15:07 -0800
        Re: Best teaching methodology for Forths? stephen@mpeforth.com (Stephen Pelc) - 2016-03-05 11:22 +0000
          Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 15:10 -0800
            Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:05 +0000
              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 17:06 -0800
              Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 20:58 -0500
              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 11:10 -0700
          Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 15:23 -0800
            Re: Best teaching methodology for Forths? stephen@mpeforth.com (Stephen Pelc) - 2016-03-06 09:28 +0000
              Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-06 13:45 -0800
      Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:59 +0200
    Re: Best teaching methodology for Forths? Whammo <sidciavic@gmail.com> - 2016-03-08 19:47 -0800
    Re: Best teaching methodology for Forths? Brad Eckert <hwfwguy@gmail.com> - 2016-03-23 16:19 -0700
      Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-24 07:29 +0200
      Re: Best teaching methodology for Forths? Richard Owlett <rowlett@cloud85.net> - 2016-03-24 04:44 -0500
      Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-24 12:47 +0000
        Re: Best teaching methodology for Forths? Paul Rubin <no.email@nospam.invalid> - 2016-03-24 10:19 -0700
          Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-25 00:54 +0000
            Re: Best teaching methodology for Forths? Paul Rubin <no.email@nospam.invalid> - 2016-03-24 19:24 -0700
              Re: Best teaching methodology for Forths? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-25 11:38 +0000
                Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-25 12:42 +0000
                  Re: Best teaching methodology for Forths? Doug Hoffman <glidedog@gmail.com> - 2016-03-25 09:07 -0400
                  Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-25 07:54 -0700
                  Re: Best teaching methodology for Forths? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-25 14:29 +0000
                  Re: Best teaching methodology for Forths? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-25 21:17 +0000
                    Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-26 00:43 +0000
                      Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-26 12:06 +0000

Page 4 of 4 — ← Prev page 1 2 3 [4]

#46186

Thanks!

On 24/03/2016 01:19, Brad Eckert wrote:
> On Thursday, March 3, 2016 at 10:17:01 PM UTC-7, Ron Aaron wrote:
>> My question: what is the best way to teach people with disparate
>> backgrounds how to program effectively in a Forth-type language?
>>
> 
> Change the perception of what a programming language is and what it should do. Forth is a language for building languages. You should end up with a Forth-flavored language that fits the application domain.
> 
> The lexicon of words you build is there to:
> 1. Minimize information entropy, Shannon's famous H.
> 2. Debug the programmer.
> 3. Debug the program.
> 
> Experienced programmers have to develop new habits. Not only should you keep functions to less than a page, you should keep them to between 7 and 15 words. This isn't a strict rule, but it has been shown to work well. It goes well with:
> 
> A. Keep it simple.
> 
> B. Test as you go. This is the best way to debug the programmer, since programmers are notoriously buggy.
> 
> C. Crash early and crash often. Like B, but with the humility to actively look for flaws in your reasoning (by getting your hands dirty) instead of assuming you've already thought of the best approach and coded it with minimal bugs.
> 

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

#46189

On 3/23/2016 6:19 PM, Brad Eckert wrote:
> On Thursday, March 3, 2016 at 10:17:01 PM UTC-7, Ron Aaron wrote:
>> My question: what is the best way to teach people with disparate
>> backgrounds how to program effectively in a Forth-type language?
>>
>
> Change the perception of what a programming language is and what it should do. Forth is a language for building languages. You should end up with a Forth-flavored language that fits the application domain.
>
> The lexicon of words you build is there to:
> 1. Minimize information entropy, Shannon's famous H.
> 2. Debug the programmer.
> 3. Debug the program.
>
> Experienced programmers have to develop new habits. Not only should you keep functions to less than a page, you should keep them to between 7 and 15 words. This isn't a strict rule, but it has been shown to work well. It goes well with:
>
> A. Keep it simple.
>
> B. Test as you go. This is the best way to debug the programmer, since programmers are notoriously buggy.
>
> C. Crash early and crash often. Like B, but with the humility to actively look for flaws in your reasoning (by getting your hands dirty) instead of assuming you've already thought of the best approach and coded it with minimal bugs.
>

Isn't that how any language should be taught?
I'm teaching myself Tcl/Tk and I'm following that path and 
finding it fascinating.
I've been exposed to [if even not writing] Forth since the Byte 
issue on Forth.

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

#46191

Brad Eckert <hwfwguy@gmail.com> writes:

>On Thursday, March 3, 2016 at 10:17:01 PM UTC-7, Ron Aaron wrote:
>> My question: what is the best way to teach people with disparate
>> backgrounds how to program effectively in a Forth-type language?
>>

>Change the perception of what a programming language is and what it should do. Forth is a language for building languages. You should end up with a Forth-flavored language that fits the application domain.

>The lexicon of words you build is there to:
>1. Minimize information entropy, Shannon's famous H.
>2. Debug the programmer.
>3. Debug the program.

>Experienced programmers have to develop new habits. Not only should
  you keep functions to less than a page, you should keep them to
  between 7 and 15 words. This isn't a strict rule, but it has been
  shown to work well. It goes well with:

I've known this for an incredibly long time. Yet, I've just recently
introduced the REGRESS word. Now while I build a program even
the simplest of words get a REGRESS check. This style:

100,000,000,000,000 CONSTANT SIZE
REGRESS 1000 CONSTANT SIZE S:

VARIABLE buffer
: init   HERE SIZE ALLOT buffer ! ;
REGRESS init S:

If I normally load this, all regress words are executed and on
the first test that fails, the INCLUDE throws an exception.
Also note that the regression is executed with a much smaller
SIZE. (The problem with test-as-you-go is of course that
it requires a lot of discipline to test init routinely when you
replace ALLOT by an ALLOCATE. )

After just 2 month this has become indispensable to the point
that I can't program without it any more.

(A compilation with -c executes NO-REGRESS, making al these
words into comments.)

There is a disadvantage, the source looks ugly. OTOH the
test cases serve as a documentation.

>A. Keep it simple.

I really do this. The REGRESS facility takes one screen and
the mechanism to switch it on and off another one.

>B. Test as you go. This is the best way to debug the programmer,
  since programmers are notoriously buggy.

Make a definition and a REGRESS. If the regress fails, you just can't
continue. (i.e. test as you go)

>C. Crash early and crash often. Like B, but with the humility to
  actively look for flaws in your reasoning (by getting your hands
  dirty) instead of assuming you've already thought of the best
  approach and coded it with minimal bugs.
(Please trim your lines, this is usenet with Google as a guest
not the other way around.)

Make a definition and a REGRESS. If the regress fails, you just can't
continue. (i.e. crash early)

If there seems to be something wrong after a change, I DO-REGRESS
instead of NO-REGRESS. What is pleasant that if it passes, it is
really reassuring, and if it aborts you know which word fails.
[Most Forth's have an edit-where-the-error-was facility knowadays.]

You can steal REGRESS from ciforth 5.3.1 (site in my sig).

Groetjes Albert

P.S. Using it feels totally different from the famous Hopkins
test method. Experience it.
-- 
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]

#46197

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> 100,000,000,000,000 CONSTANT SIZE
> REGRESS 1000 CONSTANT SIZE S:

What does REGRESS do?  Rewind HERE back to before the previous
definition?  And what is S: ?

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

#46200

Paul Rubin <no.email@nospam.invalid> writes:

>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>> 100,000,000,000,000 CONSTANT SIZE
>> REGRESS 1000 CONSTANT SIZE S:

>What does REGRESS do?  Rewind HERE back to before the previous
>definition?  And what is S: ?

Basically REGRESS does the interpret action of \ (nice speak)
when your application is finished.

Under development the part between REGRESS and S: is executed,
then the part between S: and the end of the line.
If the stack results are different, an exception is thrown.
In the above code you also get a "SIZE redefined" message.

In Hopkins system it would be
{ 1000 CONSTANT SIZE -> }

or
{ 0 INVERT 1 AND -> 1 }
versus
REGRESS 0 INVERT 1 AND S: 1

I hesitate to publish the code for REGRESS a second time,
as it is a mere exercise for the reader, but it is
short enough.

LOCATE REGRESS
SCR # 174
0 ( REGRESS )                                     \ AvdH B5dec5
1 : ?.S?   DUP IF >R .S R> THEN ; \ (e-e) If ERROR, print stack.
2 : unbalance?  \ ( A B C - A B C ) give error if "A-B <> B-C "
3     2DUP - >R   >R 2DUP - R> SWAP    R> <>   ?.S? 40 ?ERROR ;
4 \ For A B C give error if [A,B) and [B,C) are different.
5 : unequal?     OVER - CORA   ?.S? 41 ?ERROR ;
6 \ (sc - sc) If not a plausible string, give error.
7 : ?test-for-S:?  OVER SRC 2@ SWAP WITHIN 0= 42 ?ERROR ;
8 \ Break off the evaluation, leave REMAINDER of parse area
9 : S:   SRC CELL+ 2@ OVER - RDROP ;
10 \ Insert this to show the text of a test that passed.
11 : _RVERBOSE LATEST ID. WHERE 2@ TYPE "\ PASSED" TYPE CR ;
12 \ Used as: REGRESS <test> S: <result>
13 : REGRESS    DSP@ >R   ^J PARSE  2DUP WHERE 2!   EVALUATE
14    DSP@ 2 CELLS + >R   ?test-for-S:? EVALUATE DSP@ R> R@
15    unbalance? unequal? _RVERBOSE R> DSP! ;

It is very carnal with DSP@ as the place of the stack, etc.
which is fully justified for a system word like this.
The most interesting part for reimplementors is the comment.

Note that REGRESS interprets the reset of the line using
EVALUATE and within that S: breaks off the evaluation,
but passes the as yet unevaluated part to REGRESS.
Then REGRESS evaluates that second part.
The stack is checked using three markers and my general
purpose CORA (compare memory area's).

It is terse but it is hardly less woc than the John Hopkins
code.

REGRESS either fails, or returns the stack in the exact state
it was before (barring malicious intent). This makes it usable
interspersed with source code.

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]

#46201

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> Basically REGRESS does the interpret action of \ (nice speak)
> when your application is finished.
> Under development the part between REGRESS and S: is executed,
> then the part between S: and the end of the line.
> If the stack results are different, an exception is thrown.

I see, it's for in-line unit testing.  Nice.  I'm not familiar with the
Hopkins system but sometimes use the gforth assert( word, or just write
some testing words and leave them in the program to be run during test
runs (or during all runs, if they don't break things).

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

#46203

Paul Rubin <no.email@nospam.invalid> writes:
> I'm not familiar with the
>Hopkins system

I guess he means the Hayes tester (and John Hayes worked at Johns
Hopkins University).  A typical test looks like this:

{ 1 2 + -> 3 }

The idea to have these inline and disableable is interesting.  I have
no idea why Albert van der Horst had to invent a new syntax for that.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#46204

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>Paul Rubin <no.email@nospam.invalid> writes:
>> I'm not familiar with the
>>Hopkins system

>I guess he means the Hayes tester (and John Hayes worked at Johns
>Hopkins University).  A typical test looks like this:

>{ 1 2 + -> 3 }

>The idea to have these inline and disableable is interesting.  I have
>no idea why Albert van der Horst had to invent a new syntax for that.

Because words like { and } are severely overloaded?

Plus:
{ } do not stand out, at all. I don't like that.
The endsentinel costs extra code and tokens, especially
to make it disablable.

The obligation to have all on one line makes it possible to
filter out with `` grep -v REGRESS '' and prevent idiots to
write page long tests.

Maybe
    REGRESS ... S: ....
could be formulated
    ASSERT: .... === ...
(assuming the triple = is not claimed yet.)

That makes no difference to the idea.
(The formulation as an assert is similar to Python.)

There is a difference with Hopkins regards purpose:
  Hopkins : find errors in systems
  REGRESS : prevent wrong application code to be loaded.

Another difference :
  Hopkins is not reentrant as it uses some global data
  One less special word.

>- anton

P.S.
Maybe assert is a better stem for this idea than regress.
I'll think about it.
-- 
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]

#46205

On 3/25/16 8:42 AM, Albert van der Horst wrote:

> { } do not stand out, at all. I don't like that.

I have my editor set to make these black-bold. They stand out nicely.

-Doug

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

#46206

On Friday, March 25, 2016 at 6:49:24 AM UTC-5, Anton Ertl wrote:
> 
> { 1 2 + -> 3 }
> 
> The idea to have these inline and disableable is interesting.  I have
> no idea why Albert van der Horst had to invent a new syntax for that.
> 

On Friday, March 25, 2016 at 7:42:41 AM UTC-5, Albert van der Horst wrote:
> 
> Plus:
> { } do not stand out, at all. I don't like that.
>

On Friday, March 25, 2016 at 8:08:00 AM UTC-5, Doug Hoffman wrote:
> 
> I have my editor set to make these black-bold. They stand out nicely.

The Hayes test code with { } would look like this:

  \ Repeat in Hex mode
  16 OLD-DBASE ! 16 BASE !
  { #12346789. -> BC65A5. }
  { #-12346789. -> -BC65A5. }
  { $12aBcDeF. -> 12AbCdeF. }
  { $-12AbCdEf. -> -12ABCDef. }
  { %10010110. -> 96. }
  { %-10010110. -> -96. }

The { } shouldn't stand out.  They're only there as a frame for
the tests that you're interested in.  There is also no need to draw
your attention to the tests because there's practically nothing
else to see, that might distract you from them.  It's just tests
and more tests and some testing syntax.

I don't see any uses of REGRESS in lina 5.3.0, but I imagine it
looks something like this:

  SCR # 1
   0 ( -a :_Make_want_available_silently )           \ AvdH B0nov25
   1 ( WANT WANTED CF: ) \ AvdH A7feb24
   2 CREATE _pad 80 ALLOT \ Word surrounded by spaces
   3 : FILL-pad   ( sc --) " " _pad $!   _pad $+!   " " _pad $+! ;
   4 REGRESS SOME WORDS HERE S:
   5 : POSITION   _pad @ - 0 MAX OVER + SWAP
   6   DO   I _pad $@ CORA   0= IF I UNLOOP EXIT THEN   LOOP   0 ;
   7 \ Find WORD in blocks N and up. Leave the BLOCK or throw.
   8 : #LOCATED  >R FILL-pad R> BEGIN 0 OVER (LINE) -TRAILING
   9     DUP 0= 24 AND THROW POSITION 0= WHILE 1+ REPEAT   ;
  10 : (WANTED)   ( sc -- ) ERRSCR @ 4 + >R   BEGIN 2DUP PRESENT 0=
  11   WHILE 2DUP R> #LOCATED DUP 1+ >R  LOAD REPEAT RDROP ;
  12 : WANTED   ( Make WORD available. ) '(WANTED) CATCH DUP 24 = IF
  13     >R ETYPE R> MESSAGE ELSE THROW 2DROP THEN ;
  14 : WANT  ^J PARSE SAVE SET-SRC BEGIN NAME DUP WHILE WANTED
  15     REPEAT 2DROP RESTORE ;      : CF: "CONFIG" WANTED ;

If your source is in files and has more vertical spacing, it's
still the case that you want a testing syntax that reads well when
occasionally found among a lot of non-testing code.  This is a
different desire and it justifies a different solution than a
desire for testing syntax that should not be ridiculous when
mainly found by others of its kind:

  \ Repeat in Hex mode
  16 OLD-DBASE ! 16 BASE !
  REGRESS #12346789. YIELDS BC65A5. S:
  REGRESS #-12346789. YIELDS -BC65A5. S:
  REGRESS $12aBcDeF. YIELDS 12AbCdeF. S:
  REGRESS $-12AbCdEf. YIELDS -12ABCDef. S:
  REGRESS %10010110. YIELDS 96. S:
  REGRESS %-10010110. YIELDS -96. S:


-- Julian

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

#46207

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>>Paul Rubin <no.email@nospam.invalid> writes:
>>> I'm not familiar with the
>>>Hopkins system
>
>>I guess he means the Hayes tester (and John Hayes worked at Johns
>>Hopkins University).  A typical test looks like this:
>
>>{ 1 2 + -> 3 }
>
>>The idea to have these inline and disableable is interesting.  I have
>>no idea why Albert van der Horst had to invent a new syntax for that.
>
>Because words like { and } are severely overloaded?

True, but others have noticed this quite some time ago, so in 2007 I
presented <2007Aug19.221330@mips.complang.tuwien.ac.at> a revision of
the Hayes tester that uses T{ and }T (with some other additional
features, in particular FP support).  That has been picked up and
further developed by others and is used in the Forth-2012 standard and
Gerry Jackson's test suite
<https://github.com/gerryjackson/forth2012-test-suite>.

>{ } do not stand out, at all. I don't like that.

To me lines that start with { or T{ stand out nicely; maybe you should
get a highlighting editor.

>The endsentinel costs extra code and tokens, especially
>to make it disablable.

It allows putting other stuff on the same line, but that's admittedly
not used much.  One could require that there is nothing on the same
line that is not enabled or disabled at the same time; then one could
implement a disabled T{ like \.  OTOH, scanning for " }T" is not that
hard.  And it's probably simpler than whatever REGRESS does to perform
the }T action when the end of the line is reached.

>There is a difference with Hopkins regards purpose:
>  Hopkins : find errors in systems
>  REGRESS : prevent wrong application code to be loaded.

There is nothing in the Hayes or ttester.fs testing framework that
limits the usage to system testing.  System testing was just its first
application.

>  Hopkins is not reentrant as it uses some global data

What would be the point of reentrancy there?

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#46212

On 25/03/2016 12:42, Albert van der Horst wrote:
> anton@mips.complang.tuwien.ac.at  (Anton Ertl) writes:
>
>> >Paul Rubin<no.email@nospam.invalid>  writes:
>>> >>I'm not familiar with the
>>> >>Hopkins system
>> >I guess he means the Hayes tester (and John Hayes worked at Johns
>> >Hopkins University).  A typical test looks like this:
>> >{ 1 2 + -> 3 }
>> >The idea to have these inline and disableable is interesting.  I have
>> >no idea why Albert van der Horst had to invent a new syntax for that.
> Because words like { and } are severely overloaded?
>
> Plus:
> { } do not stand out, at all. I don't like that.
> The endsentinel costs extra code and tokens, especially
> to make it disablable.

T{ ... }T was introduced to replace { ... } to avoid a clash. T{ stands 
out well enough for me.

>
> The obligation to have all on one line makes it possible to
> filter out with `` grep -v REGRESS '' and prevent idiots to
> write page long tests.

I routinely have test files several pages long. Why does that make me an 
idiot?

I see no advantage in REGRESS ... S: over T{ ... }T which seem to be 
more flexible e.g. they can span more than one line, T{ and }T can be 
used in loops. It seems a bit silly to me to have tests in line in the 
source code if they have to be filtered out with grep. Better to have 
the tests in a separate file.

-- 
Gerry

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

#46215

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:

>On 25/03/2016 12:42, Albert van der Horst wrote:
>> anton@mips.complang.tuwien.ac.at  (Anton Ertl) writes:
>>
>>> >Paul Rubin<no.email@nospam.invalid>  writes:
>>>> >>I'm not familiar with the
>>>> >>Hopkins system
>>> >I guess he means the Hayes tester (and John Hayes worked at Johns
>>> >Hopkins University).  A typical test looks like this:
>>> >{ 1 2 + -> 3 }
>>> >The idea to have these inline and disableable is interesting.  I have
>>> >no idea why Albert van der Horst had to invent a new syntax for that.
>> Because words like { and } are severely overloaded?
>>
>> Plus:
>> { } do not stand out, at all. I don't like that.
>> The endsentinel costs extra code and tokens, especially
>> to make it disablable.

>T{ ... }T was introduced to replace { ... } to avoid a clash. T{ stands
>out well enough for me.

>>
>> The obligation to have all on one line makes it possible to
>> filter out with `` grep -v REGRESS '' and prevent idiots to
>> write page long tests.

>I routinely have test files several pages long. Why does that make me an
>idiot?

>I see no advantage in REGRESS ... S: over T{ ... }T which seem to be
>more flexible e.g. they can span more than one line, T{ and }T can be
>used in loops. It seems a bit silly to me to have tests in line in the
>source code if they have to be filtered out with grep. Better to have
>the tests in a separate file.

Now we are back to the point that they serve a different purpose.

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

#46219

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:

>Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:

>>On 25/03/2016 12:42, Albert van der Horst wrote:
>>> anton@mips.complang.tuwien.ac.at  (Anton Ertl) writes:
>>>
>>>> >Paul Rubin<no.email@nospam.invalid>  writes:
>>>>> >>I'm not familiar with the
>>>>> >>Hopkins system
>>>> >I guess he means the Hayes tester (and John Hayes worked at Johns
>>>> >Hopkins University).  A typical test looks like this:
>>>> >{ 1 2 + -> 3 }
>>>> >The idea to have these inline and disableable is interesting.  I have
>>>> >no idea why Albert van der Horst had to invent a new syntax for that.
>>> Because words like { and } are severely overloaded?
>>>
>>> Plus:
>>> { } do not stand out, at all. I don't like that.
>>> The endsentinel costs extra code and tokens, especially
>>> to make it disablable.

>>T{ ... }T was introduced to replace { ... } to avoid a clash. T{ stands
>>out well enough for me.

>>>
>>> The obligation to have all on one line makes it possible to
>>> filter out with `` grep -v REGRESS '' and prevent idiots to
>>> write page long tests.

>>I routinely have test files several pages long. Why does that make me an
>>idiot?

Oops. That came out wrong. The intended design of REGRESS is not to
prevent long tests. It is to prevent placing long tests to clutter
up the source file. I myself have very long tests (sometimes far longer
than the source) in packages like ciasdis (reverse engineering assembler)
and I don't think of myself as an idiot, but they are in separate files.
REGRESS must only be used for small tests. As a rule of dumb, if they
can't serve double duty as a usage example, it is not good.

>>I see no advantage in REGRESS ... S: over T{ ... }T which seem to be
>>more flexible e.g. they can span more than one line, T{ and }T can be
>>used in loops. It seems a bit silly to me to have tests in line in the
>>source code if they have to be filtered out with grep. Better to have
>>the tests in a separate file.

>Now we are back to the point that they serve a different purpose.

I mean those tests that are better in a separate file, must not be
done with REGRESS.

>>--
>>Gerry
>--

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] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web