A use for quotations

[Gerry Jackson]

In the RfD for quotations it states that quotations just provide
syntactic sugar for code that can be written using :NONAME. This has led
to some opposition with statements summarised by "why bother and
complicate Forth with an unnecessary feature". I think the example below
shows that having quotations provides an opportunity for design
approaches that wouldn't be taken were quotations not available, i.e. it
wouldn't be implemented that way using :NONAME because of the complexity.

The example is for pattern matching using regular expressions (RE)
where, given this usage:

s" <regular expression>" regex$ foo
s" <text>" foo

REGEX$ ( caddr u -- ) compiles code representing the RE expression into
the word FOO.

FOO (caddr u -- caddr2 u2 f ) matches text against the RE.

The compiled code in FOO follows this pattern for each (sub)RE:

: foo ... [: 2dup <code implementing the (sub)RE> ;] CATCH ... ;

where the code after CATCH varies depending on whether the quotation was
generated by one of the RE operators ? | * +

Because the (sub)RE is arbitrarily complex the quotations will be nested
appropriately, for example given the RE:
a((bc(def*)g(h|j|k))+)?l
quotations will be nested 4 deep.

The use of CATCH and THROW handles backtracking in the event of failure.
I had some qualms about (mis)using exceptions for this purpose but it is
so convenient that I did it anyway despite reduced efficiency.

I've implemented this, using LexGen and Grace to relieve the tedium of
parsing RE's, and it works well on both my system and GForth. It was
also easy to write the code generators once I had decided on the
approach to take. I suspect that if and when I develop this into a more
complete system, access to outer local variables could be useful -
although that needs more thought.

Incidentally I had a quick look at GForth's implementation regexp.fs
but, as I couldn't find any documentation or examples of use, recoiled
from trying to understand how it works or even trying to use it. Are
there any examples or even test files available for this?

--
Gerry

[Bernd Paysan]

Am Sun, 14 Aug 2016 19:51:38 +0100 schrieb Gerry Jackson:
> Incidentally I had a quick look at GForth's implementation regexp.fs
> but, as I couldn't find any documentation or examples of use, recoiled
> from trying to understand how it works or even trying to use it. Are
> there any examples or even test files available for this?

regexp-test.fs contains the rest files. It uses "FORK/JOIN" as
speculative control structure, FORK is a call forward to the "JOIN"
marker, similar to AHEAD/THEN, but not as branch. EXIT goes back to the
code after FORK. That's a lot cheaper than CATCH/THROW.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[hughag...@gmail.com]

On Sunday, August 14, 2016 at 11:51:36 AM UTC-7, Gerry wrote:
> The use of CATCH and THROW handles backtracking in the event of failure.
> I had some qualms about (mis)using exceptions for this purpose but it is
> so convenient that I did it anyway despite reduced efficiency.

This is the only use that I have ever made of CATCH and THROW. In my LC53 encryption-cracking program I did a recursive-descent traversal through all the possible keys. When I found a key that worked, I did a THROW to escape. At this time, I was likely several levels deep in recursion, so with THROW I was able to clear out the return-stack and get back to the top --- this was much more efficient than unwinding all the recursion a step at a time, testing the same flag at every step.

If I were to write a regexp package, I would use this same technique. I may yet write one, although I don't really like regexp much so this isn't a high priority for me.

[Cecil Bayona]

Interesting, I remember in some cases nested deep in code backing out
and passing and testing a flag to see if it had failed way down in the
code so I could undo some of the effects of the software, never thought
of using that as a mechanism to simplify the code. You learn stuff
everyday or you are six feet under.
--
Cecil - k5nwa

[Gerry Jackson]

On 14/08/2016 20:44, Bernd Paysan wrote:
> Am Sun, 14 Aug 2016 19:51:38 +0100 schrieb Gerry Jackson:
>> Incidentally I had a quick look at GForth's implementation regexp.fs
>> but, as I couldn't find any documentation or examples of use, recoiled
>> from trying to understand how it works or even trying to use it. Are
>> there any examples or even test files available for this?
>
> regexp-test.fs contains the rest files. It uses "FORK/JOIN" as
> speculative control structure, FORK is a call forward to the "JOIN"
> marker, similar to AHEAD/THEN, but not as branch. EXIT goes back to the
> code after FORK. That's a lot cheaper than CATCH/THROW.
>

Thanks for pointing it out the test file. It wasn't in Gforth
0.7.9_20160113 for Windows that I've been using, and I missed finding it
in the GIT repository as I expected to see it in the test directory.

Regarding cost/efficiency of CATCH/THROW I'm not sure whether it will
make a great difference for me in practice given the power of desktop
computers. I might rethink it in future if speed is a problem.

--
Gerry

[HAA]

Gerry Jackson wrote:
> In the RfD for quotations it states that quotations just provide
> syntactic sugar for code that can be written using :NONAME. This has led
> to some opposition with statements summarised by "why bother and
> complicate Forth with an unnecessary feature".

I see :NONAME is a primitive - a low-level mechanism that can be applied
to a variety of situations. While name-lessness in general is a bad thing
(hard to test, re-use etc) there can still be valid uses for :NONAME e.g.

: +IS ( xt <name> -- )
>r :noname r> compile, ' >body dup >r @ compile, postpone ; r> ! ;

IMO quotations aren't syntactic sugar for :NONAME, they are a specific
application of it. Whatever the ills of quotations, they don't necessarily
apply to :NONAME which is a different beast altogether.

[humptydumpty]

Hi!

Another mechanism to go back to parents caller:

bo@linux-h5s7:~> gforth
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
2variable backp ok
: backs> R@ RP@ cell+ backp 2! ; ok
: back backp 2@ RP! >R ; ok
: bottom 1- ?dup IF back THEN ; ok
: middle ." pre-mid " bottom ." post.mid " ; ok
: top ." pre-top " middle ." post.top " ; ok
: test ( n -- ) ." init " backs> top cr .s ; ok
clearstack cr 1 test
init pre-top pre-mid post.mid post.top
<0> ok
clearstack cr 2 test
init pre-top pre-mid pre-top pre-mid post.mid post.top
<0> ok
clearstack cr 3 test
init pre-top pre-mid pre-top pre-mid pre-top pre-mid post.mid post.top
<0> ok


--
Have a nice day,
humptydumpty

[Gerry Jackson]

On 17/08/2016 02:29, HAA wrote:
> Gerry Jackson wrote:
>> In the RfD for quotations it states that quotations just provide
>> syntactic sugar for code that can be written using :NONAME. This has led
>> to some opposition with statements summarised by "why bother and
>> complicate Forth with an unnecessary feature".
>
> I see :NONAME is a primitive - a low-level mechanism that can be applied
> to a variety of situations. While name-lessness in general is a bad thing
> (hard to test,

I've used :NONAME extensively and don't think such definitions are any
harder to test than other definitions.

> re-use etc) there can still be valid uses for :NONAME

Obviously.

> e.g.
> : +IS ( xt <name> -- )
> >r :noname r> compile, ' >body dup >r @ compile, postpone ; r> ! ;
>

When you post cryptic code like that you really ought to provide an
example of use - one writer many readers. Ordinarily I wouldn't have
bothered to decode it but as you replied to me I felt obliged to.
For the benefit of others here is an example of what it does (I think)
- prepending an action to another.

-------------------------
Gforth 0.7.9_20160113, Copyright (C) 1995-2015 Free Software Foundation,

Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'

Type `bye' to exit:

: +IS ( xt <name> -- )
>r :noname r> compile, ' >body dup >r @ compile, postpone ;

r> ! ; ok
: creator create , does> @ execute ; ok
:noname ." mushy peas"; creator msg ok
: msg-start ." chips and " ; ok
msg mushy peas ok
' msg-start +is msg ok
msg chips and mushy peas ok
: msg-start2 cr ." Fish, " ;
ok
' msg-start2 +is msg ok
msg
Fish, chips and mushy peas ok
----------------------------------

> IMO quotations aren't syntactic sugar for :NONAME,

I and the RfD didn't say they were. Code written using quotations can be
rewritten using :NONAME definitions but with (probably) reduced
readability. I just presented an example where rewriting using :NONAME
is possible but not sensible. The converse may or may not be true.

> they are a specific application of it.

Not necessarily, an implementation of quotations may or may not use :NONAME.

> Whatever the ills of quotations, they don't necessarily
> apply to :NONAME which is a different beast altogether.
>

What are the "ills of quotations"? The arguments I've seen are whether
the RfD should include access to parent locals which clearly don't apply
to :NONAME definitions that lack a parent definition.

--
Gerry

[hughag...@gmail.com]

I started to write RP! and RP@ in VFX assembly-language, but then I remembered what Stephen Pelc has told me repeatedly: "RTFM!" So I read the VFX manual, and found that they were already there --- that saved me some time --- RTFM can pay off occasionally!

Your code is easier to use than CATCH and THROW so I put it in the novice-package as VFX-specific code --- apparently it works under Gforth too, because that is what you tested under, and I don't know about SwiftForth --- I don't bother to support Gforth or SwiftForth anymore, so I don't care.

I wrote quite a lot of SwiftForth assembly-language in the novice-package (I doubled the speed of programs such as SLIDE-RULE.4TH that rely heavily on lists) --- I think that I will delete all of that in the next release of the novice-package --- it clutters up the source-code, and Elizabeth Rather said that my novice-package was "written by a novice," so I will just delete my SwiftForh assembly-language code and forget everything I knew about SwiftForth internal workings.

In MS-DOS days, to be a Forth programmer it was necessary to disassemble UR/Forth and know all of the internal workings (when I interviewed for the job at Testra that is the only thing they asked about) --- nowadays it is necessary to disassemble VFX and know all of the internal workings --- ANS-Forth has zero value; SwiftForth and Gforth have less.

Stephen Pelc only jumped onto the Forth-200x bandwagon for the purpose of dragging his feet --- he wants everybody to ignore ANS-Forth and Forth-200x --- he makes his money by selling VFX as the true standard, so he wants the Standard to be as crippled as possible in order for VFX to look good by comparison.

[Gerry Jackson]

On 17/08/2016 08:55, humptydumpty wrote:
> On Sunday, August 14, 2016 at 9:51:36 PM UTC+3, Gerry wrote:
>>
>> The use of CATCH and THROW handles backtracking in the event of failure.
>> I had some qualms about (mis)using exceptions for this purpose but it is
>> so convenient that I did it anyway despite reduced efficiency.
>>

> Hi!
>
> Another mechanism to go back to parents caller:
>
> bo@linux-h5s7:~> gforth
> Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> 2variable backp ok
> : backs> R@ RP@ cell+ backp 2! ; ok
> : back backp 2@ RP! >R ; ok
> : bottom 1- ?dup IF back THEN ; ok
> : middle ." pre-mid " bottom ." post.mid " ; ok
> : top ." pre-top " middle ." post.top " ; ok
> : test ( n -- ) ." init " backs> top cr .s ; ok
> clearstack cr 1 test
> init pre-top pre-mid post.mid post.top
> <0> ok
> clearstack cr 2 test
> init pre-top pre-mid pre-top pre-mid post.mid post.top
> <0> ok
> clearstack cr 3 test
> init pre-top pre-mid pre-top pre-mid pre-top pre-mid post.mid post.top
> <0> ok
>

Well that not standard ANS Forth/Forth 2012 code. At the risk of being
accused of being a brown noser, I prefer to stick to complying with the
standard. I have thought that if performance becomes an issue I would
provide a lightweight mechanism such as you suggest. I haven't pursued
that thought any further - is there a guaranteed non-crashing way of
testing whether return stack manipulation works on an ANS Forth system?
If so I could conditionally compile a lightweight version.

I did post some code providing a similar mechanism to yours here
https://groups.google.com/forum/?hl=en#!topic/comp.lang.forth/b0rpNOd8WF8%5B76-100%5D

--
Gerry

[Gerry Jackson]

I hate Google Groups, that link nearly gets you there, you have to
scroll down several messages to one dated 3/6/15 (American date format
i.e. 6 March)

--
Gerry

[humptydumpty]

Hi!

Interesting! I'm used to return stack continuations, but manipulations
of return stack pointer really should be used with care :)

I do not understand reluctance of using continuations...
If there are implementations that use 2 cells for a continuation,
why not propose a standard word RCELL that have the size of
return stack continuation.

As for continuations, I'm very pleased with pair END ENDS>

[humptydumpty]

Hi!

I know that you were interested in locals implementations.
Here is another use of END ENDS> macro builders:

\ rlocals.fs

: ENDS> R> ;
: END >R ; IMMEDIATE

VARIABLE LEVELS
: ONE 1 DUP 1- LEVELS ! ; IMMEDIATE
: TWO 2 DUP 1- LEVELS ! ; IMMEDIATE
: THREE 3 DUP 1- LEVELS ! ; IMMEDIATE
: FOUR 4 DUP 1- LEVELS ! ; IMMEDIATE

VARIABLE RC
: N>R
R> RC !
0 over = IF drop RC @ >R EXIT THEN
1 over = IF drop >R RC @ >R EXIT THEN
2 over = IF drop >R >R RC @ >R EXIT THEN
3 over = IF drop >R >R >R RC @ >R EXIT THEN
ABORT" N>R: TOO MUCH LOCALS!"
;
: NR>
R> RC !
0 over = IF drop RC @ >R EXIT THEN
1 over = IF drop R> RC @ >R EXIT THEN
2 over = IF drop R> R> RC @ >R EXIT THEN
3 over = IF drop R> R> R> RC @ >R EXIT THEN
ABORT" N>R: TOO MUCH LOCALS!"
;
: RLOCALS ( ctime: u -- ) ( rtime: -- alocals )
1- ?DUP
POSTPONE >R
IF
RECURSE
ELSE
POSTPONE RP@
LEVELS @ NR> ENDS> LEVELS @ N>R
THEN
POSTPONE RDROP
; IMMEDIATE

1 [IF]
: .up-locals ( a -- )
cr ." Test of visibilty of parents locals: "
dup 0 th ?
1 th ?
;
: test ( n0 n1 -- )
TWO RLOCALS
dup 0 th ?
dup 1 th ?
.up-locals
END
;
[THEN]

And test:

bo@linux-h5s7:~/src> gforth rlocals.fs -e '9 10 TEST see TEST .s cr bye'
9 10
Test of visibilty of parents locals: 9 10
: test
>r >r rp@ dup 0 th ? dup 1 th ? .up-locals rdrop rdrop ;<0>

[humptydumpty]

Overcomplicated!

: ends> R> ;
: end >R ; immediate

: rlocal postpone >r postpone rp@ ends> postpone rdrop ; immediate
: 2rlocals postpone >r postpone >r
postpone rp@ ends>
postpone rdrop postpone rdrop ; immediate
: 3rlocals postpone >r postpone >r postpone >r
postpone rp@ ends>
postpone rdrop postpone rdrop postpone rdrop ; immediate
: 4rlocals postpone >r postpone >r postpone >r postpone >r
postpone rp@ ends>
postpone rdrop postpone rdrop postpone rdrop postpone rdrop ; immediate

: test 2rlocals dup 0 th ? 1 th ? end ;

Testing:

99 100 cr test .s
99 100 <0> ok

--
humptydumpty

[HAA]

Gerry Jackson wrote:
> On 17/08/2016 02:29, HAA wrote:

> > ...

> > I see :NONAME is a primitive - a low-level mechanism that can be applied
> > to a variety of situations. While name-lessness in general is a bad thing
> > (hard to test,
>
> I've used :NONAME extensively and don't think such definitions are any
> harder to test than other definitions.

A name is convenient and always available, an xt often isn't. Quotations are
worse when it comes to testing because they must be embedded in another
definition (funny because that was also the complaint about CATCH :)

> > e.g.
> > : +IS ( xt <name> -- )
> > >r :noname r> compile, ' >body dup >r @ compile, postpone ; r> ! ;
>
> When you post cryptic code like that you really ought to provide an
> example of use - one writer many readers. Ordinarily I wouldn't have
> bothered to decode it but as you replied to me I felt obliged to.

It was just an example and the name should have been a 'give-away' :)
+IS is an extension to DEFER IS. Where IS initializes a DEFER with
an xt, +IS prepends another to it.

> > IMO quotations aren't syntactic sugar for :NONAME,
>
> I and the RfD didn't say they were. Code written using quotations can be
> rewritten using :NONAME definitions but with (probably) reduced
> readability.
>
> I just presented an example where rewriting using :NONAME
> is possible but not sensible. The converse may or may not be true.

You are saying quotations are justified because :noname is inconvenient.
I'm saying :noname is appropriate for the uses to which it was intended.

[Anton Ertl]

Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>Well that not standard ANS Forth/Forth 2012 code. At the risk of being
>accused of being a brown noser, I prefer to stick to complying with the
>standard. I have thought that if performance becomes an issue I would
>provide a lightweight mechanism such as you suggest. I haven't pursued
>that thought any further - is there a guaranteed non-crashing way of
>testing whether return stack manipulation works on an ANS Forth system?

No. There is not even a crashing way. Some programs that use
return-address manipulation may work as intended on a system, and some
other programs don't work as intended. Typical issues in modern
systems are:

* The system uses tail-call elimination or inlining, i.e., the call
does not push a return address.

* Locals work differently than in the system for which the program was
developed. This can be avoided by not using locals in any of the
words that are involved in the return-address manipulation.

* The code for a word has a different size and representation than
expected by the program. This is relevant for programs that try to
skip code by applying, e.g., CELL+ to a return address to skip code.

* Likewise, if the program tries to compile inline data by ","
etc. after a return-address manipulating word, and then skipping
that data by adding to the return address, this does not work if the
code is somewhere else than ALLOTed data.

- 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/

[Gerry Jackson]

On 18/08/2016 03:18, HAA wrote:
> Gerry Jackson wrote:
>> On 17/08/2016 02:29, HAA wrote:
>>> ...
>>> I see :NONAME is a primitive - a low-level mechanism that can be applied
>>> to a variety of situations. While name-lessness in general is a bad thing
>>> (hard to test,
>>
>> I've used :NONAME extensively and don't think such definitions are any
>> harder to test than other definitions.
>
> A name is convenient and always available, an xt often isn't.

When testing it is easy to temporarily give a :noname definition a name
:NONAME ... ; constant fred

> Quotations are
> worse when it comes to testing because they must be embedded in another
> definition

Again it's easy to temporarily name and test a quotation

: foo ... [: ... ;] constant ... ;
foo fred
fred execute

> (funny because that was also the complaint about CATCH :)

I don't understand - CATCH doesn't have to be embedded in another definition

>
>>> e.g.
>>> : +IS ( xt <name> -- )
>>> >r :noname r> compile, ' >body dup >r @ compile, postpone ; r> ! ;
>>
>> When you post cryptic code like that you really ought to provide an
>> example of use - one writer many readers. Ordinarily I wouldn't have
>> bothered to decode it but as you replied to me I felt obliged to.
>
> It was just an example and the name should have been a 'give-away' :)

Well I did think it related to DEFER but then DEFER doesn't have to be
defined using CREATE in which case >BODY shouldn't be used on the
deferred word in a standard program. But if you don't care about
standards ...

Anyway why not use Forth 2012 words DEFER@ and DEFER!

: +is ( xt <name> -- )
>r :noname r> compile, ' dup >r defer@ compile, postpone ; r> defer!
;

> +IS is an extension to DEFER IS. Where IS initializes a DEFER with
> an xt, +IS prepends another to it.

That's all you needed to say in your previous post.

>
>>> IMO quotations aren't syntactic sugar for :NONAME,
>>
>> I and the RfD didn't say they were. Code written using quotations can be
>> rewritten using :NONAME definitions but with (probably) reduced
>> readability.
>>
>> I just presented an example where rewriting using :NONAME
>> is possible but not sensible. The converse may or may not be true.
>
> You are saying quotations are justified because :noname is inconvenient.
> I'm saying :noname is appropriate for the uses to which it was intended.

Well like the vast majority of words in the standard it wouldn't be much
use if it wasn't.


--
Gerry

[Elizabeth D. Rather]

It has to be embedded in *a* definition, not used interpretively.
:noname makes its own unnamed definition, whereas quotations and CATCHes
must be in a definition. I agree that this renders quotations less
attractive, although I'm not a great fan of :noname, either.

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."
==================================================

[Gerry Jackson]

Well I can't find anywhere in the standard where CATCH is forbidden in
interpretation mode. The specification for CATCH doesn't say its
interpretation semantics are undefined. It's not listed in ambiguous
conditions. Perhaps you can provide a reference to prove otherwise.

Furthermore it works in GForth, VFX Forth, Swiftforth and my Forth (the
only systems I've to hand) e.g try

: x 999 throw ;
' x catch cr 999 = [if] .( Caught) [else] .( Not caught) [then]

Of course that doesn't prove it is standard usage.

--
Gerry

[HAA]

Gerry Jackson wrote:
> On 18/08/2016 03:18, HAA wrote:

> > ...

> > A name is convenient and always available, an xt often isn't.
>
> When testing it is easy to temporarily give a :noname definition a name
> :NONAME ... ; constant fred
>
> > Quotations are
> > worse when it comes to testing because they must be embedded in another
> > definition
>
> Again it's easy to temporarily name and test a quotation
>
> : foo ... [: ... ;] constant ... ;
> foo fred
> fred execute

But the argument for quotations was that they don't need names.
:noname is similar impacted by its lack of name. If I have to work-around
the fact that something isn't named, then I have to ask myself what exactly
have I gained.

There may be uses for :noname etc e.g. computer-generated code
and that's what interested me about your post. But then I see libraries
such as FFL in which there is not a single use of :noname and btw
it has a regex parser.

> >> I just presented an example where rewriting using :NONAME
> >> is possible but not sensible. The converse may or may not be true.
> >
> > You are saying quotations are justified because :noname is inconvenient.
> > I'm saying :noname is appropriate for the uses to which it was intended.
>
> Well like the vast majority of words in the standard it wouldn't be much
> use if it wasn't.

But how much use are they really? Have we just talked ourselves into
believing certain things are useful or necessary?

> Anyway why not use Forth 2012 words DEFER@ and DEFER!

A case in point.

> > (funny because that was also the complaint about CATCH :)
>
> I don't understand - CATCH doesn't have to be embedded in another definition

The complaint about CATCH in a definition was that it required as argument
'a separate named word'. Quotations were billed as the solution but in order
to test the quotation you had to embed it in 'a separate named word' anyway.

[Coos Haak]

Op Sat, 20 Aug 2016 13:19:14 +1000 schreef HAA:

> Gerry Jackson wrote:
>> On 18/08/2016 03:18, HAA wrote:
>>> ...
>>> A name is convenient and always available, an xt often isn't.
>>
>> When testing it is easy to temporarily give a :noname definition a name
>>:NONAME ... ; constant fred
>>
>>> Quotations are
>>> worse when it comes to testing because they must be embedded in another
>>> definition
>>
>> Again it's easy to temporarily name and test a quotation
>>
>>: foo ... [: ... ;] constant ... ;
>> foo fred
>> fred execute
>
> But the argument for quotations was that they don't need names.
>:noname is similar impacted by its lack of name. If I have to work-around
> the fact that something isn't named, then I have to ask myself what exactly
> have I gained.

The keyword here was 'testing'. What would the developer forbid to give
a 'temporary' name to a :noname definition or a quotation in this phase?
A name probably is not used in production code.

groet Coos

[Anton Ertl]

Coos Haak <htr...@gmail.com> writes:
>Op Sat, 20 Aug 2016 13:19:14 +1000 schreef HAA:
>
>> Gerry Jackson wrote:
>>> On 18/08/2016 03:18, HAA wrote:
>>>> Quotations are
>>>> worse when it comes to testing because they must be embedded in another
>>>> definition
>>>
>>> Again it's easy to temporarily name and test a quotation
>>>
>>>: foo ... [: ... ;] constant ... ;
>>> foo fred
>>> fred execute
>>
>> But the argument for quotations was that they don't need names.
>>:noname is similar impacted by its lack of name. If I have to work-around
>> the fact that something isn't named, then I have to ask myself what exactly
>> have I gained.

Yes. But maybe you do not need to name the quotation in order to test
the word that contains it. I usually don't, just like I usually don't
need to name the contents of an IF...THEN etc., and for the contents
of ?DO...LOOP I often cannot name the contents, because the contents
contain an I.

The nice thing in this context is, that, unlike IF ... THEN, you can
test

[: ... ;] traverse-wordlist

interpretively in current development Gforth, or by using :NONAME
... ; on systems that don't support interpretive "[:".

>The keyword here was 'testing'. What would the developer forbid to give
>a 'temporary' name to a :noname definition or a quotation in this phase?
>A name probably is not used in production code.

If the definition is so complex that you want to test it separately,
you probably want to keep the name. I see quotations mainly for small
definitions that you can test as part of the word containing the
quotation, like the contents of control structures.

[HAA]

Coos Haak wrote:
> Op Sat, 20 Aug 2016 13:19:14 +1000 schreef HAA:

> ...

> > But the argument for quotations was that they don't need names.
> >:noname is similar impacted by its lack of name. If I have to work-around
> > the fact that something isn't named, then I have to ask myself what exactly
> > have I gained.
>
> The keyword here was 'testing'. What would the developer forbid to give
> a 'temporary' name to a :noname definition or a quotation in this phase?
> A name probably is not used in production code.
>
> groet Coos

Names aren't just for testing, they're there for readability and convenience.

[Julian Fondren]

On Sunday, August 21, 2016 at 11:58:10 PM UTC-5, HAA wrote:
> Names aren't just for testing, they're there for readability and convenience.

Yes, and one avoids names *also* for readability and convenience.

This entire 'testing' subthread is just devoid of any content.

[Coos Haak]

Op Mon, 22 Aug 2016 14:58:31 +1000 schreef HAA:

You turned the discussion upside down. First you complain that :noname
and quotations are hard to test. Then I proposed to give them (temporary)
names. Now you say that those names are essential.
To quote Julian Fondren: this subthread is void and without any content.

groet Coos

[HAA]

I'm not complaining. I'm pointing out the absurdity of namelessness.
If I have to give something a temporary name, or put it into a temporary
named definition, or engage in any extra work to get around the fact that
something hasn't got a name, then perhaps it's trying to tell me something.

[hughag...@gmail.com]

The whole point of quotations is that they have access to the parent function's local variables.

The Paysan-faked quotations have no purpose. You might as well just use named functions, like I did in the novice-package for many years:

: <show-seq> ( node -- )
.line @ count type cr ;

: show-seq ( head -- )
cr
['] <show-seq> each ;

I don't recall having ever use :NONAME for anything --- it is pretty useless --- the Paysan-faked quotations which are just :NONAME with syntactic sugar are uselessness piled on top of uselessness.

[Gerry Jackson]

On 24/08/2016 13:20, HAA wrote:
> Coos Haak wrote:
>> Op Mon, 22 Aug 2016 14:58:31 +1000 schreef HAA:
>>
>>> Coos Haak wrote:
>>>> Op Sat, 20 Aug 2016 13:19:14 +1000 schreef HAA:
>>>> ...
>>>>> But the argument for quotations was that they don't need names.
>>>>> :noname is similar impacted by its lack of name. If I have to work-around
>>>>> the fact that something isn't named, then I have to ask myself what exactly
>>>>> have I gained.
>>>>
>>>> The keyword here was 'testing'. What would the developer forbid to give
>>>> a 'temporary' name to a :noname definition or a quotation in this phase?
>>>> A name probably is not used in production code.
>>>>
>>>> groet Coos
>>>
>>> Names aren't just for testing, they're there for readability and convenience.
>>
>> You turned the discussion upside down. First you complain that :noname
>> and quotations are hard to test. Then I proposed to give them (temporary)
>> names. Now you say that those names are essential.
>
> I'm not complaining. I'm pointing out the absurdity of namelessness.

Whether it's absurd or not depends on the context, for example if using
the original mini-oof and two classes inherit from a base class with a
method called foo it is not absurd to give :NONAME definitions a name e.g.

:noname ... ; class1 defines foo
:noname ... ; class2 defines foo

class1 new constant obj1
class2 new constant obj2

obj1 foo \ executes the first :noname
obj2 foo \ executes the second :noname

Just one example.

> If I have to give something a temporary name, or put it into a temporary
> named definition, or engage in any extra work to get around the fact that
> something hasn't got a name, then perhaps it's trying to tell me something.
>

It's telling you that *you* yourself can't test unnamed definitions and
I think you are in a small minority there. Have you actually tried or
are you just prejudiced?

--
Gerry

[HAA]

Gerry Jackson wrote:
> On 24/08/2016 13:20, HAA wrote:

> > ...

> > I'm not complaining. I'm pointing out the absurdity of namelessness.
>
> Whether it's absurd or not depends on the context, for example if using
> the original mini-oof and two classes inherit from a base class with a
> method called foo it is not absurd to give :NONAME definitions a name e.g.
>
> :noname ... ; class1 defines foo
> :noname ... ; class2 defines foo
>
> class1 new constant obj1
> class2 new constant obj2
>
> obj1 foo \ executes the first :noname
> obj2 foo \ executes the second :noname
>
> Just one example.
>
> > If I have to give something a temporary name, or put it into a temporary
> > named definition, or engage in any extra work to get around the fact that
> > something hasn't got a name, then perhaps it's trying to tell me something.
> >
>
> It's telling you that *you* yourself can't test unnamed definitions and
> I think you are in a small minority there. Have you actually tried or
> are you just prejudiced?

I stand by my statement *AS I SAID IT*. I won't defend unnamed
definitions at any cost. If that means being misrepresented and
accused of incompetence or prejudice, so be it.