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

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

Pass a name string to a CREATE DOES> via user input

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

Contents

  Pass a name string to a CREATE DOES> via user input hank.lenzi@gmail.com - 2014-02-12 17:50 -0800
    Re: Pass a name string to a CREATE DOES> via user input "Elizabeth D. Rather" <erather@forth.com> - 2014-02-12 16:01 -1000
      Re: Pass a name string to a CREATE DOES> via user input Julian Fondren <julian.fondren@gmail.com> - 2014-02-12 18:14 -0800
        Re: Pass a name string to a CREATE DOES> via user input "Elizabeth D. Rather" <erather@forth.com> - 2014-02-12 16:36 -1000
      Re: Pass a name string to a CREATE DOES> via user input Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-13 00:42 -0800
        Re: Pass a name string to a CREATE DOES> via user input Elizabeth D Rather <erather@forth.com> - 2014-02-12 22:55 -1000
    Re: Pass a name string to a CREATE DOES> via user input Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-13 23:56 +0000
      Re: Pass a name string to a CREATE DOES> via user input hank.lenzi@gmail.com - 2014-02-13 18:20 -0800
        Re: Pass a name string to a CREATE DOES> via user input Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-14 08:02 +0000
          Re: Pass a name string to a CREATE DOES> via user input "Elizabeth D. Rather" <erather@forth.com> - 2014-02-13 22:18 -1000
            Re: Pass a name string to a CREATE DOES> via user input Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-14 10:37 +0000
              Re: Pass a name string to a CREATE DOES> via user input "Elizabeth D. Rather" <erather@forth.com> - 2014-02-14 09:53 -1000
                Re: Pass a name string to a CREATE DOES> via user input Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-14 22:16 +0000
            Re: Pass a name string to a CREATE DOES> via user input albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-14 12:17 +0000
          Re: Pass a name string to a CREATE DOES> via user input hank.lenzi@gmail.com - 2014-02-15 11:16 -0800
            Re: Pass a name string to a CREATE DOES> via user input Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-15 22:54 +0000
              Re: Pass a name string to a CREATE DOES> via user input Coos Haak <chforth@hccnet.nl> - 2014-02-16 00:24 +0100
                Re: Pass a name string to a CREATE DOES> via user input Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-16 08:01 +0000
            Re: Pass a name string to a CREATE DOES> via user input "Elizabeth D. Rather" <erather@forth.com> - 2014-02-15 16:27 -1000
              Re: Pass a name string to a CREATE DOES> via user input Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-16 08:21 +0000
            Re: Pass a name string to a CREATE DOES> via user input stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-16 10:58 +0000
      Re: Pass a name string to a CREATE DOES> via user input "Elizabeth D. Rather" <erather@forth.com> - 2014-02-13 18:28 -1000

Page 1 of 2  [1] 2  Next page →

#28350 — Pass a name string to a CREATE DOES> via user input

Hello --

 Here's the problem. I'd like to be able to associate a database indentifier with  a very long name.

 I can do that with:

: $NAME CREATE 46 ( . ) WORD C@ 1+ ALLOT ;

 The user can do something like:

$NAME STJOHN100 Mary Josephine Alcantara Souza de Aguiar.

 At this, point, of course, STJOHN100 is a word.

 The problem is that the user has to enter "$NAME". Is there a way to get a string from user input (say, via PAD) and then pass *that* to the CREATE part?

 I've tried dropping "c-addr u" on the stack, and then doing "CREATE , , " (all the rest the same).

 Why do this? For instance, you could create a procedure that would use $NAME automatically (e.g., in a loop). This would sort of work like an iterator in some other languages, I suppose.

 TIA, 
  Hank Lenzi

[toc] | [next] | [standalone]

#28351

On 2/12/14 3:50 PM, hank.lenzi@gmail.com wrote:
> Hello --
>
>   Here's the problem. I'd like to be able to associate a database indentifier with  a very long name.
>
>   I can do that with:
>
> : $NAME CREATE 46 ( . ) WORD C@ 1+ ALLOT ;
>
>   The user can do something like:
>
> $NAME STJOHN100 Mary Josephine Alcantara Souza de Aguiar.
>
>   At this, point, of course, STJOHN100 is a word.
>
>   The problem is that the user has to enter "$NAME". Is there a way to get a string from user input (say, via PAD) and then pass *that* to the CREATE part?
>
>   I've tried dropping "c-addr u" on the stack, and then doing "CREATE , , " (all the rest the same).
>
>   Why do this? For instance, you could create a procedure that would use $NAME automatically (e.g., in a loop). This would sort of work like an iterator in some other languages, I suppose.

Simple prompted user input:

: $NAME ( -- n )   CREATE 46 ( . ) WORD C@ DUP 1+ ALLOT ;

: Get-info ( -- )   BEGIN
	CR ." Enter data: " $NAME 0= UNTIL ;

If the user enters a 0 length string (i.e. just CR) the loop terminates.

Could be made fancier, but that's the general idea.

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]

#28353

On Wednesday, February 12, 2014 8:01:56 PM UTC-6, Elizabeth D. Rather wrote:
> : $NAME ( -- n )   CREATE 46 ( . ) WORD C@ DUP 1+ ALLOT ;
> 
> 
> 
> : Get-info ( -- )   BEGIN
> 
> 	CR ." Enter data: " $NAME 0= UNTIL ;
> 

get-info
Enter data: Attempt to use zero-length string as a name


What Hank is looking for is more like:

create creator ," CREATE "  ok
64 allot  ok
: (create) ( c-addr u -- ) tuck creator count + swap move creator count rot + evaluate ;
(CREATE) isn't unique.  ok
s" STJOHN100" (create)  ok
STJOHN100 . 4690004  ok

Gforth has a nice word that allows any parsing word to parse from a provided string.  To replace the parsing in SwiftForth, Hank would just need to LOCATE CREATE and work from there.


-- Julian

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

#28355

On 2/12/14 4:14 PM, Julian Fondren wrote:
> On Wednesday, February 12, 2014 8:01:56 PM UTC-6, Elizabeth D. Rather wrote:
>> : $NAME ( -- n )   CREATE 46 ( . ) WORD C@ DUP 1+ ALLOT ;
>>
>>
>>
>> : Get-info ( -- )   BEGIN
>>
>> 	CR ." Enter data: " $NAME 0= UNTIL ;
>>
>
> get-info
> Enter data: Attempt to use zero-length string as a name
>
>
> What Hank is looking for is more like:
>
> create creator ," CREATE "  ok
> 64 allot  ok
> : (create) ( c-addr u -- ) tuck creator count + swap move creator count rot + evaluate ;
> (CREATE) isn't unique.  ok
> s" STJOHN100" (create)  ok
> STJOHN100 . 4690004  ok

You mean the user has to type, s" STJOHN100" (create) ? I don't think 
so! He wants something in a loop. Nothing wrong with his $NAME, except 
that he doesn't want the user to have to type it every time.

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]

#28365

On Thursday, February 13, 2014 2:01:56 AM UTC, Elizabeth D. Rather wrote:
> Simple prompted user input:
> : $NAME ( -- n )   CREATE 46 ( . ) WORD C@ DUP 1+ ALLOT ;
> : Get-info ( -- )   BEGIN
> 	CR ." Enter data: " $NAME 0= UNTIL ;
> If the user enters a 0 length string (i.e. just CR) the loop terminates.
> Could be made fancier, but that's the general idea.
> 
> Cheers,
> 
> Elizabeth

This doesn't look correct. Where does the input come from?

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

#28367

On 2/12/2014 10:42 PM, Mark Wills wrote:
> On Thursday, February 13, 2014 2:01:56 AM UTC, Elizabeth D. Rather wrote:
>> Simple prompted user input:
>> : $NAME ( -- n )   CREATE 46 ( . ) WORD C@ DUP 1+ ALLOT ;
>> : Get-info ( -- )   BEGIN
>> 	CR ." Enter data: " $NAME 0= UNTIL ;
>> If the user enters a 0 length string (i.e. just CR) the loop terminates.
>> Could be made fancier, but that's the general idea.
>>
>> Cheers,
>>
>> Elizabeth
>
> This doesn't look correct. Where does the input come from?

Somebody has to do an ACCEPT somewhere. Hank didn't include it in his 
code, so I didn't either. The above is only a suggestion for doing a 
prompt and accepting the data. I assume there would be an ACCEPT 
somewhere before the $NAME.

In fact, this is overall a poor approach, since every time the user 
enters data there's more space ALLOTted. He really needs to use a 
temporary buffer to get the info and store it in a database.

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]

#28399

On 13/02/2014 01:50, hank.lenzi@gmail.com wrote:
> Hello --
>
>   Here's the problem. I'd like to be able to associate a database indentifier with  a very long name.
>
>   I can do that with:
>
> : $NAME CREATE 46 ( . ) WORD C@ 1+ ALLOT ;

Using WORD like this is not portable as WORD is not guaranteed to save a 
counted string at to HERE, although many Forths do so. So you ought to 
copy the string there yourself. In that case it is better to use PARSE 
instead of WORD ( and [CHAR] . instead of 46) e.g.

: $name create [char] . parse dup c, here swap chars dup allot move ;

An alternative to get the string on the rest of the line is to use 
SOURCE e.g.

: $name create source >in @ /string dup c, here swap chars dup allot 
move postpone \ ;

But that is a bit longer.

If you really want to have a named definition returning a (caddr u) 
string you can get the system to store it e.g.

: $name : [char] . parse postpone sliteral postpone ; ;

In all these versions of $name it might be a good idea to skip leading 
spaces before parsing because, if there is more than 1 space before the 
string, it/they will be included in the string

>
>   The user can do something like:
>
> $NAME STJOHN100 Mary Josephine Alcantara Souza de Aguiar.
>
>   At this, point, of course, STJOHN100 is a word.
>
>   The problem is that the user has to enter "$NAME". Is there a way to get a string from user input (say, via PAD) and then pass *that* to the CREATE part?
>

To put this in a loop you can do (REFILL works with different input 
sources and so is better than ACCEPT):

: get-line ( -- u )  refill 0= abort" Early end of file" source nip ;
: save-data ( -- ) begin get-line while $name repeat ;

save-data
STJOHN100 Mary Josephine Alcantara Souza de Aguiar
FRDBLG Fred Bloggs

\ end-data Note that input is terminated by the blank line above

If there is nothing at the end of the line after the string the 
terminating . is unnecessary as PARSE or WORD will parse to the end of 
the line.

>   I've tried dropping "c-addr u" on the stack, and then doing "CREATE , , " (all the rest the same).
>
>   Why do this? For instance, you could create a procedure that would use $NAME automatically (e.g., in a loop). This would sort of work like an iterator in some other languages, I suppose.
>
>   TIA,
>    Hank Lenzi
>


-- 
Gerry

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

#28407

> Gerry

 What can I say? This is *exactly* what I needed! Thank you!

 The part I'm not sure about is how do I get leading whitespace out of it. It's not -TRAILING. WORD does it, but PARSE doesn't, right?

 TIA

 -- Hank Lenzi

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

#28414

On 14/02/2014 02:20, hank.lenzi@gmail.com wrote:
>
>> Gerry
>
>   What can I say? This is *exactly* what I needed! Thank you!
>
>   The part I'm not sure about is how do I get leading whitespace out of it. It's not -TRAILING. WORD does it, but PARSE doesn't, right?

Yes and no. WORD loses leading delimiters, PARSE doesn't. If the 
delimiting character is a space WORD will get rid of leading spaces 
otherwise not - your delimiter is '.' so you need to do it yourself.

>
>   TIA
>
>   -- Hank Lenzi
>

: -leading  ( caddr u -- caddr' u' )
    begin dup while over c@ bl <= while 1 /string repeat then
;

s"       Hello" cr 2dup type -leading cr type
       Hello
Hello ok

Using BL <= removes any tabs and other control characters. And before 
somebody points it out, <= is not standard but easily defined

-- 
Gerry

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

#28415

On 2/13/14 10:02 PM, Gerry Jackson wrote:
> On 14/02/2014 02:20, hank.lenzi@gmail.com wrote:
>>
>>> Gerry
>>
>>   What can I say? This is *exactly* what I needed! Thank you!
>>
>>   The part I'm not sure about is how do I get leading whitespace out
>> of it. It's not -TRAILING. WORD does it, but PARSE doesn't, right?
>
> Yes and no. WORD loses leading delimiters, PARSE doesn't. If the
> delimiting character is a space WORD will get rid of leading spaces
> otherwise not - your delimiter is '.' so you need to do it yourself.

Not correct. WORD skips leading delimiters regardless of what the 
delimiter is. It will skip leading '.' or any other specified delimiter.

Leading *white space* is not specified in the CORE wordset. The 
specification covers the specified delimiter character only. In the 
FILES wordset, there is an additional requirement that "When parsing 
from a text file using a space delimiter, control characters shall be 
treated the same as the space character." That doesn't apply to user 
input, however.

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]

#28422

On 14/02/2014 08:18, Elizabeth D. Rather wrote:
> On 2/13/14 10:02 PM, Gerry Jackson wrote:
>> On 14/02/2014 02:20, hank.lenzi@gmail.com wrote:
>>>
>>>> Gerry
>>>
>>>   What can I say? This is *exactly* what I needed! Thank you!
>>>
>>>   The part I'm not sure about is how do I get leading whitespace out
>>> of it. It's not -TRAILING. WORD does it, but PARSE doesn't, right?
>>
>> Yes and no. WORD loses leading delimiters, PARSE doesn't. If the
>> delimiting character is a space WORD will get rid of leading spaces
>> otherwise not - your delimiter is '.' so you need to do it yourself.
>
> Not correct.

In that case please explain why Swiftforth does this.

: emit" [char] " emit ;
: x [char] . word count cr emit" type emit" ;
x      .\ abc.xyz
"     " ok

When I wrote "so you need to do it yourself" I meant of course that you 
needed to write code that skipped leading white space from the string 
returned by WORD. The context was a reply to a question about getting 
rid of leading whitespace

WORD skips leading delimiters regardless of what the
> delimiter is. It will skip leading '.' or any other specified delimiter.

Yes but only one delimiter can be specified for a particular execution 
of WORD. If the delimiter is '.' it will not skip leading spaces - as 
Swiftforth demonstrates.

-- 
Gerry

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

#28434

On 2/14/14 12:37 AM, Gerry Jackson wrote:
> On 14/02/2014 08:18, Elizabeth D. Rather wrote:
>> On 2/13/14 10:02 PM, Gerry Jackson wrote:
>>> On 14/02/2014 02:20, hank.lenzi@gmail.com wrote:
>>>>
>>>>> Gerry
>>>>
>>>>   What can I say? This is *exactly* what I needed! Thank you!
>>>>
>>>>   The part I'm not sure about is how do I get leading whitespace out
>>>> of it. It's not -TRAILING. WORD does it, but PARSE doesn't, right?
>>>
>>> Yes and no. WORD loses leading delimiters, PARSE doesn't. If the
>>> delimiting character is a space WORD will get rid of leading spaces
>>> otherwise not - your delimiter is '.' so you need to do it yourself.
>>
>> Not correct.
>
> In that case please explain why Swiftforth does this.
>
> : emit" [char] " emit ;
> : x [char] . word count cr emit" type emit" ;
> x      .\ abc.xyz
> "     " ok
>
> When I wrote "so you need to do it yourself" I meant of course that you
> needed to write code that skipped leading white space from the string
> returned by WORD. The context was a reply to a question about getting
> rid of leading whitespace
>
> WORD skips leading delimiters regardless of what the
>> delimiter is. It will skip leading '.' or any other specified delimiter.
>
> Yes but only one delimiter can be specified for a particular execution
> of WORD. If the delimiter is '.' it will not skip leading spaces - as
> Swiftforth demonstrates.

Ah, yes, I misunderstood: it's about skipping the characters before the 
start of the string with a non-blank delimiter. But we need to talk 
about exactly what the user interface is. Surely there will be a prompt 
followed by an ACCEPT. What is the delimiter? Why not use space? None of 
the names suggested as examples so far have embedded spaces.

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]

#28441

On 14/02/2014 19:53, Elizabeth D. Rather wrote:
> On 2/14/14 12:37 AM, Gerry Jackson wrote:
>> On 14/02/2014 08:18, Elizabeth D. Rather wrote:
>>> On 2/13/14 10:02 PM, Gerry Jackson wrote:
>>>> On 14/02/2014 02:20, hank.lenzi@gmail.com wrote:
>>>>>
>>>>>> Gerry
>>>>>
>>>>>   What can I say? This is *exactly* what I needed! Thank you!
>>>>>
>>>>>   The part I'm not sure about is how do I get leading whitespace out
>>>>> of it. It's not -TRAILING. WORD does it, but PARSE doesn't, right?
>>>>

[...]

> Ah, yes, I misunderstood: it's about skipping the characters before the
> start of the string with a non-blank delimiter. But we need to talk
> about exactly what the user interface is. Surely there will be a prompt
> followed by an ACCEPT. What is the delimiter? Why not use space? None of
> the names suggested as examples so far have embedded spaces.
>

Well the original post that I responded to gave this as an example of 
his input:

$NAME STJOHN100 Mary Josephine Alcantara Souza de Aguiar.

which has plenty of embedded spaces with the '.' as a delimiter. He 
wanted a loop that handled a line of input without the initial $NAME.

The OP didn't describe his user interface, just what he wanted to do 
with a line of input.

-- 
Gerry

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

#28423

In article <d5udneD2B8nbTGDPnZ2dnUVZ_sWdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 2/13/14 10:02 PM, Gerry Jackson wrote:
>> On 14/02/2014 02:20, hank.lenzi@gmail.com wrote:
>>>
>>>> Gerry
>>>
>>>   What can I say? This is *exactly* what I needed! Thank you!
>>>
>>>   The part I'm not sure about is how do I get leading whitespace out
>>> of it. It's not -TRAILING. WORD does it, but PARSE doesn't, right?
>>
>> Yes and no. WORD loses leading delimiters, PARSE doesn't. If the
>> delimiting character is a space WORD will get rid of leading spaces
>> otherwise not - your delimiter is '.' so you need to do it yourself.
>
>Not correct. WORD skips leading delimiters regardless of what the
>delimiter is. It will skip leading '.' or any other specified delimiter.
>
>Leading *white space* is not specified in the CORE wordset. The
>specification covers the specified delimiter character only. In the
>FILES wordset, there is an additional requirement that "When parsing
>from a text file using a space delimiter, control characters shall be
>treated the same as the space character." That doesn't apply to user
>input, however.

This fundamentally different behaviour of WORD for blanks and other
characters led to splitting the functionality over two words in
the 200x standard:
   PARSE-NAME  ( parses a blank delimited string, ignoring
   leading and trailing blank space)
   PARSE ( Parses a delimited string, up till a character.)

For ." we can use `` CHAR " PARSE ''
Be careful though. This works because the standard requires
the interpreter to work thusly:
." we go"
After identifying ." the parse pointer sits after the blank
behind the ." where the ." word finds it when it executes.
So interpreting `` ." we go" '' prints
we go
And for `` ."     we go" '' we get
    we go

PARSE-NAME get its name from the functionality. BL WORD or
PARSE-NAME is used to get the name of a new definition as in
:               test  ." ape" ;
The blanks between : and test are very unusual but syntactically
allowed, to accentuate that a name is fetched from the input stream.

>
>Cheers,


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]

#28458

> 
> : -leading  ( caddr u -- caddr' u' )
> 
>     begin dup while over c@ bl <= while 1 /string repeat then
> 
> ;
> 
> 
> 
> s"       Hello" cr 2dup type -leading cr type
> 
>        Hello

Hello, Gerry --

I get an access violation, both on SwiftForth and VFX Forth.

-- Hank Lenzi

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

#28463

On 15/02/2014 19:16, hank.lenzi@gmail.com wrote:
>
>>
>> : -leading  ( caddr u -- caddr' u' )
>>
>>      begin dup while over c@ bl <= while 1 /string repeat then
>>
>> ;
>>
>>
>>
>> s"       Hello" cr 2dup type -leading cr type
>>
>>         Hello
>
> Hello, Gerry --
>
> I get an access violation, both on SwiftForth and VFX Forth.
>
> -- Hank Lenzi
>
>

Strange, it works for me on Swiftforth, VFX Forth, GForth, Win32 Forth 
and ...

-- 
Gerry

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

#28464

Op Sat, 15 Feb 2014 22:54:39 +0000 schreef Gerry Jackson:

> On 15/02/2014 19:16, hank.lenzi@gmail.com wrote:
>>
>>>
>>> : -leading  ( caddr u -- caddr' u' )
>>>
>>>      begin dup while over c@ bl <= while 1 /string repeat then
>>>
>>> ;
>>>
>>>
>>>
>>> s"       Hello" cr 2dup type -leading cr type
>>>
>>>         Hello
>>
>> Hello, Gerry --
>>
>> I get an access violation, both on SwiftForth and VFX Forth.
>>
>> -- Hank Lenzi
>>
>>
> 
> Strange, it works for me on Swiftforth, VFX Forth, GForth, Win32 Forth 
> and ...

Perhaps forgotten the THEN after REPEAT (resolving the second WHILE)
-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#28476

On 15/02/2014 23:24, Coos Haak wrote:
> Op Sat, 15 Feb 2014 22:54:39 +0000 schreef Gerry Jackson:
>
>> On 15/02/2014 19:16, hank.lenzi@gmail.com wrote:
>>>
>>>>
>>>> : -leading  ( caddr u -- caddr' u' )
>>>>
>>>>       begin dup while over c@ bl <= while 1 /string repeat then
>>>>
>>>> ;
>>>>
>>>>
>>>>
>>>> s"       Hello" cr 2dup type -leading cr type
>>>>
>>>>          Hello
>>>
>>> Hello, Gerry --
>>>
>>> I get an access violation, both on SwiftForth and VFX Forth.
>>>
>>> -- Hank Lenzi
>>>
>>>
>>
>> Strange, it works for me on Swiftforth, VFX Forth, GForth, Win32 Forth
>> and ...
>
> Perhaps forgotten the THEN after REPEAT (resolving the second WHILE)
>

More likely he omitted the 2DUP before the first TYPE in the test line 
which did indeed give an access violation in SwiftForth when I tried it, 
but 'stack underflow' in VFX Forth.

-- 
Gerry

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

#28468

On 2/15/14 9:16 AM, hank.lenzi@gmail.com wrote:
>
>>
>> : -leading  ( caddr u -- caddr' u' )
>>
>>      begin dup while over c@ bl <= while 1 /string repeat then
>>
>> ;
>>
>>
>>
>> s"       Hello" cr 2dup type -leading cr type
>>
>>         Hello
>
> Hello, Gerry --
>
> I get an access violation, both on SwiftForth and VFX Forth.

Get rid of the extraneous THEN after REPEAT.

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]

#28477

On 16/02/2014 02:27, Elizabeth D. Rather wrote:
> On 2/15/14 9:16 AM, hank.lenzi@gmail.com wrote:
>>
>>>
>>> : -leading  ( caddr u -- caddr' u' )
>>>
>>>      begin dup while over c@ bl <= while 1 /string repeat then
>>>
>>> ;
>>>
>>>
>>>
>>> s"       Hello" cr 2dup type -leading cr type
>>>
>>>         Hello
>>
>> Hello, Gerry --
>>
>> I get an access violation, both on SwiftForth and VFX Forth.
>
> Get rid of the extraneous THEN after REPEAT.
>

Unfortunately not, Swiftforth gives:

: -leading  ( caddr u -- caddr' u' )
    begin dup while over c@ bl <= while 1 /string repeat
;  Unbalanced control structure

I did test it before posting.

-- 
Gerry

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web