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

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

Simple Strings

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

Contents

  Simple Strings JennyB <jennybrien@googlemail.com> - 2013-10-11 10:42 -0700
    Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-11 21:05 +0200
      Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-11 15:49 -0700
        Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-11 16:21 -0700
          Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-11 16:28 -0700
          Re: Simple Strings mhx@iae.nl - 2013-10-12 01:03 -0700
          Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-24 12:04 +0000
            Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-25 02:32 -0700
              Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-25 11:43 +0000
                Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-25 06:03 -0700
      Re: Simple Strings hughaguilar96@yahoo.com - 2013-10-11 21:26 -0700
        Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-11 23:33 -0700
          Re: Simple Strings "WJ" <w_a_x_man@yahoo.com> - 2013-10-12 18:40 +0000
        Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-12 05:40 -0500
          Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-12 04:36 -0700
            Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-12 08:56 -0500
              Re: Simple Strings Howerd <howerdo@yahoo.co.uk> - 2013-10-12 14:04 -0700
                Re: Simple Strings Coos Haak <chforth@hccnet.nl> - 2013-10-13 01:04 +0200
                  Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-13 03:25 +0200
                Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-13 02:01 -0500
                Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-14 17:24 +0000
              Re: Simple Strings "Elizabeth D. Rather" <erather@forth.com> - 2013-10-12 11:40 -1000
                Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-13 00:53 +0200
                Re: Simple Strings hughaguilar96@yahoo.com - 2013-10-12 22:13 -0700
                Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-13 02:16 -0500
                  Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 14:57 +0000
                    Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-15 19:45 +0200
                Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-14 17:27 +0000
                  Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 20:14 +0100
                    Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 16:06 +0000
              Re: Simple Strings Paul Rubin <no.email@nospam.invalid> - 2013-10-13 20:58 -0700
                Re: Simple Strings m.a.m.hendrix@tue.nl - 2013-10-14 00:00 -0700
                Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 03:18 -0500
                  Re: Simple Strings Paul Rubin <no.email@nospam.invalid> - 2013-10-14 01:49 -0700
                    Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 04:29 -0500
                      Re: Simple Strings m.a.m.hendrix@tue.nl - 2013-10-14 03:01 -0700
                        Re: Simple Strings Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-10-14 15:09 +0200
                      Re: Simple Strings Paul Rubin <no.email@nospam.invalid> - 2013-10-14 03:26 -0700
                        Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 09:21 -0500
                          Re: Simple Strings Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> - 2013-10-14 17:49 +0100
                            Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 12:53 -0500
                        Re: Simple Strings "Elizabeth D. Rather" <erather@forth.com> - 2013-10-14 09:26 -1000
                        Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-28 18:19 +0000
                Re: Simple Strings Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-10-14 11:02 +0200
                Re: Simple Strings Marc Olschok <nobody@nowhere.invalid> - 2013-10-15 14:43 +0000
                  Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-15 15:59 +0000
                    Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 12:12 +0000
                      Re: Simple Strings albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-17 11:52 +0000
            Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-12 16:55 +0100
        Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-12 16:12 +0200
          Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-12 16:50 +0100
            Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 09:41 +0100
              Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-14 13:10 +0100
                Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 13:46 +0100
                  Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 09:23 -0500
                    Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 17:38 +0100
                      Re: Simple Strings Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 12:56 -0500
                        Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 20:33 +0100
                      Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-14 21:50 +0100
                        Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 22:29 +0100
                          Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-14 22:31 +0100
                          Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-14 22:46 +0100
                Re: Simple Strings Lars Brinkhoff <lars.spam@nocrew.org> - 2013-10-15 08:00 +0200
                  Re: Simple Strings Lars Brinkhoff <lars.spam@nocrew.org> - 2013-10-15 13:20 +0200
                  Re: Simple Strings Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-15 13:36 +0100
                    Re: Simple Strings Lars Brinkhoff <lars.spam@nocrew.org> - 2013-10-16 12:11 +0200
                      Re: Simple Strings Coos Haak <chforth@hccnet.nl> - 2013-10-16 17:36 +0200
                      Re: Simple Strings "Alex McDonald" <blog@rivadpm.com> - 2013-10-16 17:01 +0100
                        Re: Simple Strings Lars Brinkhoff <lars.spam@nocrew.org> - 2013-10-16 20:52 +0200
    Re: Simple Strings "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-10-12 22:49 -0700
      Re: Simple Strings hughaguilar96@yahoo.com - 2013-10-13 10:31 -0700
    Re: Simple Strings hughaguilar96@yahoo.com - 2013-10-13 10:30 -0700
    Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-14 16:26 +0000
      Re: Simple Strings JennyB <jennybrien@googlemail.com> - 2013-10-15 07:36 -0700
        Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 16:05 +0000
          Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-16 19:58 +0200
            Re: Simple Strings Brad Eckert <hwfwguy@gmail.com> - 2013-10-29 07:40 -0700
              Re: Simple Strings Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 17:10 +0100
                Re: Simple Strings Brad Eckert <hwfwguy@gmail.com> - 2013-10-29 16:39 -0700
              Re: Simple Strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-30 12:00 +0000

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

#26518

Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> wrote:
> On 14/10/2013 15:21, Andrew Haley wrote:
>> Paul Rubin <no.email@nospam.invalid> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> So what if they're globally visible?  It's only an actual problem if
>>>> they shadow something else,
>>>
>>> Picking enough new names to prevent shadowing is a problem in its own
>>> right.  I don't think it's really like static functions in C.  It's more
>>> like local variables in C functions.  It's common for C functions to be
>>> a few tens of LOC long and use a number of internal variables.  In Forth
>>> the function is instead split into a half dozen named factors, and those
>>> names start getting cumbersome after a while.  I end up numbering
>>> instead, like foo.1, foo.2 etc. but that's not so descriptive.
>>
>> You reuse some names.  As long as they don't shadow something global,
>> it's not going to be a problem.
>>
>> IME, this tends to be raised as a problem by users of other languages.
>> Have you ever encountered such a problem in a Forth program?
>>
> Yes! Many times.
> 
> I use VFX under Windows where I find that the various display objects 
> such as edit boxes, display 'panels' etc. each need to respond to the 
> various Windows messages.
> 
> One such message is the one informing an application that an object has 
> been resized and a word to respond to that message might be DORESIZE 
> (say). Each of those objects will respond to that message in a different 
> way and I want to identify each object's responses properly.
> 
> So I end up with something like:
>        editboxRESIZE, winpanelRESIZE, gridRESIZE, listRESIZE etc. You get the 
> picture.

I think that's a completely different situation from the one I was
talking about.  In this case, you need the RESIZE words to be visible,
so you need to give them different names.  I'm talking about internal
factors.

Andrew.

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

#26521

On 10/14/13 12:26 AM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> So what if they're globally visible?  It's only an actual problem if
>> they shadow something else,
>
> Picking enough new names to prevent shadowing is a problem in its own
> right.  I don't think it's really like static functions in C.  It's more
> like local variables in C functions.  It's common for C functions to be
> a few tens of LOC long and use a number of internal variables.  In Forth
> the function is instead split into a half dozen named factors, and those
> names start getting cumbersome after a while.  I end up numbering
> instead, like foo.1, foo.2 etc. but that's not so descriptive.
>

A useful factor (as opposed to just a section of code) should perform a 
conceptual function, and that should help think of a descriptive name. 
It's a good rule of thumb that if you can think of a name for it, it's 
probably a useful factor, and vice-versa. Some people use a Thesaurus :-)


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]

#26724

In article <7x4n8kjghp.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> So what if they're globally visible?  It's only an actual problem if
>> they shadow something else,
>
>Picking enough new names to prevent shadowing is a problem in its own
>right.  I don't think it's really like static functions in C.  It's more
>like local variables in C functions.  It's common for C functions to be
>a few tens of LOC long and use a number of internal variables.  In Forth
>the function is instead split into a half dozen named factors, and those
>names start getting cumbersome after a while.  I end up numbering
>instead, like foo.1, foo.2 etc. but that's not so descriptive.

The static keyword in C prevents a function from being visible outside
of the current "compilation unit" read source file.
As such it is quite similar. Local variables in C functions are similar
to local variables in Forth.

If I write C in my Forthish style, there are lots of small functions
all called PRIVATE.

#define PRIVATE static

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]

#26499

In article <7xtxgkpkpt.fsf@ruckus.brouhaha.com>,
 Paul Rubin <no.email@nospam.invalid> wrote:

[...]

> Does that look tempting?

No.
Something similar already exists in several Forth systems.
Some find it very useful, for others it's hell!
I'm forced to work with it: cause of utter frustration to deal with 
other people their ideas about factoring or fixing their bugs.

-r

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

#26551

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> > A quotation is block of Forth code that has no name...
> > So this example prints 99:
> > : example   [: 99 . ;] execute ; ...
> > Note that a quotation is only a notational convenience.
> 
> I find myself wishing for something more like a lightweight module
> symbol to make temporary named functions, rather than getting rid of the
> names completely.  Something inspired by old-fashioned 16-line screens:
> 
> PARAGRAPH( foo bar ) \ only foo and bar are visible from this paragraph
> : tempthing blah blah ;
> : another-temp blah blah blah ;
> : foo ( n -- n n ) tempthing xyz another-temp ;
> : whatsit xyz foo ;
> : bar ( n -- )  whatsit 3 foo tempthing blah blah ;
> /PARAGRAPH
> 
> The /PARAGRAPH forgets all symbols defined in the paragraph, except
> the ones named for export at the top of the paragraph.  /PARAGRAPH
> could be combined with starting a new paragraph:
> 
> +PARAGRAPH( quux baz )  \ equivalent to /PARAGRAPH PARAGRAPH( ... )
> : quux ... ;
> : baz ... ;
> /PARAGRAPH
> 
> Does that look tempting?

Actually, Retroforth provides this (or at least did so up to v9)
via local definitions. Your examples would look like

loc:
: tempthing blah blah ;
: another-temp blah blah blah ;
: foo ( n -- n n ) tempthing xyz another-temp ;
: whatsit xyz foo ;
: bar ( n -- )  whatsit 3 foo tempthing blah blah ;
' foo ' bar
;loc
alias bar alias foo

-- 
Marc

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

#26556

In article <l3jk6u$hko$1@news.albasani.net>,
Marc Olschok  <nobody@nowhere.invalid> wrote:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> > A quotation is block of Forth code that has no name...
>> > So this example prints 99:
>> > : example   [: 99 . ;] execute ; ...
>> > Note that a quotation is only a notational convenience.
>>
>> I find myself wishing for something more like a lightweight module
>> symbol to make temporary named functions, rather than getting rid of the
>> names completely.  Something inspired by old-fashioned 16-line screens:
>>
>> PARAGRAPH( foo bar ) \ only foo and bar are visible from this paragraph
>> : tempthing blah blah ;
>> : another-temp blah blah blah ;
>> : foo ( n -- n n ) tempthing xyz another-temp ;
>> : whatsit xyz foo ;
>> : bar ( n -- )  whatsit 3 foo tempthing blah blah ;
>> /PARAGRAPH
>>
>> The /PARAGRAPH forgets all symbols defined in the paragraph, except
>> the ones named for export at the top of the paragraph.  /PARAGRAPH
>> could be combined with starting a new paragraph:
>>
>> +PARAGRAPH( quux baz )  \ equivalent to /PARAGRAPH PARAGRAPH( ... )
>> : quux ... ;
>> : baz ... ;
>> /PARAGRAPH
>>
>> Does that look tempting?
>
>Actually, Retroforth provides this (or at least did so up to v9)
>via local definitions. Your examples would look like
>
>loc:
>: tempthing blah blah ;
>: another-temp blah blah blah ;
>: foo ( n -- n n ) tempthing xyz another-temp ;
>: whatsit xyz foo ;
>: bar ( n -- )  whatsit 3 foo tempthing blah blah ;
>' foo ' bar
>;loc
>alias bar alias foo

This is a nice trick that can be applied to wordlists too:
NAMESPACE AAP    \ Named wordlist with auto-push/built-in-ALSO
AAP DEFINITIONS
...
...
: export1 .. ;
: export2 .. ;
'export1 'export2
PREVIOUS DEFINITIONS
ALIAS export2 ALIAS export1

To me it proves that ALIAS is superior to the double parsing
SYNONYM. SYNONYM gets it panties in a knot and can't do this.

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

#26580

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>This is a nice trick that can be applied to wordlists too:
>NAMESPACE AAP    \ Named wordlist with auto-push/built-in-ALSO
>AAP DEFINITIONS
>...
>...
>: export1 .. ;
>: export2 .. ;
>'export1 'export2
>PREVIOUS DEFINITIONS
>ALIAS export2 ALIAS export1
>
>To me it proves that ALIAS is superior to the double parsing
>SYNONYM. SYNONYM gets it panties in a knot and can't do this.

But it can:

NAMESPACE AAP    \ Named wordlist with auto-push/built-in-ALSO
AAP get-current DEFINITIONS
...
...
: export1 .. ;
: export2 .. ;
set-current
synonym export1 export1
synonym export2 export2
PREVIOUS

- 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 2013: http://www.euroforth.org/ef13/

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

#26610

In article <2013Oct16.141258@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>This is a nice trick that can be applied to wordlists too:
>>NAMESPACE AAP    \ Named wordlist with auto-push/built-in-ALSO
>>AAP DEFINITIONS
>>...
>>...
>>: export1 .. ;
>>: export2 .. ;
>>'export1 'export2
>>PREVIOUS DEFINITIONS
>>ALIAS export2 ALIAS export1
>>
>>To me it proves that ALIAS is superior to the double parsing
>>SYNONYM. SYNONYM gets it panties in a knot and can't do this.
>
>But it can:
>
>NAMESPACE AAP    \ Named wordlist with auto-push/built-in-ALSO
>AAP get-current DEFINITIONS
>...
>...
>: export1 .. ;
>: export2 .. ;
>set-current
>synonym export1 export1
>synonym export2 export2
>PREVIOUS

Blinded by hate I suppose ;-)

>
>- 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 2013: http://www.euroforth.org/ef13/
-- 
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]

#26427

on 12/10/2013 12:36:25, Howerd wrote:
> Maybe I am suffering from the delusion that if something does not have
> a Wikipedia page it doesn't exist.

I hope your delusion doesn't extend to believing that things only work as
described in their Wikipedia pages.

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

#26424

hughaguilar96@yahoo.com wrote:

> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>> ... we now have quotations, which make handling
>> this statefull stuff easier (what to do in case of an exception?).
> 
> We now have quotations??? Since when? That is not possible under
> ANS-Forth.

We have quotations, we don't have closures.  They are easy to implement with 
a bit of carnal knowledge, and we can make them standard (so far, nobody has 
proposed an RfD).  The term comes from Factor.  I think it's unique to stack 
languages, because the typical way to deploy quotations is that they can use 
the entire stack, including for keeping state.  Example:

: count-words ( wid -- n )  0 [: drop 1+ true ;] rot traverse-wordlist ;

Closures can only keep an internal state, but they can't return that state.  
So for all those implicit loops like traverse-wordlist, you do all the stuff 
you can do with a closure with quotations, without the need for garbage 
collection, and with the added goodie that your loop can return additional 
results.

There are implementations of quotations for VFX, for SwiftForth, for Gforth 
and bigForth... and we actually should write an RfD to add them to the 
standard.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26426

on 12/10/2013 15:12:40, Bernd Paysan wrote:
> hughaguilar96@yahoo.com wrote:
> 
>> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>>> ... we now have quotations, which make handling
>>> this statefull stuff easier (what to do in case of an exception?).
>>
>> We now have quotations??? Since when? That is not possible under
>> ANS-Forth.
> 
> We have quotations, we don't have closures. They are easy to implement
> with a bit of carnal knowledge, and we can make them standard (so far,
> nobody has proposed an RfD).

Hugh's right that they can't be implemented in only ANS Forth; but they
can be implemented easily. Here's mine for W32F, which supports RECURSE
inside a quotation and allows refering to locals defined in the embedding
definition;

\ ---  Quotations ---

: [:  ( c: -- xt xt' cs1 cs2 ) ( start an anonymous quotation )
    (comp-only)
    compilation> ( xt -- ) 
      postpone ahead
      over dup latestxt ! swap 
      1 +to localadj ;

: ;]  ( c: xt xt' cs1 cs2 -- ) ( end an anonymous quotation )
    (comp-only)
    compilation> drop
      -1 +to localadj
      postpone exit
      postpone then
      postpone literal
      latestxt ! ;

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

#26497

On 12/10/2013 16:50, Alex McDonald wrote:
> on 12/10/2013 15:12:40, Bernd Paysan wrote:
>> hughaguilar96@yahoo.com wrote:
>>
>>> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>>>> ... we now have quotations, which make handling
>>>> this statefull stuff easier (what to do in case of an exception?).
>>>
>>> We now have quotations??? Since when? That is not possible under
>>> ANS-Forth.
>>
>> We have quotations, we don't have closures. They are easy to implement
>> with a bit of carnal knowledge, and we can make them standard (so far,
>> nobody has proposed an RfD).
>
> Hugh's right that they can't be implemented in only ANS Forth;

It's been done e.g. see Stephen Pelc's summary near the end of this 
discussion:
https://groups.google.com/forum/?hl=en#!msg/comp.lang.forth/x8hUOj1MetU/tSHs6EMudLEJ

which you replied to.

-- 
Gerry

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

#26504

on 14/10/2013 09:41:28, Gerry Jackson wrote:
> On 12/10/2013 16:50, Alex McDonald wrote:
>> on 12/10/2013 15:12:40, Bernd Paysan wrote:
>>> hughaguilar96@yahoo.com wrote:
>>>
>>>> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>>>>> ... we now have quotations, which make handling
>>>>> this statefull stuff easier (what to do in case of an exception?).
>>>>
>>>> We now have quotations??? Since when? That is not possible under
>>>> ANS-Forth.
>>>
>>> We have quotations, we don't have closures. They are easy to implement
>>> with a bit of carnal knowledge, and we can make them standard (so far,
>>> nobody has proposed an RfD).
>>
>> Hugh's right that they can't be implemented in only ANS Forth;
> 
> It's been done e.g. see Stephen Pelc's summary near the end of this
> discussion:
> https://groups.google.com/forum/?hl=en#!msg/comp.lang.forth/x8hUOj1MetU/tSHs6EMudLEJ
> 
> which you replied to.
> 

Do you mean the zip file? It doesn't exist. Can you repost the code?

I'm pretty sure this can't be done without carnal knowledge. 

 

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

#26505

On 14/10/2013 13:10, Alex McDonald wrote:
> on 14/10/2013 09:41:28, Gerry Jackson wrote:
>> On 12/10/2013 16:50, Alex McDonald wrote:
>>> on 12/10/2013 15:12:40, Bernd Paysan wrote:
>>>> hughaguilar96@yahoo.com wrote:
>>>>
>>>>> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>>>>>> ... we now have quotations, which make handling
>>>>>> this statefull stuff easier (what to do in case of an exception?).
>>>>>
>>>>> We now have quotations??? Since when? That is not possible under
>>>>> ANS-Forth.
>>>>
>>>> We have quotations, we don't have closures. They are easy to implement
>>>> with a bit of carnal knowledge, and we can make them standard (so far,
>>>> nobody has proposed an RfD).
>>>
>>> Hugh's right that they can't be implemented in only ANS Forth;
>>
>> It's been done e.g. see Stephen Pelc's summary near the end of this
>> discussion:
>> https://groups.google.com/forum/?hl=en#!msg/comp.lang.forth/x8hUOj1MetU/tSHs6EMudLEJ
>>
>> which you replied to.
>>
>
> Do you mean the zip file? It doesn't exist. Can you repost the code?
>

Sorry that site has been taken down for various reasons, if you send me 
an email address I'll email the zip file to you. It's got test files, a 
demo etc included in the zip file. There's Knuth's manorboy code for it 
somewhere in c.l.f archives.

> I'm pretty sure this can't be done without carnal knowledge.
>

Well it works on several ANS Forths without carnal knowledge of them, 
but not Win32 Forth the last time I tried it as SAVE-INPUT and 
RESTORE-INPUT didn't work properly on Win32 Forth. I don't know if it 
has been fixed or not (I think we've mentioned this before).

-- 
Gerry

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

#26508

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> On 14/10/2013 13:10, Alex McDonald wrote:
>> on 14/10/2013 09:41:28, Gerry Jackson wrote:
>>> On 12/10/2013 16:50, Alex McDonald wrote:
>>>> on 12/10/2013 15:12:40, Bernd Paysan wrote:
>>>>> hughaguilar96@yahoo.com wrote:
>>>>>
>>>>>> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>>>>>>> ... we now have quotations, which make handling
>>>>>>> this statefull stuff easier (what to do in case of an exception?).
>>>>>>
>>>>>> We now have quotations??? Since when? That is not possible under
>>>>>> ANS-Forth.
>>>>>
>>>>> We have quotations, we don't have closures. They are easy to implement
>>>>> with a bit of carnal knowledge, and we can make them standard (so far,
>>>>> nobody has proposed an RfD).
>>>>
>>>> Hugh's right that they can't be implemented in only ANS Forth;
>>>
>>> It's been done e.g. see Stephen Pelc's summary near the end of this
>>> discussion:
>>> https://groups.google.com/forum/?hl=en#!msg/comp.lang.forth/x8hUOj1MetU/tSHs6EMudLEJ
>>>
>>> which you replied to.
>>>
>>
>> Do you mean the zip file? It doesn't exist. Can you repost the code?
>>
> 
> Sorry that site has been taken down for various reasons, if you send me 
> an email address I'll email the zip file to you.

I remember someone posted some code that required a complex OOP
package, but I couldn't tease the code out of the OOP.  I haven't seen
a straightforward Forth implmentation.

Andrew.

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

#26509

On 14/10/2013 15:23, Andrew Haley wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>> On 14/10/2013 13:10, Alex McDonald wrote:
>>> on 14/10/2013 09:41:28, Gerry Jackson wrote:
>>>> On 12/10/2013 16:50, Alex McDonald wrote:
>>>>> on 12/10/2013 15:12:40, Bernd Paysan wrote:
>>>>>> hughaguilar96@yahoo.com wrote:
>>>>>>
>>>>>>> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>>>>>>>> ... we now have quotations, which make handling
>>>>>>>> this statefull stuff easier (what to do in case of an exception?).
>>>>>>>
>>>>>>> We now have quotations??? Since when? That is not possible under
>>>>>>> ANS-Forth.
>>>>>>
>>>>>> We have quotations, we don't have closures. They are easy to implement
>>>>>> with a bit of carnal knowledge, and we can make them standard (so far,
>>>>>> nobody has proposed an RfD).
>>>>>
>>>>> Hugh's right that they can't be implemented in only ANS Forth;
>>>>
>>>> It's been done e.g. see Stephen Pelc's summary near the end of this
>>>> discussion:
>>>> https://groups.google.com/forum/?hl=en#!msg/comp.lang.forth/x8hUOj1MetU/tSHs6EMudLEJ
>>>>
>>>> which you replied to.
>>>>
>>>
>>> Do you mean the zip file? It doesn't exist. Can you repost the code?
>>>
>>
>> Sorry that site has been taken down for various reasons, if you send me
>> an email address I'll email the zip file to you.
>
> I remember someone posted some code that required a complex OOP
> package, but I couldn't tease the code out of the OOP.  I haven't seen
> a straightforward Forth implmentation.

It can't be as straightforward (Alex didn't say straightforward) as an 
implementation that's system specific such as those posted for various 
systems. It's not difficult in principle and but is difficult to explain 
without a diagram, but here goes.

I used :lam ... ;lam as the outer definition containing quotations (to 
avoid complications using : and ; ) and a :lam definition is compiled in 
two passes.

The first pass scans the text, when it sees a [: it does a SAVE-INPUT 
and pushes the returned data onto a stack and carries on scanning.

When it reaches the end of the enclosing definition ;lam it starts pass 
2 by unstacking the data from the last SAVE-INPUT and does a 
RESTORE-INPUT to jump back to the start of the last quotation. It then 
compiles the quotation as a :noname definition.

The next ;] does another SAVE-INPUT and stacks it
and RESTORE-INPUTs to either the preceding quotation or the :lam.
The compilation of the outer definition skips over the already compiled 
quotations. And so on until ;lam is executed.

Diagrammatically (and I hope newsreaders don't screw this up with 
proportional fonts)

:lam foo   ...   [:         ...      ;]  ...   ;lam
      A             B                   C
    save-input A
    scan--------> save-input B
                  scan------------------------> restore-input B
                                                i.e. jump to B
                      <-----------------------------
                    execute :noname
                    compile ---------> save-input C
                                       execute ;
                                       restore-input A
      <------------------------------------
    execute :
    compile -----> restore-input C
                   i.e. jump to C ------>
                                       compile ---> execute ;

It is simple to extend this to multiple and nested quotations

The complication you're thinking of might be because it also includes 
closures which is where the OOP comes in (mini-oof's not complex). I'm 
not going to attempt to explain that here.

I did it all as a proof that it could be done in ANS Forth to counter 
those who said it couldn't, more for fun than anything. I've implemented 
quotations in a straightforward way in my Forth system.

Anyway as I said to Alex, if you or anyone wants a copy, send me an 
email with an email address that works.

-- 
Gerry

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

#26519

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> On 14/10/2013 15:23, Andrew Haley wrote:
>>
>> I remember someone posted some code that required a complex OOP
>> package, but I couldn't tease the code out of the OOP.  I haven't seen
>> a straightforward Forth implmentation.
> 
> It can't be as straightforward (Alex didn't say straightforward) as
> an implementation that's system specific such as those posted for
> various systems. It's not difficult in principle and but is
> difficult to explain without a diagram, but here goes.

[ ... description elided ... ]

That's very helpful, thank you.

> The complication you're thinking of might be because it also includes 
> closures which is where the OOP comes in (mini-oof's not complex). I'm 
> not going to attempt to explain that here.

But is there a version that doesn't require an OOP package?  I just
meant a version that doesn't depend on anything other than Forth.

Thanks,
Andrew.

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

#26522

On 14/10/2013 18:56, Andrew Haley wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>> On 14/10/2013 15:23, Andrew Haley wrote:
>>>
>>> I remember someone posted some code that required a complex OOP
>>> package, but I couldn't tease the code out of the OOP.  I haven't seen
>>> a straightforward Forth implmentation.
>>
>> It can't be as straightforward (Alex didn't say straightforward) as
>> an implementation that's system specific such as those posted for
>> various systems. It's not difficult in principle and but is
>> difficult to explain without a diagram, but here goes.
>
> [ ... description elided ... ]
>
> That's very helpful, thank you.
>
>> The complication you're thinking of might be because it also includes
>> closures which is where the OOP comes in (mini-oof's not complex). I'm
>> not going to attempt to explain that here.
>
> But is there a version that doesn't require an OOP package?  I just
> meant a version that doesn't depend on anything other than Forth.
>

Not that I know of. From what's been posted in the past people seem to 
think that closures, what I've called shared variables, are not wanted 
so if they were stripped out a quick look indicates that any remaining 
code wouldn't need mini-oof. It would be quite simple to do and would 
save a lot of code.

I don't think an OOP was needed anyway, I'm often guilty of using 
mini-oof for convenience even when unnecessary as its such a simple OOP 
package.


-- 
Gerry

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

#26527

on 14/10/2013 17:38:15, Gerry Jackson wrote:
> On 14/10/2013 15:23, Andrew Haley wrote:
>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>>> On 14/10/2013 13:10, Alex McDonald wrote:
>>>> on 14/10/2013 09:41:28, Gerry Jackson wrote:
>>>>> On 12/10/2013 16:50, Alex McDonald wrote:
>>>>>> on 12/10/2013 15:12:40, Bernd Paysan wrote:
>>>>>>> hughaguilar96@yahoo.com wrote:
>>>>>>>
>>>>>>>> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>>>>>>>>> ... we now have quotations, which make handling
>>>>>>>>> this statefull stuff easier (what to do in case of an exception?).
>>>>>>>>
>>>>>>>> We now have quotations??? Since when? That is not possible under
>>>>>>>> ANS-Forth.
>>>>>>>
>>>>>>> We have quotations, we don't have closures. They are easy to implement
>>>>>>> with a bit of carnal knowledge, and we can make them standard (so far,
>>>>>>> nobody has proposed an RfD).
>>>>>>
>>>>>> Hugh's right that they can't be implemented in only ANS Forth;
>>>>>
>>>>> It's been done e.g. see Stephen Pelc's summary near the end of this
>>>>> discussion:
>>>>> https://groups.google.com/forum/?hl=en#!
msg/comp.lang.forth/x8hUOj1MetU/tSHs6EMudLEJ
>>>>>
>>>>> which you replied to.
>>>>>
>>>>
>>>> Do you mean the zip file? It doesn't exist. Can you repost the code?
>>>>
>>>
>>> Sorry that site has been taken down for various reasons, if you send me
>>> an email address I'll email the zip file to you.
>>
>> I remember someone posted some code that required a complex OOP
>> package, but I couldn't tease the code out of the OOP.  I haven't seen
>> a straightforward Forth implmentation.
> 
> It can't be as straightforward (Alex didn't say straightforward) as an
> implementation that's system specific such as those posted for various
> systems. It's not difficult in principle and but is difficult to
> explain without a diagram, but here goes.
> 
> I used :lam ... ;lam as the outer definition containing quotations (to
> avoid complications using : and ; ) and a :lam definition is compiled
> in two passes.
> 
> The first pass scans the text, when it sees a [: it does a SAVE-INPUT
> and pushes the returned data onto a stack and carries on scanning.
> 
> When it reaches the end of the enclosing definition ;lam it starts
> pass 2 by unstacking the data from the last SAVE-INPUT and does a
> RESTORE-INPUT to jump back to the start of the last quotation. It then
> compiles the quotation as a :noname definition.
> 
> The next ;] does another SAVE-INPUT and stacks it
> and RESTORE-INPUTs to either the preceding quotation or the :lam.
> The compilation of the outer definition skips over the already
> compiled quotations. And so on until ;lam is executed.
> 
> Diagrammatically (and I hope newsreaders don't screw this up with
> proportional fonts)
> 
>:lam foo   ...   [:         ...      ;]  ...   ;lam
> A             B                   C
> save-input A
> scan--------> save-input B
> scan------------------------> restore-input B
> i.e. jump to B
> <-----------------------------
> execute :noname
> compile ---------> save-input C
> execute ;
> restore-input A
> <------------------------------------
> execute :
> compile -----> restore-input C
> i.e. jump to C ------>
> compile ---> execute ;
> 
> It is simple to extend this to multiple and nested quotations
> 
> The complication you're thinking of might be because it also includes
> closures which is where the OOP comes in (mini-oof's not complex). I'm
> not going to attempt to explain that here.
> 
> I did it all as a proof that it could be done in ANS Forth to counter
> those who said it couldn't, more for fun than anything. I've
> implemented quotations in a straightforward way in my Forth system.
> 
> Anyway as I said to Alex, if you or anyone wants a copy, send me an
> email with an email address that works.
> 

Although it might be written in ANS Forth, I don't think this results in
code that can compile an ANS Forth program. 

Words such as ( a comment about [: ) or parsing as in POSTPONE ; will
throw off any simple "deferred scan".

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

#26528

On 14/10/2013 21:50, Alex McDonald wrote:
> on 14/10/2013 17:38:15, Gerry Jackson wrote:
>> On 14/10/2013 15:23, Andrew Haley wrote:
>>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>>>> On 14/10/2013 13:10, Alex McDonald wrote:
>>>>> on 14/10/2013 09:41:28, Gerry Jackson wrote:
>>>>>> On 12/10/2013 16:50, Alex McDonald wrote:
>>>>>>> on 12/10/2013 15:12:40, Bernd Paysan wrote:
>>>>>>>> hughaguilar96@yahoo.com wrote:
>>>>>>>>
>>>>>>>>> On Friday, October 11, 2013 12:05:07 PM UTC-7, Bernd Paysan wrote:
>>>>>>>>>> ... we now have quotations, which make handling
>>>>>>>>>> this statefull stuff easier (what to do in case of an exception?).
>>>>>>>>>
>>>>>>>>> We now have quotations??? Since when? That is not possible under
>>>>>>>>> ANS-Forth.
>>>>>>>>
>>>>>>>> We have quotations, we don't have closures. They are easy to implement
>>>>>>>> with a bit of carnal knowledge, and we can make them standard (so far,
>>>>>>>> nobody has proposed an RfD).
>>>>>>>
>>>>>>> Hugh's right that they can't be implemented in only ANS Forth;
>>>>>>
>>>>>> It's been done e.g. see Stephen Pelc's summary near the end of this
>>>>>> discussion:
>>>>>> https://groups.google.com/forum/?hl=en#!
> msg/comp.lang.forth/x8hUOj1MetU/tSHs6EMudLEJ
>>>>>>
>>>>>> which you replied to.
>>>>>>
>>>>>
>>>>> Do you mean the zip file? It doesn't exist. Can you repost the code?
>>>>>
>>>>
>>>> Sorry that site has been taken down for various reasons, if you send me
>>>> an email address I'll email the zip file to you.
>>>
>>> I remember someone posted some code that required a complex OOP
>>> package, but I couldn't tease the code out of the OOP.  I haven't seen
>>> a straightforward Forth implmentation.
>>
>> It can't be as straightforward (Alex didn't say straightforward) as an
>> implementation that's system specific such as those posted for various
>> systems. It's not difficult in principle and but is difficult to
>> explain without a diagram, but here goes.
>>
>> I used :lam ... ;lam as the outer definition containing quotations (to
>> avoid complications using : and ; ) and a :lam definition is compiled
>> in two passes.
>>
>> The first pass scans the text, when it sees a [: it does a SAVE-INPUT
>> and pushes the returned data onto a stack and carries on scanning.
>>
>> When it reaches the end of the enclosing definition ;lam it starts
>> pass 2 by unstacking the data from the last SAVE-INPUT and does a
>> RESTORE-INPUT to jump back to the start of the last quotation. It then
>> compiles the quotation as a :noname definition.
>>
>> The next ;] does another SAVE-INPUT and stacks it
>> and RESTORE-INPUTs to either the preceding quotation or the :lam.
>> The compilation of the outer definition skips over the already
>> compiled quotations. And so on until ;lam is executed.
>>
>> Diagrammatically (and I hope newsreaders don't screw this up with
>> proportional fonts)
>>
>> :lam foo   ...   [:         ...      ;]  ...   ;lam
>> A             B                   C
>> save-input A
>> scan--------> save-input B
>> scan------------------------> restore-input B
>> i.e. jump to B
>> <-----------------------------
>> execute :noname
>> compile ---------> save-input C
>> execute ;
>> restore-input A
>> <------------------------------------
>> execute :
>> compile -----> restore-input C
>> i.e. jump to C ------>
>> compile ---> execute ;
>>
>> It is simple to extend this to multiple and nested quotations
>>
>> The complication you're thinking of might be because it also includes
>> closures which is where the OOP comes in (mini-oof's not complex). I'm
>> not going to attempt to explain that here.
>>
>> I did it all as a proof that it could be done in ANS Forth to counter
>> those who said it couldn't, more for fun than anything. I've
>> implemented quotations in a straightforward way in my Forth system.
>>
>> Anyway as I said to Alex, if you or anyone wants a copy, send me an
>> email with an email address that works.
>>
>
> Although it might be written in ANS Forth, I don't think this results in
> code that can compile an ANS Forth program.
>
> Words such as ( a comment about [: ) or parsing as in POSTPONE ; will
> throw off any simple "deferred scan".
>

It's wise to look at any code before pontificating at what it will and 
won't do. You're as bad as Hugh:-) In fact it will scan comments and 
text bracketed by ( " and all standard parsing words like ' and 
POSTPONE. But you are partly right in that there are restrictions e.g. 
if someone writes a word like

: bar parse-name ; immediate

it won't handle  :lam foo ... [: ... bar [: ... ;] ... ;lam
or               :lam foo ... bar s" ... ;lam
and so on because there is a limit to what can be done without writing a 
full blown Forth interpreter.

Other restrictions are listed in the readme file, they are ones I think 
I could live with had I used the package extensively.

Are you sure you don't want to look at the package? ISTR that you ignore 
emails to the email address in your c.l.f posts - you certainly ignored 
one I accidentally sent soon after Thunderbird changed its interface for 
replies to newsgroups some time ago.

-- 
Gerry

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

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

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

csiph-web