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

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

Forth on spoj.com

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

Contents

  Forth on spoj.com Julian Fondren <julian.fondren@gmail.com> - 2017-02-17 21:29 -0800
    Re: Forth on spoj.com anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-18 07:06 +0000
      Re: Forth on spoj.com Julian Fondren <julian.fondren@gmail.com> - 2017-02-18 05:42 -0800
        Re: Forth on spoj.com anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-18 14:56 +0000
          Re: Forth on spoj.com Julian Fondren <julian.fondren@gmail.com> - 2017-02-18 12:58 -0800
            Re: Forth on spoj.com albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-19 11:35 +0100
      Re: Forth on spoj.com albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 14:58 +0200
        Re: Forth on spoj.com Mark Wills <markwills1970@gmail.com> - 2017-04-04 07:40 -0700
          Re: Forth on spoj.com Julian Fondren <julian.fondren@gmail.com> - 2017-04-04 07:52 -0700
            Re: Forth on spoj.com albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 17:36 +0200
            Re: Forth on spoj.com Mark Wills <markwills1970@gmail.com> - 2017-04-04 09:05 -0700
              Re: Forth on spoj.com NN <november.nihal@gmail.com> - 2017-04-04 11:22 -0700
              Re: Forth on spoj.com Julian Fondren <julian.fondren@gmail.com> - 2017-04-04 11:33 -0700
                Re: Forth on spoj.com albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-05 02:12 +0200
            Re: Forth on spoj.com rickman <gnuarm@gmail.com> - 2017-04-04 16:12 -0400
    Re: Forth on spoj.com Julian Fondren <julian.fondren@gmail.com> - 2017-02-19 22:59 -0800
    Re: Forth on spoj.com Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-03 20:06 +0200

#54956 — Forth on spoj.com

Hello clf,

A few weeks ago a coworker drew my attention to a site called
spoj.com. This site indexes programming challenges, accepts source for
solutions to them, and then builds and tests the solutions itself,
with public listings of solutions by time, memory use, language, and
whether they worked or not.

I wasn't impressed at the time--the site had a huge list of languages,
but not Forth. The challenges also seemed tricky in a bad way: the
first challenge has you write a program that "stops processing input"
when it reads in 42 on a line, this somehow meaning that it must still
exhaust its input source after reading that number, which is a
ludicrous thing to do.

It came to mind a little while ago, and if you go now and try to
submit a solution to a problem, you can tell it that your solution is
"Forth (gforth 0.7.3)".

So I submitted one.

| PROBLEM       | RESULT   | TIME | MEM | LANG  |
|---------------+----------+------+-----+-------|
| that 42 thing | accepted | 0.00 | 22M | FORTH | 

  [undefined] stdin [if] 0 constant stdin [then]
  
  1024 8 * constant /buffer
  create buffer /buffer allot
  
  : ?end ( f x -- f x )  over 0= if bye then ;
  
  : flush-line ( -- )
    begin buffer /buffer stdin read-line throw ?end nip if exit then again ;
  
  : ?42 ( n -- )
    buffer over s" 42" compare if buffer swap type cr exit then
    drop begin flush-line again ;
  
  : go ( -- )
    begin
      buffer /buffer stdin read-line ?end throw
      if ?42 else drop flush-line then
    again ;
  
  go

There was no need to keep caring about lines after finding 42, so the
reuse of flush-line in ?42 just slows it down. FLUSH-LINE exists in
the first place to skip over lines that are read incomplete and
therefore assumed to be super long and super not "42".


Forth isn't on the ranked list of languages as yet:
http://www.spoj.com/ranks/languages/


-- Julian

[toc] | [next] | [standalone]

#54963

Julian Fondren <julian.fondren@gmail.com> writes:
>The challenges also seemed tricky in a bad way: the
>first challenge has you write a program that "stops processing input"
>when it reads in 42 on a line, this somehow meaning that it must still
>exhaust its input source after reading that number, which is a
>ludicrous thing to do.

It actually turns out that this helps make the solution shorter, see
below.

I took quite a while (and resorting to Google) to find that problem
(It seems they have ~20000 problems), it's

http://www.spoj.com/problems/TEST/

>  [undefined] stdin [if] 0 constant stdin [then]

If the system does not have STDIN, isn't it better if the program
fails complaining about that rather than failing later at the
READ-FILE?  If a system treats 0 as STDIN, one could test for that
system rather than for the absence of STDIN.

>  1024 8 * constant /buffer
>  create buffer /buffer allot
>  
>  : ?end ( f x -- f x )  over 0= if bye then ;
>  
>  : flush-line ( -- )
>    begin buffer /buffer stdin read-line throw ?end nip if exit then again ;
>  
>  : ?42 ( n -- )
>    buffer over s" 42" compare if buffer swap type cr exit then
>    drop begin flush-line again ;
>  
>  : go ( -- )
>    begin
>      buffer /buffer stdin read-line ?end throw
>      if ?42 else drop flush-line then
>    again ;
>  
>  go

Gforth-specific (but your program already is, because of STDIN):

stdin slurp-fid 2dup s" 42" search and nip - type bye

[not tested on spoj.com, I would have to make an account there]

Note that the AND NIP - sequence produces the right result in case
there is no 42 in the input; if I did not care about that case, I
would have written

stdin slurp-fid 2dup s" 42" search 2drop nip over - type bye

which is conceptually a little simpler, although the code is longer.

If the requirement was not to read past the 42, we could not use
SLURP-FID, but would have to use READ-LINE in a loop, resulting in a
longer program.

- 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 2016: http://www.euroforth.org/ef16/

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

#54969

On Saturday, February 18, 2017 at 1:52:44 AM UTC-6, Anton Ertl wrote:
> 
> >  [undefined] stdin [if] 0 constant stdin [then]
> 
> If the system does not have STDIN, isn't it better if the program
> fails complaining about that rather than failing later at the
> READ-FILE?  If a system treats 0 as STDIN, one could test for that
> system rather than for the absence of STDIN.
> 

If a system uses unix file descriptors for file IDs, then it doesn't
have to define stdin. If it uses objects or FILE*s or whatever, it
must do. So I suspect this would work as widely as any other test.
 
> stdin slurp-fid 2dup s" 42" search and nip - type bye
> 
> [not tested on spoj.com, I would have to make an account there]
> 

I submitted it as that exactly and it does work.

Which also means:

  1. the input wasn't excessive in total size (only a few MB, by the
     memory use)

  2. continuous output wasn't tested for

  3. there wasn't even a "12342123" instance of a 42 ahead of 42 being
     in its own line in the input

I said I didn't like the arbitrariness of the actual tests vs. the
test descriptions, but it does remind me of redevelopment in response
to customer feedback.

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

#54971

Julian Fondren <julian.fondren@gmail.com> writes:
>  3. there wasn't even a "12342123" instance of a 42 ahead of 42 being
>     in its own line in the input

The task description says that the input contains only 1-digit and
2-digit numbers.

- 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 2016: http://www.euroforth.org/ef16/

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

#54978

On Saturday, February 18, 2017 at 9:02:07 AM UTC-6, Anton Ertl wrote:
> Julian Fondren <julian.fondren@gmail.com> writes:
> >  3. there wasn't even a "12342123" instance of a 42 ahead of 42 being
> >     in its own line in the input
> 
> The task description says that the input contains only 1-digit and
> 2-digit numbers.

Gah, this also reminds me of the feedback cycle.  I *totally* missed
that.  That last line renders much of my solution unnecessary, and
means I missed an opportunity to gratuitously use PAD

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

#55001

In article <c47533aa-ab97-4bb2-804e-615aff1d74a9@googlegroups.com>,
Julian Fondren  <julian.fondren@gmail.com> wrote:
>On Saturday, February 18, 2017 at 9:02:07 AM UTC-6, Anton Ertl wrote:
>> Julian Fondren <julian.fondren@gmail.com> writes:
>> >  3. there wasn't even a "12342123" instance of a 42 ahead of 42 being
>> >     in its own line in the input
>>
>> The task description says that the input contains only 1-digit and
>> 2-digit numbers.
>
>Gah, this also reminds me of the feedback cycle.  I *totally* missed
>that.  That last line renders much of my solution unnecessary, and
>means I missed an opportunity to gratuitously use PAD

I find (ACCEPT) a very useful words, for these cases where the
input is read but the string returned is not altered.
(ACCEPT) just returns a pointer into the input buffer and a length.
It is a factor of ACCEPT :
: ACCEPT   (ACCEPT) 2SWAP ROT MIN DUP >R MOVE R> ;

We then get

-----------------
WANT $=
: main
    BEGIN (ACCEPT) "42" $= UNTIL
\   "FOUND 42 " TYPE CR     \ test output
    BEGIN '(ACCEPT) CATCH -32 <> WHILE 2DROP REPEAT ;
-----------------

On a file with no 42 we get

? ciforth ERROR # -32 : Broken pipe

This is a very silly program indeed.

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]

#56701

In article <2017Feb18.080616@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Julian Fondren <julian.fondren@gmail.com> writes:
>>The challenges also seemed tricky in a bad way: the
>>first challenge has you write a program that "stops processing input"
>>when it reads in 42 on a line, this somehow meaning that it must still
>>exhaust its input source after reading that number, which is a
>>ludicrous thing to do.
>
>It actually turns out that this helps make the solution shorter, see
>below.
>
>I took quite a while (and resorting to Google) to find that problem
>(It seems they have ~20000 problems), it's
>
>http://www.spoj.com/problems/TEST/
>
>>  [undefined] stdin [if] 0 constant stdin [then]
>
>If the system does not have STDIN, isn't it better if the program
>fails complaining about that rather than failing later at the
>READ-FILE?  If a system treats 0 as STDIN, one could test for that
>system rather than for the absence of STDIN.
>
>>  1024 8 * constant /buffer
>>  create buffer /buffer allot
>>
>>  : ?end ( f x -- f x )  over 0= if bye then ;
>>
>>  : flush-line ( -- )
>>    begin buffer /buffer stdin read-line throw ?end nip if exit then again ;
>>
>>  : ?42 ( n -- )
>>    buffer over s" 42" compare if buffer swap type cr exit then
>>    drop begin flush-line again ;
>>
>>  : go ( -- )
>>    begin
>>      buffer /buffer stdin read-line ?end throw
>>      if ?42 else drop flush-line then
>>    again ;
>>
>>  go
>
>Gforth-specific (but your program already is, because of STDIN):
>
>stdin slurp-fid 2dup s" 42" search and nip - type bye
>
>[not tested on spoj.com, I would have to make an account there]
>
>Note that the AND NIP - sequence produces the right result in case
>there is no 42 in the input; if I did not care about that case, I
>would have written
>
>stdin slurp-fid 2dup s" 42" search 2drop nip over - type bye
>
>which is conceptually a little simpler, although the code is longer.
>
>If the requirement was not to read past the 42, we could not use
>SLURP-FID, but would have to use READ-LINE in a loop, resulting in a
>longer program.

Interesting how different solutions can be.
This is how it gets in lina scripting.

In the first place I think we need a
    : process TYPE CR ;
Otherwise the program cannot be tested. This can then be
replaced by a NOOP.
In the second place "input" means that standard in must be used
in my book. Files are not mentioned in the specs.
----------------------
#!/usr/bin/lina64 -s

WANT $= NOT
: process TYPE CR ;
BEGIN (ACCEPT) 2DUP "42" $= NOT WHILE process REPEAT
----------------------
This must be made executable in linux and then used as

doit.frt  < jan

For an executable program we need a Forth word that replaces
ABORT :
----------------------

WANT $= NOT
: process TYPE CR ;
: main
    BEGIN (ACCEPT) 2DUP "42" $= NOT WHILE process REPEAT
;
----------------------
This is accomplished with the -c option (using a SAVE-SYSTEM):

    lina -c doit.frt
    doit < jan

(Yes my PATH contains .)

(These examples have been tested. The last one gives
an EPIPE exception if the input ends before a 42.
That falls within the miserable specification.
If this annoys you, add:
    -32 CONSTANT EPIPE
    : doit 'main CATCH DUP EPIPE <> AND THROW ;
)

>
>- anton



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]

#56707

On Tuesday, 4 April 2017 13:57:51 UTC+1, Albert van der Horst  wrote:
> In article <2017Feb18.080616@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> >Julian Fondren <julian.fondren@gmail.com> writes:
> >>The challenges also seemed tricky in a bad way: the
> >>first challenge has you write a program that "stops processing input"
> >>when it reads in 42 on a line, this somehow meaning that it must still
> >>exhaust its input source after reading that number, which is a
> >>ludicrous thing to do.
> >
> >It actually turns out that this helps make the solution shorter, see
> >below.
> >
> >I took quite a while (and resorting to Google) to find that problem
> >(It seems they have ~20000 problems), it's
> >
> >http://www.spoj.com/problems/TEST/
> >
> >>  [undefined] stdin [if] 0 constant stdin [then]
> >
> >If the system does not have STDIN, isn't it better if the program
> >fails complaining about that rather than failing later at the
> >READ-FILE?  If a system treats 0 as STDIN, one could test for that
> >system rather than for the absence of STDIN.
> >
> >>  1024 8 * constant /buffer
> >>  create buffer /buffer allot
> >>
> >>  : ?end ( f x -- f x )  over 0= if bye then ;
> >>
> >>  : flush-line ( -- )
> >>    begin buffer /buffer stdin read-line throw ?end nip if exit then again ;
> >>
> >>  : ?42 ( n -- )
> >>    buffer over s" 42" compare if buffer swap type cr exit then
> >>    drop begin flush-line again ;
> >>
> >>  : go ( -- )
> >>    begin
> >>      buffer /buffer stdin read-line ?end throw
> >>      if ?42 else drop flush-line then
> >>    again ;
> >>
> >>  go
> >
> >Gforth-specific (but your program already is, because of STDIN):
> >
> >stdin slurp-fid 2dup s" 42" search and nip - type bye
> >
> >[not tested on spoj.com, I would have to make an account there]
> >
> >Note that the AND NIP - sequence produces the right result in case
> >there is no 42 in the input; if I did not care about that case, I
> >would have written
> >
> >stdin slurp-fid 2dup s" 42" search 2drop nip over - type bye
> >
> >which is conceptually a little simpler, although the code is longer.
> >
> >If the requirement was not to read past the 42, we could not use
> >SLURP-FID, but would have to use READ-LINE in a loop, resulting in a
> >longer program.
> 
> Interesting how different solutions can be.
> This is how it gets in lina scripting.
> 
> In the first place I think we need a
>     : process TYPE CR ;
> Otherwise the program cannot be tested. This can then be
> replaced by a NOOP.
> In the second place "input" means that standard in must be used
> in my book. Files are not mentioned in the specs.
> ----------------------
> #!/usr/bin/lina64 -s
> 
> WANT $= NOT
> : process TYPE CR ;
> BEGIN (ACCEPT) 2DUP "42" $= NOT WHILE process REPEAT
> ----------------------
> This must be made executable in linux and then used as
> 
> doit.frt  < jan
> 
> For an executable program we need a Forth word that replaces
> ABORT :
> ----------------------
> 
> WANT $= NOT
> : process TYPE CR ;
> : main
>     BEGIN (ACCEPT) 2DUP "42" $= NOT WHILE process REPEAT
> ;
> ----------------------
> This is accomplished with the -c option (using a SAVE-SYSTEM):
> 
>     lina -c doit.frt
>     doit < jan
> 
> (Yes my PATH contains .)
> 
> (These examples have been tested. The last one gives
> an EPIPE exception if the input ends before a 42.
> That falls within the miserable specification.
> If this annoys you, add:
>     -32 CONSTANT EPIPE
>     : doit 'main CATCH DUP EPIPE <> AND THROW ;
> )
> 
> >
> >- anton
> 
> 
> 
> 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

KISS:

: 42? ( --) begin tib @ 80 expect bl word number drop 42 <> while repeat ;

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

#56708

On Tuesday, April 4, 2017 at 9:40:52 AM UTC-5, Mark Wills wrote:
> KISS:
> 
> : 42? ( --) begin tib @ 80 expect bl word number drop 42 <> while repeat ;

This fails to echo numbers prior to 42
It fails to continue to accept input after the 42.

As silly as the problem is, you can submit Forth solutions to see if they pass:
http://www.spoj.com/problems/TEST/

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

#56711

In article <b74187f8-7dee-4539-b0db-b4193256059b@googlegroups.com>,
Julian Fondren  <julian.fondren@gmail.com> wrote:
>On Tuesday, April 4, 2017 at 9:40:52 AM UTC-5, Mark Wills wrote:
>> KISS:
>>
>> : 42? ( --) begin tib @ 80 expect bl word number drop 42 <> while repeat ;
>
>This fails to echo numbers prior to 42
>It fails to continue to accept input after the 42.
>
>As silly as the problem is, you can submit Forth solutions to see if they pass:
>http://www.spoj.com/problems/TEST/

There is nothing there to suggest that you must read numbers after
the 42. The stupid thing is that there can be no input after the
42 if the program stops. So this really is a problem to be
voted down.

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]

#56715

On Tuesday, 4 April 2017 15:52:08 UTC+1, Julian Fondren  wrote:
> On Tuesday, April 4, 2017 at 9:40:52 AM UTC-5, Mark Wills wrote:
> > KISS:
> > 
> > : 42? ( --) begin tib @ 80 expect bl word number drop 42 <> while repeat ;
> 
> This fails to echo numbers prior to 42
> It fails to continue to accept input after the 42.
> 
> As silly as the problem is, you can submit Forth solutions to see if they pass:
> http://www.spoj.com/problems/TEST/

"Stop processing input after reading in the number 42"
http://www.spoj.com/problems/TEST/

Here's a literal interpretation that satisfies all criteria:

: 42? begin tib @ 2 expect bl word number 0= if dup . then 42 <> while repeat ;

That's 79 characters in length and 52 bytes in memory (on my system).

I've no idea if it works on GForth as I don't use it and I can't be
bothered to sign up. Meh.

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

#56725

: 42? ( -- ) 
	begin
		cr pad dup 20 accept
		0. 2swap >number
		0= if drop d>s 42 = else
			drop 2drop false
		then
	until ;

NN

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

#56728

On Tuesday, April 4, 2017 at 11:05:40 AM UTC-5, Mark Wills wrote:
> On Tuesday, 4 April 2017 15:52:08 UTC+1, Julian Fondren  wrote:
> > On Tuesday, April 4, 2017 at 9:40:52 AM UTC-5, Mark Wills wrote:
> > > KISS:
> > > 
> > > : 42? ( --) begin tib @ 80 expect bl word number drop 42 <> while repeat ;
> > 
> > This fails to echo numbers prior to 42
> > It fails to continue to accept input after the 42.
> > 
> > As silly as the problem is, you can submit Forth solutions to see if they pass:
> > http://www.spoj.com/problems/TEST/
> 
> "Stop processing input after reading in the number 42"
> http://www.spoj.com/problems/TEST/

Which it means: continue to read numbers until the input is exhausted,
but don't echo them, starting with 42.

Please don't exclaim that this is crazy. I've already said all this earlier in
the thread.

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

#56733

In article <0532f8b6-9f2a-4926-a18d-7a2d72dbf975@googlegroups.com>,
Julian Fondren  <julian.fondren@gmail.com> wrote:
>On Tuesday, April 4, 2017 at 11:05:40 AM UTC-5, Mark Wills wrote:
>> On Tuesday, 4 April 2017 15:52:08 UTC+1, Julian Fondren  wrote:
>> > On Tuesday, April 4, 2017 at 9:40:52 AM UTC-5, Mark Wills wrote:
>> > > KISS:
>> > >
>> > > : 42? ( --) begin tib @ 80 expect bl word number drop 42 <> while repeat ;
>> >
>> > This fails to echo numbers prior to 42
>> > It fails to continue to accept input after the 42.
>> >
>> > As silly as the problem is, you can submit Forth solutions to see if they pass:
>> > http://www.spoj.com/problems/TEST/
>>
>> "Stop processing input after reading in the number 42"
>> http://www.spoj.com/problems/TEST/
>
>Which it means: continue to read numbers until the input is exhausted,
>but don't echo them, starting with 42.
>
>Please don't exclaim that this is crazy. I've already said all this earlier in
>the thread.

It is worth to explain this is crazy. If you continue after reading 42,
then you are processing the lines, by reading and then ignoring them.
The only way to stop processing is ... well stop processing.

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]

#56729

On 4/4/2017 10:52 AM, Julian Fondren wrote:
> On Tuesday, April 4, 2017 at 9:40:52 AM UTC-5, Mark Wills wrote:
>> KISS:
>>
>> : 42? ( --) begin tib @ 80 expect bl word number drop 42 <> while repeat ;
>
> This fails to echo numbers prior to 42
> It fails to continue to accept input after the 42.
>
> As silly as the problem is, you can submit Forth solutions to see if they pass:
> http://www.spoj.com/problems/TEST/

I can't get any to pass and with no output I have no idea why.  I saw 
comments in another problem where the specification has to be 
interpreted to say each line had to end with a space.  I don't have a 
lot of interest in trying to solve riddles with no way of figuring out 
what you are doing wrong.

-- 

Rick C

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

#55016

On Friday, February 17, 2017 at 11:29:41 PM UTC-6, Julian Fondren wrote:
> 
> Forth isn't on the ranked list of languages as yet:
> http://www.spoj.com/ranks/languages/
> 

It is now: rank 66.

65: R

Also 66: Swift

68+: Scheme, Racket, Kotlin, Awk, Fantom, Octave.

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

#56674

Julian Fondren wrote:
> the first challenge has you write a program that "stops processing
> input" when it reads in 42 on a line

I'd like something like

    : 42 bye ;

[toc] | [prev] | [standalone]

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

csiph-web