Gerry Jackson <do-not-use@swldwa.uk> writes:
>I'm curious about why you think auto-scoping locals is worth the trouble
> when the philosophy of Forth in general is 'let the programmer
>beware'.

I don't care that much for claims about "the philosophy of Forth". I
have seen too much nonsense advocated with this claimed philosophy;
things along the lines of: The philosophy demands that we do it this
way, because it makes this particular word shorter by a few bytes; who
cares if this word is used dozens of times, and every use becomes
harder, more error-prone, or even bigger or slower. I care!

Anyway, you have given an example of why it is useful to define locals
inside control structures in <ukteh9$1dfna$1@dont-email.me>, and I use
that a lot. Now, if we want that, but are also required by the
standard to implement general control flow as discussed in A.3.2.3.2,
I need to define the lifetime and visibility of the locals, and
ideally they should live at least as long as they are visible. I
found a solution to this problem [ertl94l], so I implemented it.

Now, 29 years later, there is the first complaint about the main
weakness of the solution, but fortunately it is possible to fix that,
too.

@InProceedings{ertl94l,
author = "M. Anton Ertl",
title = "Automatic Scoping of Local Variables",
booktitle = "EuroForth~'94 Conference Proceedings",
year = "1994",
address = "Winchester, UK",
pages = "31--37",
url = "http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz",
abstract = "In the process of lifting the restrictions on using
locals in Forth, an interesting problem poses
itself: What does it mean if a local is defined in a
control structure? Where is the local visible? Since
the user can create every possible control structure
in ANS Forth, the answer is not as simple as it may
seem. Ideally, the local is visible at a place if
the control flow {\em must} pass through the
definition of the local to reach this place. This
paper discusses locals in general, the visibility
problem, its solution, the consequences and the
implementation as well as related programming style
questions."
}

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

minforth@gmx.net (minforth) writes:
>The standard distinguishes between <arg> and <val> locals. The latter
>are not initialised; in the locals declaration they appear after a
>vertical bar character.
>
>IIRC in gforth you can use {: ... :} multiple times within a word
>definition. It would therefore be perfectly possible to use {: | b :}
>within a control structure without logical conflicts.

Yes, it's possible. What's your point?

The "| ..." part of the {:...:} syntax is unnecessary. Instead of

{: ... | x y z :}

one could write

0 0 0 {: ... x y z :}

But I don't need either in my code, because, by being able to define
locals anywhere, I define them when the initial value is known, so no
need to define it earlier uninitialized and then set the value later.

Looking in the Gforth sources, the use of '|' in a locals definition
is usually for cases where a local buffer is defined with the 'name['
syntax.

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 08/12/2023 10:47, Ruvim wrote:
> On 2023-12-08 12:11, Gerry Jackson wrote:
> [...]
>>
>> Two things about FOR-EACH I don't think I've yet mentioned.
>>
>> The pipeline operator is optional. Without it the whole thing reverts
>> to a BEGIN ... WHILE ... REPEAT loop with a small amount of redundant
>> code. So why use FOR-EACH, IMHO the FOR-EACH is arguably more readable.
>>
>> The pipeline operator can make the FOR-EACH statement equivalent to
>> multi-WHILE loops without the drawbacks of ELSE parts being separated
>> in the source code.
>
> OTOH, FOR-EACH part is also optional. A pipeline operator can be used
> instead:
>
>   FOR-EACH TRUE DO[ next-item |> check-item |> process-item ]NEXT
>
> It's not obvious to me that placing "next-item" into a separate section
> rather than into the chain (like in this example) makes readability better.

You're probably right, my intention was to highlight that the first item
had to be something that iterated through a collection. But without
thinking it through I guess that's a fairly minor change to make. It
would also eliminate the need for DO[

>
> Also, I would use different operators to break and to continue the loop,
> instead of different signs of the input value.
>

Do you mean three operators that could be placed between the pipeline
operationsi.e. retaining the
iterator pipe-operator operation pipe-operator ... sequence

where we have three different pipe operators that, for the sake of
argument, might be:

|> for Proceed currently handled by a value 0
<|x for exit pipeline back, currently <0, like C continue
|x> for exit pipeline forward, currently >0, like C break

But without thinking about it deeply I don't see how that would work as
the decision about which option to take is at run-time not compile-time.

Whether this is managed by conditional jumps or possibly quotations ISTM
that there is always a choice of 1 from 3 has to be made at runtime.

Or did you have another idea in mind?

>
>> In addition using IF statements before the |> operator the programmer
>> has the option of continuing the loop, breaking the pipeline and
>> continuing or breaking the loop. This is also true of Gforth's CASE
>> extensions but I would argue readability again.
>>
>
> A small clarification: the operator "|>" cannot be placed inside an "IF"
> statement. Only its input value can be calculated (using "IF", or any
> other words).
>

Yes that is correct in general. If the IF was in the pipeline code it
could possibly be accomodated using a CS-ROLL or CS-PICK but of course
it could be in a separate colon definition when it would be impossible.
I was envisioning the arms of the IF ... ELSE ... THEN generating the
appropriate one of the three possibilites <0 0 >0 to be handled by the
following |>.

>
> --
> Ruvim
>

Sorry but I won't be able to work on this again until Sunday. Thanks for
your comments, it's certainly making me think about it more so we should
hopefully end up with a better solution.

--
Gerry

On 08/12/2023 14:44, Anton Ertl wrote:
> Gerry Jackson <do-not-use@swldwa.uk> writes:
>> I'm curious about why you think auto-scoping locals is worth the trouble
>> when the philosophy of Forth in general is 'let the programmer
>> beware'.
>
> I don't care that much for claims about "the philosophy of Forth". I
> have seen too much nonsense advocated with this claimed philosophy;
> things along the lines of: The philosophy demands that we do it this
> way, because it makes this particular word shorter by a few bytes; who
> cares if this word is used dozens of times, and every use becomes
> harder, more error-prone, or even bigger or slower. I care!
>
> Anyway, you have given an example of why it is useful to define locals
> inside control structures in <ukteh9$1dfna$1@dont-email.me>, and I use
> that a lot. Now, if we want that, but are also required by the
> standard to implement general control flow as discussed in A.3.2.3.2,
> I need to define the lifetime and visibility of the locals, and
> ideally they should live at least as long as they are visible. I
> found a solution to this problem [ertl94l], so I implemented it.
>
> Now, 29 years later, there is the first complaint about the main
> weakness of the solution, but fortunately it is possible to fix that,
> too.

I seem to remember years ago that I caused you to improve code generated
by Gray many years after Gray had been developed. I'm getting to be a
nuisance :)

>
> @InProceedings{ertl94l,
> author = "M. Anton Ertl",
> title = "Automatic Scoping of Local Variables",
> booktitle = "EuroForth~'94 Conference Proceedings",
> year = "1994",
> address = "Winchester, UK",
> pages = "31--37",
> url = "http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz",
> abstract = "In the process of lifting the restrictions on using
> locals in Forth, an interesting problem poses
> itself: What does it mean if a local is defined in a
> control structure? Where is the local visible? Since
> the user can create every possible control structure
> in ANS Forth, the answer is not as simple as it may
> seem. Ideally, the local is visible at a place if
> the control flow {\em must} pass through the
> definition of the local to reach this place. This
> paper discusses locals in general, the visibility
> problem, its solution, the consequences and the
> implementation as well as related programming style
> questions."
> }
>

I see, a research topic

--
Gerry

On 8/12/2023 10:37 pm, Ruvim wrote:
> On 2023-12-08 14:25, Ruvim wrote:
>> On 2023-12-08 01:47, Gerry Jackson wrote:
>>>
>>>
>>> As Gforth can declare locals within control structures it is clearly non-standard as the restriction you quote uses 'shall not' instead of making it an ambiguous condition.
>>
>> In both cases (i.e., regardless of the form), it is non-standard for *programs* and only for programs. A system is allowed to provide this capability, and non-standard programs can use this capability.
>
> Well, probably I was not quite correct here.
>
> The section "3 Usage requirements" <https://forth-standard.org/standard/usage#usage> says:
>   "A program that requires a system to provide words or techniques not defined in this standard has an environmental dependency."
>
> So, if a program requires a specific behavior in the case of some ambiguous condition, it can be considered as just an environmental dependency. Especially, if this requirement is mentioned in the program's documentation.

A program that relies on an 'ambiguous condition' can hardly be portable.
If ANS wants to claim documenting it will make it 'standard' that's their
business and yours if you choose to buy into it.

dxf <dxforth@gmail.com> writes:
>A program that relies on an 'ambiguous condition' can hardly be portable.

That depends on the ambiguous condition. In particular, looking at
<https://forth-standard.org/standard/doc#subsection.4.1.2>, I see

|producing a result out of range, e.g., multiplication (using *)
|results in a value too big to be represented by a single-cell integer
|(6.1.0090 *, 6.1.0100 */, 6.1.0110 */MOD, 6.1.0570 >NUMBER, 6.1.1561
|FM/MOD, 6.1.2214 SM/REM, 6.1.2370 UM/MOD, 8.6.1.1820 M*/);

Certainly for * every system with a given cell size produces the same
result. This has led to the result of * overflow being standardized
in the next release <http://www.forth200x.org/twos-complement.html>.
It's interesting that this ambiguous condition does not mention +, -,
or it's variants.

Bottom line: In some cases there is common practice even if it has not
been standardized.

I don't think that the documentation in 4.1.2 is useful to find such
common practice, though.

>If ANS wants to claim documenting it will make it 'standard' that's their
>business and yours if you choose to buy into it.

I don't know who this ANS is and why he/she would "want to claim" such
a thing, and why anybody should care about such a supposed urge, if
he/she does not actually make such a claim.

In any case, Forth-94 and Forth-2012 require standard systems to
document some ambiguous conditions. As you point out, that certainly
does not help in writing portable programs.

If the behaviour is considered a feature by the Forth system
implementor, the behaviour will certainly be documented without such a
requirement. If it is not a feature, what use should a programmer
have from the documentation?

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 9/12/2023 6:18 pm, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> A program that relies on an 'ambiguous condition' can hardly be portable.
>
> That depends on the ambiguous condition. In particular, looking at
> <https://forth-standard.org/standard/doc#subsection.4.1.2>, I see
>
> |producing a result out of range, e.g., multiplication (using *)
> |results in a value too big to be represented by a single-cell integer
> |(6.1.0090 *, 6.1.0100 */, 6.1.0110 */MOD, 6.1.0570 >NUMBER, 6.1.1561
> |FM/MOD, 6.1.2214 SM/REM, 6.1.2370 UM/MOD, 8.6.1.1820 M*/);
>
> Certainly for * every system with a given cell size produces the same
> result. This has led to the result of * overflow being standardized
> in the next release <http://www.forth200x.org/twos-complement.html>.
> It's interesting that this ambiguous condition does not mention +, -,
> or it's variants.
>
> Bottom line: In some cases there is common practice even if it has not
> been standardized.
>
> I don't think that the documentation in 4.1.2 is useful to find such
> common practice, though.

It was 'ambiguous' because the result was mathematically incorrect.
You can prescribe the actions taken but it won't change the fact.

> ...
> In any case, Forth-94 and Forth-2012 require standard systems to
> document some ambiguous conditions. As you point out, that certainly
> does not help in writing portable programs.

Unfortunately ANS (aka ANS-FORTH) was more interested including as many
systems under their umbrella than they were in users writing portable
programs.

dxf <dxforth@gmail.com> writes:
>On 9/12/2023 6:18 pm, Anton Ertl wrote:
>> That depends on the ambiguous condition. In particular, looking at
>> <https://forth-standard.org/standard/doc#subsection.4.1.2>, I see
>>
>> |producing a result out of range, e.g., multiplication (using *)
>> |results in a value too big to be represented by a single-cell integer
>> |(6.1.0090 *, 6.1.0100 */, 6.1.0110 */MOD, 6.1.0570 >NUMBER, 6.1.1561
>> |FM/MOD, 6.1.2214 SM/REM, 6.1.2370 UM/MOD, 8.6.1.1820 M*/);
>>
>> Certainly for * every system with a given cell size produces the same
>> result. This has led to the result of * overflow being standardized
>> in the next release <http://www.forth200x.org/twos-complement.html>.
>> It's interesting that this ambiguous condition does not mention +, -,
>> or it's variants.
>>
>> Bottom line: In some cases there is common practice even if it has not
>> been standardized.
>>
>> I don't think that the documentation in 4.1.2 is useful to find such
>> common practice, though.
>
>It was 'ambiguous' because the result was mathematically incorrect.

Where do I find the documentation on the reasons for this ambiguous
condition that your claim is based on?

I don't have such documentation, so I can only guess. And my guess is
that it's because Forth-94 allowed systems to choose among three
different representations of negative numbers: 2's-complement,
1s-complement, sign-magnitude. And these representations result in
different behaviour on overflow, so the easiest way was to declare
this to be an ambiguous condition.

In any case, it does not matter whether you consider the result to be
"mathematically incorrect", modulo arithmetic produces results that
are useful for some applications (e.g., for hash functions), so given
that it is common practice, it is a good idea to standardize it.

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 9/12/2023 10:24 pm, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> On 9/12/2023 6:18 pm, Anton Ertl wrote:
>>> That depends on the ambiguous condition. In particular, looking at
>>> <https://forth-standard.org/standard/doc#subsection.4.1.2>, I see
>>>
>>> |producing a result out of range, e.g., multiplication (using *)
>>> |results in a value too big to be represented by a single-cell integer
>>> |(6.1.0090 *, 6.1.0100 */, 6.1.0110 */MOD, 6.1.0570 >NUMBER, 6.1.1561
>>> |FM/MOD, 6.1.2214 SM/REM, 6.1.2370 UM/MOD, 8.6.1.1820 M*/);
>>>
>>> Certainly for * every system with a given cell size produces the same
>>> result. This has led to the result of * overflow being standardized
>>> in the next release <http://www.forth200x.org/twos-complement.html>.
>>> It's interesting that this ambiguous condition does not mention +, -,
>>> or it's variants.
>>>
>>> Bottom line: In some cases there is common practice even if it has not
>>> been standardized.
>>>
>>> I don't think that the documentation in 4.1.2 is useful to find such
>>> common practice, though.
>>
>> It was 'ambiguous' because the result was mathematically incorrect.
>
> Where do I find the documentation on the reasons for this ambiguous
> condition that your claim is based on?

From the link you provided:

4.1.2 Ambiguous conditions
...
producing a result out of range, e.g., multiplication (using *) results
in a value too big to be represented by a single-cell integer

>
> I don't have such documentation, so I can only guess. And my guess is
> that it's because Forth-94 allowed systems to choose among three
> different representations of negative numbers: 2's-complement,
> 1s-complement, sign-magnitude. And these representations result in
> different behaviour on overflow, so the easiest way was to declare
> this to be an ambiguous condition.
>
> In any case, it does not matter whether you consider the result to be
> "mathematically incorrect", modulo arithmetic produces results that
> are useful for some applications (e.g., for hash functions), so given
> that it is common practice, it is a good idea to standardize it.

And the result will still be 'out of range' which qualifies it as an
'ambiguous condition' under ANS' definition of the term.

On 2023-12-09 00:49, Gerry Jackson wrote:
> On 08/12/2023 10:47, Ruvim wrote:
>> On 2023-12-08 12:11, Gerry Jackson wrote:
>> [...]
>>>
>>> Two things about FOR-EACH I don't think I've yet mentioned.
>>>
>>> The pipeline operator is optional. Without it the whole thing reverts
>>> to a BEGIN ... WHILE ... REPEAT loop with a small amount of redundant
>>> code. So why use FOR-EACH, IMHO the FOR-EACH is arguably more readable.
>>>
>>> The pipeline operator can make the FOR-EACH statement equivalent to
>>> multi-WHILE loops without the drawbacks of ELSE parts being separated
>>> in the source code.
>>
>> OTOH, FOR-EACH part is also optional. A pipeline operator can be used
>> instead:
>>
>>    FOR-EACH TRUE DO[ next-item |> check-item |> process-item ]NEXT
>>
>> It's not obvious to me that placing "next-item" into a separate
>> section rather than into the chain (like in this example) makes
>> readability better.
>
> You're probably right, my intention was to highlight that the first item
> had to be something that iterated through a collection. But without
> thinking it through I guess that's a fairly minor change to make. It
> would also eliminate the need for DO[
>
>>
>> Also, I would use different operators to break and to continue the
>> loop, instead of different signs of the input value.
>>
>
> Do you mean three operators that could be placed between the pipeline
> operations i.e. retaining the
>    iterator pipe-operator operation pipe-operator ... sequence
>
> where we have three different pipe operators that, for the sake of
> argument, might be:
>
>    |>  for Proceed currently handled by a value 0
>   <|x  for exit pipeline back, currently <0, like C continue
>    |x> for exit pipeline forward, currently >0, like C break

>
> But without thinking about it deeply I don't see how that would work as
> the decision about which option to take is at run-time not compile-time.
>
> Whether this is managed by conditional jumps or possibly quotations ISTM
> that there is always a choice of 1 from 3 has to be made at runtime.
>
> Or did you have another idea in mind?
>

I mean a compile-time decision. My arguments are as follows.

1. In most use cases, you know at compile-time whether you need to
continue or break the loop (I mean, in the case of a pipeline break).
Then, it's better for readability to use different pipe-operators for
these cases.

2. For code reuse, it's better if an operation returns (and a
pipe-operator accepts) a value of one of two disjoint types {0, x/0},
rather than one of three disjoint types {0, +n/0, -n/0} (where 0 is a
singleton {"0"}, and "\" means a set difference).

If a pipe-operator distinguishes two types of the input value, two
operators are enough. And if we use zero to break a pipeline, these
operators can be defined via your "|>" as follows:

: |>| ( 0|x -- ) postpone 0= postpone |> ; immediate
: |<| ( 0|x -- ) postpone 0= postpone abs postpone |> ; immediate

--
Ruvim

In article <ul5967$2qirl$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2023-12-09 00:49, Gerry Jackson wrote:
>> On 08/12/2023 10:47, Ruvim wrote:
>>> On 2023-12-08 12:11, Gerry Jackson wrote:
>>> [...]
>>>>
>>>> Two things about FOR-EACH I don't think I've yet mentioned.
>>>>
>>>> The pipeline operator is optional. Without it the whole thing reverts
>>>> to a BEGIN ... WHILE ... REPEAT loop with a small amount of redundant
>>>> code. So why use FOR-EACH, IMHO the FOR-EACH is arguably more readable.
>>>>
>>>> The pipeline operator can make the FOR-EACH statement equivalent to
>>>> multi-WHILE loops without the drawbacks of ELSE parts being separated
>>>> in the source code.
>>>
>>> OTOH, FOR-EACH part is also optional. A pipeline operator can be used
>>> instead:
>>>
>>>    FOR-EACH TRUE DO[ next-item |> check-item |> process-item ]NEXT
>>>
>>> It's not obvious to me that placing "next-item" into a separate
>>> section rather than into the chain (like in this example) makes
>>> readability better.
>>
>> You're probably right, my intention was to highlight that the first item
>> had to be something that iterated through a collection. But without
>> thinking it through I guess that's a fairly minor change to make. It
>> would also eliminate the need for DO[
>>
>>>
>>> Also, I would use different operators to break and to continue the
>>> loop, instead of different signs of the input value.
>>>
>>
>> Do you mean three operators that could be placed between the pipeline
>> operations i.e. retaining the
>>    iterator pipe-operator operation pipe-operator ... sequence
>>
>> where we have three different pipe operators that, for the sake of
>> argument, might be:
>>
>>    |>  for Proceed currently handled by a value 0
>>   <|x  for exit pipeline back, currently <0, like C continue
>>    |x> for exit pipeline forward, currently >0, like C break
>
>>
>> But without thinking about it deeply I don't see how that would work as
>> the decision about which option to take is at run-time not compile-time.
>>
>> Whether this is managed by conditional jumps or possibly quotations ISTM
>> that there is always a choice of 1 from 3 has to be made at runtime.
>>
>> Or did you have another idea in mind?
>>
>
>
>I mean a compile-time decision. My arguments are as follows.
>
>1. In most use cases, you know at compile-time whether you need to
>continue or break the loop (I mean, in the case of a pipeline break).
>Then, it's better for readability to use different pipe-operators for
>these cases.
>
>2. For code reuse, it's better if an operation returns (and a
>pipe-operator accepts) a value of one of two disjoint types {0, x/0},
>rather than one of three disjoint types {0, +n/0, -n/0} (where 0 is a
>singleton {"0"}, and "\" means a set difference).
>
>
>If a pipe-operator distinguishes two types of the input value, two
>operators are enough. And if we use zero to break a pipeline, these
>operators can be defined via your "|>" as follows:
>
> : |>| ( 0|x -- ) postpone 0= postpone |> ; immediate
> : |<| ( 0|x -- ) postpone 0= postpone abs postpone |> ; immediate

Components of a pipe line must not contain logic to decide when to
stop. It should terminate as the input terminates.
So pipeline operators should marry a yield operation that produces a
stream of data, and decides termination.

>
>
>
>--
>Ruvim
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On 10/12/2023 21:05, Ruvim wrote:
> On 2023-12-09 00:49, Gerry Jackson wrote:
>> On 08/12/2023 10:47, Ruvim wrote:
>>> On 2023-12-08 12:11, Gerry Jackson wrote:
>>> [...]
>>>>
>>>> Two things about FOR-EACH I don't think I've yet mentioned.
>>>>
>>>> The pipeline operator is optional. Without it the whole thing
>>>> reverts to a BEGIN ... WHILE ... REPEAT loop with a small amount of
>>>> redundant code. So why use FOR-EACH, IMHO the FOR-EACH is arguably
>>>> more readable.
>>>>
>>>> The pipeline operator can make the FOR-EACH statement equivalent to
>>>> multi-WHILE loops without the drawbacks of ELSE parts being
>>>> separated in the source code.
>>>
>>> OTOH, FOR-EACH part is also optional. A pipeline operator can be used
>>> instead:
>>>
>>>    FOR-EACH TRUE DO[ next-item |> check-item |> process-item ]NEXT
>>>
>>> It's not obvious to me that placing "next-item" into a separate
>>> section rather than into the chain (like in this example) makes
>>> readability better.
>>
>> You're probably right, my intention was to highlight that the first
>> item had to be something that iterated through a collection. But
>> without thinking it through I guess that's a fairly minor change to
>> make. It would also eliminate the need for DO[
>>
>>>
>>> Also, I would use different operators to break and to continue the
>>> loop, instead of different signs of the input value.
>>>
>>
>> Do you mean three operators that could be placed between the pipeline
>> operations i.e. retaining the
>>     iterator pipe-operator operation pipe-operator ... sequence
>>
>> where we have three different pipe operators that, for the sake of
>> argument, might be:
>>
>>     |>  for Proceed currently handled by a value 0
>>    <|x  for exit pipeline back, currently <0, like C continue
>>     |x> for exit pipeline forward, currently >0, like C break
>
>>
>> But without thinking about it deeply I don't see how that would work
>> as the decision about which option to take is at run-time not
>> compile-time.
>>
>> Whether this is managed by conditional jumps or possibly quotations
>> ISTM that there is always a choice of 1 from 3 has to be made at runtime.
>>
>> Or did you have another idea in mind?
>>
>
>
> I mean a compile-time decision. My arguments are as follows.
>
> 1. In most use cases, you know at compile-time whether you need to
> continue or break the loop (I mean, in the case of a pipeline break).
> Then, it's better for readability to use different pipe-operators for
> these cases.
>
> 2. For code reuse, it's better if an operation returns (and a
> pipe-operator accepts) a value of one of two disjoint types {0, x/0},
> rather than one of three disjoint types {0, +n/0, -n/0}  (where 0 is a
> singleton {"0"}, and "\" means a set difference).

Why do you say that's better for code reuse?

>
>
> If a pipe-operator distinguishes two types of the input value, two
> operators are enough. And if we use zero to break a pipeline, these
> operators can be defined via your "|>" as follows:
>
>   : |>|  ( 0|x -- ) postpone 0= postpone |> ; immediate
>   : |<|  ( 0|x -- ) postpone 0= postpone abs postpone |> ; immediate
>

Thanks for that. I'm not convinced that your suggestion is better for
readability. Defining suitable constants for pipeline break and continue
might suffice.

However I will experiment with your suggestions, including removing DO[
so that the iterator is the start of the pipeline, when I get a bit more
time. I'm committed to doing some work on a website I help to maintain
for the next few weeks (programming in PHP) so it won't be until next year.

--
Gerry

On 13-12-2023 22:47, Gerry Jackson wrote:
OK, I made a high level Forth version WITH size.
You only get the address, that's it.

It's full of 4tH-isms, but I guess one will manage.

[UNDEFINED] foreach [IF]
\ 'f ( addr --)
: foreach ( 'f addr count size -- )
tuck * >r -rot r> bounds ?do
i over execute over ( size 'f size)
+loop drop drop ( --)
;

\ 'f ( st addr -- st')
: reduce ( st 'f addr count size -- st')
tuck * >r -rot >r rot r> r> bounds ?do
over i swap execute >r over r> swap
+loop nip nip ( st')
;

aka foreach map
[THEN]

struct
field: one
field: two
end-struct /bla

6 constant #bla

#bla /bla * array bla
[: dup bla - swap -> two ! ;] bla #bla /bla foreach
[: -> two ? ;] bla #bla /bla foreach depth . cr
[: -> two dup @ dup * swap ! ;] bla #bla /bla map depth . cr
[: -> two ? ;] bla #bla /bla foreach depth . cr
0 [: -> two @ + ;] bla #bla /bla reduce . depth .

Hans Bezemer

In article <nnd$46aa01b1$22ce9a16@98c43956ef3e3602>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>On 13-12-2023 22:47, Gerry Jackson wrote:
>OK, I made a high level Forth version WITH size.
>You only get the address, that's it.
>
>It's full of 4tH-isms, but I guess one will manage.
>
>[UNDEFINED] foreach [IF]
>\ 'f ( addr --)
>: foreach ( 'f addr count size -- )
> tuck * >r -rot r> bounds ?do
> i over execute over ( size 'f size)
> +loop drop drop ( --)
>;
>
>\ 'f ( st addr -- st')
>: reduce ( st 'f addr count size -- st')
> tuck * >r -rot >r rot r> r> bounds ?do
> over i swap execute >r over r> swap
> +loop nip nip ( st')
>;
>
>aka foreach map
>[THEN]
>
>struct
> field: one
> field: two
>end-struct /bla
>
>6 constant #bla
>
>#bla /bla * array bla
>[: dup bla - swap -> two ! ;] bla #bla /bla foreach
>[: -> two ? ;] bla #bla /bla foreach depth . cr
>[: -> two dup @ dup * swap ! ;] bla #bla /bla map depth . cr
>[: -> two ? ;] bla #bla /bla foreach depth . cr
>0 [: -> two @ + ;] bla #bla /bla reduce . depth .

If you show a test, show the result of the test.

>
>Hans Bezemer

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -