Oforth V0.9.24.1 released

[franck....@gmail.com]

Hello,

Oforth V0.9.24.1 is released. This version fixes minor bugs.
This version also adds some optimizations on native code generated.

Also, default is now to not generate data stack checks for underflow and
overflow (to generate them, use --C command line parameter).

For instance, with this version, the binarytree benchmark results are
(on a Core i7-4720HQ 2,60GHz running on Windows 10) :

With 1 core used : about 18,5 seconds elapsed :

oforth --P"#[ 20 binarytree ] bench" --W1 examples/binarytree.of
stretch tree of depth 21 check: -1
2097152 trees of depth 4 check: -2097152
524288 trees of depth 6 check: -524288
131072 trees of depth 8 check: -131072
32768 trees of depth 10 check: -32768
8192 trees of depth 12 check: -8192
2048 trees of depth 14 check: -2048
512 trees of depth 16 check: -512
128 trees of depth 18 check: -128
32 trees of depth 20 check: -32
long lived tree of depth 20 check: -1
18410821


With 4 cores used : about 6,5 seconds elapsed :

oforth --P"#[ 20 binarytree ] bench" --W4 examples/binarytree.of
stretch tree of depth 21 check: -1
2097152 trees of depth 4 check: -2097152
524288 trees of depth 6 check: -524288
131072 trees of depth 8 check: -131072
32768 trees of depth 10 check: -32768
8192 trees of depth 12 check: -8192
2048 trees of depth 14 check: -2048
512 trees of depth 16 check: -512
128 trees of depth 18 check: -128
32 trees of depth 20 check: -32
long lived tree of depth 20 check: -1
6376182

Franck
http://www.oforth.com

[Cecil Bayona]

Thanks for making the software available, but is there any chance the
the documentation will be worked on?

It hard to deal with a Forth that is different, but at the same time not
documented well.

--
Cecil - k5nwa

[Doug Hoffman]

Documentation is most always time consuming and not easy, though I agree
more needs to be done here.

Franck has already made quite a few fundamental changes to Oforth to
make it "less different" than classic Forth:

New definitions now start with : (used to be something else)
Definitions now end with ; (used to be something else)
Locals now use the same ordering as the new ANS Forth (used to be
backwards like locals| )
Several message names have been changed like . (dot) used to be
something else like print)

Again, I agree that better documentation would be nice right now, but
Franck is also working hard on improving the internals of Oforth and
keeping Oforth multi-platform source compatible. Pretty impressive so far!

-Doug

[Cecil Bayona]

It's appreciated, the hard work put into designing, coding, and testing
a complex piece of software. Documentation is not a fun thing to do,
it's boring compared to adding new features and seeing them work, but
for the software to be of much use to others documentation is vital.

Myself when I embark on a project I start with the documentation, to
clearly state my goals in the project and a general outline on how to
solve it. From there I maintain and keep the documentation up to date as
I write and test code, I found that documenting after the fact rarely
gets done in my case so I work that way to make sure that years later
the project is well documented.

Even in old projects not well documented, I would add the documentation
on added features as I made changes to the project so at least new
features were well documented, I usually found that once started it was
hard to stop and I would add documentation to other parts of a project,
eventually it was all documented.

Recently while going through stuff in the garage, I found the notebooks
on two projects I programmed over 10 years ago,, one in Forth, the other
in Delphi, it was not difficult to understand the projects by reading
the documentation, which was my purpose in setting that documentation
style for myself. Part of that documenting procedure is to document each
word or function as they are entered so the purpose of the module, the
input data, and the results are documented.

I have Oforth installed in my main two PCs so I could try it out, I been
looking for a tool that would work well in a project that I been mulling
over a few years, now that I'm retired I have more time so I been
thinking about it again. The project would involve massive text
manipulation so I figure text, list or even lowly linked list capability
would be a great help in the project. There are some non-Forth languages
available that have good tools in that area but I rather use Forth or
something based on the Forth ideas.
--
Cecil - k5nwa

[hughag...@gmail.com]

On Saturday, July 23, 2016 at 12:35:17 PM UTC-7, Cecil - k5nwa wrote:
> The project would involve massive text
> manipulation so I figure text, list or even lowly linked list capability
> would be a great help in the project.

That sounds like something my string-stack.4th list.4th and association.4th could be used for. I have an upgrade to string-stack. 4th with some minor bug fixes.

Can you tell us something about your project?

[hughag...@gmail.com]

On Saturday, July 23, 2016 at 11:05:37 AM UTC-7, Doug Hoffman wrote:
> Franck has already made quite a few fundamental changes to Oforth to
> make it "less different" than classic Forth:
>
> New definitions now start with : (used to be something else)
> Definitions now end with ; (used to be something else)
> Locals now use the same ordering as the new ANS Forth (used to be
> backwards like locals| )
> Several message names have been changed like . (dot) used to be
> something else like print)

Having the locals declarations backwards was what turned me of on Oforth --- maybe I will look at it again.

If Franck fixes the quotations so they have access to the parent function's local variables, then I will definitely be interested. :-) You can do it Franck! It is not that complicated!

[Cecil Bayona]

Basically a general purpose macro processor, it would take an input text
file, and a template for conversion and would proceed to apply the rules
in the templates to the source text and translate them, the translated
output could be optionally be translated again until it runs out of
rules that apply.

In the Forth universe the Forth compiler name "Timbre" and somewhat does
what I want, but I'm not happy with the documentation and the fact that
it is written in "C" without comments, so in case of future problems I
am in a weak position to be able to fix it. Timbre has the advantage
that the conversion templates can include Forth code to help in the
conversion process.
< http://clubweb.interbaun.com/~rc/Timbre/index.html >

A long time ago I used a package called "Stage2", it was written in
Fortran, I used it to translate itself into assembler and that version
was used in several projects to 100% translate "C" code to Turbo Pascal,
and Forth to assembler, it worked quite well, one would write a set of
translating rules and they would convert source text to a final form.
<
http://dl.acm.org/citation.cfm?id=362691&dl=ACM&coll=DL&CFID=817177146&CFTOKEN=99137370
>

I was a conundrum, it was very primitive Fortran code that treated a
source file as a giant character list, yet it allowed you to do some
very sophisticated conversions, for example; I created a fully working
Forth Translator that supported the complete Forth language at the time,
including defining other words, and creating code words. This was in the
70's when I last worked with it.

Another program I have used in a similar vein is "Gema".
< http://gema.sourceforge.net/new/index.shtml >

--
Cecil - k5nwa

[franck....@gmail.com]

Hello,

You are right. And I agree that this is very important.

Currently, I'am focused on Oforth V1.0 version (and its documentation)
but I will release the doc first.

Did you run all the tutorials ?

Franck

[franck....@gmail.com]

Thank you, Doug.

Having now Oforth mainly written in Oforth itself helps a lot, here.
But yes, this is still very time consuming :)

That is why I'am waiting to have most code written in Oforth before
releasing the ARM version (and Oforth sources).

Franck

[franck....@gmail.com]

Quotations have access to parent local, but these locals can't be updated
(quotations hold a copy of these values).

Yes, that is not complicated to allow this. In fact it would be simpler
(no need to copy the values).

But not being able to update parent locals is an intentional choice as
this would be a huge break in task isolation in a multi-threading context
as one task could update a value seen by another task if the quotation is
shared.

Oforth has no mutex, no semaphore, ... nothing but channels to synchronize
tasks. It is required that 2 tasks can't update the same object
simulteanously. If quotations are allowed to update parent locals, everything
collapses.

In fact, this would break a lot of Oforth principles (immutability,
isolation, ....).

And, even without this problem, imo, what quotations really need is to see
parent locals, but not to be able to update them. At least, I have never feel
the need to this.

Franck.

[Cecil Bayona]

I understand, V1.0 is an important milestone that you are working hard
to accomplish so I'm being patient and waiting.

I did not go through quite all the tutorials, after a little bit I tried
to make a simple tutorial of my own to test some concepts in simple
string and list conversions and didn't get anywhere as some of the words
I "think" I would need were not documented so the only choice I had was
to pour through the source code to figure it all out, and since the
software right now is in the state of flux I figure if I had to go
through that effort I will wait a while until things settle down. I'm
thinking that V1.0 will bring additional changes ,so now it's better to
wait a bit and see what happens.

In the meantime, I keep looking for something that will accomplish what
I'm looking for, so far two pieces of software look promising ( Timbre,
and 8th ) but I have my own long term objections to both of them.

With Timbre is the lack of decent documentation, and I have known about
it for years with no change to the documentation so waiting any further
is a lost cause, a shame since it's pretty close to what I want.

8th looks like it's totally capable of doing what I want so I can create
my own application, it is well documented, and has great support for
multiple OSes but it's a software rental item, $100 a year to keep it
functional for non-commercial use. I could live with a software
maintenance fee to keep the software updated but they have it so the
software becomes crippled if you don't pay every 6 months, that is hard
to swallow. It's their software so they can do as they want, but it's my
money and I can do as I want.

I'm totally against renting software on general principles, it would
encourage others to do the same. Divx was in a similar position, it
wanted to push the idea that one doesn't own a movie but rents it for x
number of viewings then you have to buy it again, I prayed that the
concept would die before others started doing the same, and happily that
concept is no longer with us.

I have tried several offshoots of Forth so that things are getting a
little mixed up as to what software has what features. So maybe I need
to repeat the process, and document the findings so I don't forget where
all the various versions of Forth stand. One thing I do want to have are
mutable list items, which from reading Oforth does not have that but I
could be mistaken so I will wait until the new version comes out.


--
Cecil - k5nwa

[franck....@gmail.com]

Even if immutability is a key concept in Oforth, mutable list exist
(and are sometimes more suitable than immutable objects).

They are instances of ListBuffer class.
(and mutable strings are instances of StringBuffer).

You can find a reference of all words defined at startup
(including ListBuffer methods) here : http://www.oforth.com/lang.html

I doubt that those words will change a lot with V1.0

Basically, you can create a new list using :
ListBuffer new
or
n ListBuffer newSize

If you know what will be the list size, it is better to use #newSize to
avoid the list to be resized for nothing.

Then you can add new elements using #add method :
aListBuffer add ( x -- )

or update elements using #put :
aListBuffer put ( i y -- )

The list will automatically be resized if necessary.


For instance, this is how #zipWith is implemented, using a ListBuffer :

Indexable method: zipWith( coll r -- aList )
| i |
self size coll size min dup ListBuffer newSize swap
loop: i [ i coll at i self at r perform over add ]
dup freeze ;

[ 1 , 2 , 3 ] #[ + 1+ ] [ 4 , 5 , 6 ] zipWith .
[6, 8, 10] ok


Franck

[Cecil Bayona]

On 7/24/2016 2:42 PM, franck....@gmail.com wrote:
> Le dimanche 24 juillet 2016 19:44:32 UTC+2, Cecil - k5nwa a écrit :

>> I did not go through quite all the tutorials, after a little bit I tried
>> to make a simple tutorial of my own to test some concepts in simple
>> string and list conversions and didn't get anywhere as some of the words
>> I "think" I would need were not documented so the only choice I had was
>> to pour through the source code to figure it all out, and since the
>> software right now is in the state of flux I figure if I had to go
>> through that effort I will wait a while until things settle down. I'm
>> thinking that V1.0 will bring additional changes ,so now it's better to
>> wait a bit and see what happens.
>>

>>

>> I have tried several offshoots of Forth so that things are getting a
>> little mixed up as to what software has what features. So maybe I need
>> to repeat the process, and document the findings so I don't forget where
>> all the various versions of Forth stand. One thing I do want to have are
>> mutable list items, which from reading Oforth does not have that but I
>> could be mistaken so I will wait until the new version comes out.
>>
>>
>> --
>> Cecil - k5nwa
>
> Even if immutability is a key concept in Oforth, mutable list exist
> (and are sometimes more suitable than immutable objects).

Good to hear, I vaguely remembered that there was a way to get list of
items and be mutable, so maybe my documenting this information is needed
to avoid getting the different Forth systems that I been looking at
mixed up.

>
> They are instances of ListBuffer class.
> (and mutable strings are instances of StringBuffer).
>
> You can find a reference of all words defined at startup
> (including ListBuffer methods) here : http://www.oforth.com/lang.html
>

Unfortunately for me, that list rarely list what the expected parameters
are. Also some basic items are not defined, for example what is a
"receiver" in some cases I gather that it is the top of the stack, but
in some items I'm not sure.

> I doubt that those words will change a lot with V1.0
>
> Basically, you can create a new list using :
> ListBuffer new
> or
> n ListBuffer newSize
>
> If you know what will be the list size, it is better to use #newSize to
> avoid the list to be resized for nothing.
>
> Then you can add new elements using #add method :
> aListBuffer add ( x -- )
>
> or update elements using #put :
> aListBuffer put ( i y -- )

I will not know how big a list is until the code is actually reading the
input text, so I planned to declare the "ListBuffer" at a reasonable
size and then grow as needed, in most cases it will not need to grow.
The one ListBuffer will keep getting reused so as it grows the chances
of it needing to grow will diminish.

My plan is to parse a set of code into the list, then proceed to process
it looking for patterns and doing substitution of the text. If
processing Forth as an example, I would load an entire word definition
into the list array and process it as a whole entity, it may not be the
best way but it's a way I have done before and worked well.

The goal would be to use templates to optimize the word definition and
then generate optimized assembler code to be compiled as the final result.

In the past I used a similar method to translate languages, and to
optimize the Forth code and generate code for various CPU chips. The
process would first optimize the forth code to an internal form using
special optimized micro ( quarks ) primitives that translate well to
assembler then those optimized primitives would be translated to
assembler code for the specific CPU. Not only did it generate decent
code but I was able to easily modify it to work with several CPUs. The
thing is one can start simple with few templates but as one adds more
templates the code generated keeps improving.

>
> The list will automatically be resized if necessary.
>
>
> For instance, this is how #zipWith is implemented, using a ListBuffer :
>
> Indexable method: zipWith( coll r -- aList )
> | i |
> self size coll size min dup ListBuffer newSize swap
> loop: i [ i coll at i self at r perform over add ]
> dup freeze ;
>
> [ 1 , 2 , 3 ] #[ + 1+ ] [ 4 , 5 , 6 ] zipWith .
> [6, 8, 10] ok
>
>
> Franck
>

--
Cecil - k5nwa

[hughag...@gmail.com]

On Sunday, July 24, 2016 at 3:40:12 AM UTC-7, franck....@gmail.com wrote:
> Le samedi 23 juillet 2016 23:09:47 UTC+2, hughag...@gmail.com a écrit :
> > If Franck fixes the quotations so they have access to the parent function's local variables, then I will definitely be interested. :-) You can do it Franck! It is not that complicated!
>
> Quotations have access to parent local, but these locals can't be updated
> (quotations hold a copy of these values).
>
> Yes, that is not complicated to allow this. In fact it would be simpler
> (no need to copy the values).
>
> But not being able to update parent locals is an intentional choice as
> this would be a huge break in task isolation in a multi-threading context
> as one task could update a value seen by another task if the quotation is
> shared.

You're worrying about nothing! Quotations aren't going to be shared.

Look at this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B126-150%5D

I said that the rules are:
1.) A HOF calls a quotation with REX.
2.) A HOF can not call another HOF.

So how would a quotation be shared?

> Oforth has no mutex, no semaphore, ... nothing but channels to synchronize
> tasks. It is required that 2 tasks can't update the same object
> simulteanously. If quotations are allowed to update parent locals, everything
> collapses.
>
> In fact, this would break a lot of Oforth principles (immutability,
> isolation, ....).

I would like to get multi-core support similar to Oforth in Straight Forth --- I'm not clear on how to do this, so maybe you are right, but I doubt it --- if quotations can't be supported along with multi-core support though, then I would just forget about multi-core support because quotations are more important.

Straight Forth is primarily intended to be a platform for a cross-compiler, so I don't need multi-core support for this. Can Oforth be used for this? From what I've seen of it, the answer is no.

Straight Forth is also intended to be used for numeric programs --- this could benefit from multi-core support in the cases where multiple calculations can be done in parallel because they don't use the result(s) of the other calculation(s) as arguments --- these cases are pretty rare though, so multi-core support may not be all that important.

The only thing I can think of multi-core support being really useful for, is searching. If you are going to search through data for a match, you might as well let each core search part of the data and do this in parallel. There are also some inherently parallel programs, such as the Life game, but I've never seen any that had any real-world value. What do you use multi-core support for in oForth?

> And, even without this problem, imo, what quotations really need is to see
> parent locals, but not to be able to update them. At least, I have never feel
> the need to this.

The whole point of having quotations is that they can upfeed data to the parent function! If you are not going to have that, then you might as well not have quotations at all --- just use regular functions.

Look at that thread I provided the link for --- look at my hottie-counting program --- how would you do that in Oforth without using global variables?

Of course, if you use global variables, your immutability and isolation are lost, which you described as "Oforth principles." Immutability and isolation are ideals, but they are going to be lost in a lot of cases --- it is better to use rquotations and local variables than to use global variables --- if you use global variables then you have no idea which functions might be modifying them and you have completely lost control.

[Ron Aaron]

On 24/07/2016 20:44, Cecil Bayona wrote:

> 8th looks like it's totally capable of doing what I want so I can create
> my own application, it is well documented, and has great support for
> multiple OSes but it's a software rental item, $100 a year to keep it
> functional for non-commercial use. I could live with a software
> maintenance fee to keep the software updated but they have it so the
> software becomes crippled if you don't pay every 6 months

That is factually incorrect, Cecil.

8th's license is only for building binary applications. If you pay the
license, you can create encrypted binary applications. If you do not,
you cannot. THAT is the only difference between paying for a license
and not paying.

Hardly "crippled", IMO.

[Cecil Bayona]

My understanding is that you cannot generate a stand alone application
once the 6 month license expires encrypted or not, please correct me if
I am wrong. Without being able to generate a stand alone application
it's of limited use in my case, as mostly I would occasionally used it
to write simple tools for the most part.

I would create an small applications once in a blue while, so I might
have the opportunity to create one small application or two before the
expiration period times out.

Since I'm retired due to health issues my income is severely restricted,
$100 might not seem like much but I have little discretionary income,
actually until the end of the year I have no clue how I will make my
income meet my expenses due to my Insurance company only paying for my
medicine for part of the year so starting next week I have to pay for my
medicines myself.

A shame as I like your software, for simple applications any Forth would
do if it can generate stand alone code and there are several Forth
capable of doing that. The main application where your software would
shine is not so simple so it might take more than 6 month to create it
and work out the bugs.



--
Cecil - k5nwa

[Ron Aaron]

On 25/07/2016 07:28, Cecil Bayona wrote:

> My understanding is that you cannot generate a stand alone application
> once the 6 month license expires encrypted or not, please correct me if
> I am wrong. Without being able to generate a stand alone application
> it's of limited use in my case, as mostly I would occasionally used it
> to write simple tools for the most part.

You do understand correctly. However, you can use 8th in 'script mode',
e.g. invoke '8th your-script.8th' for as long as you want. It's not a
standalone executable, but for applications you yourself use (or on a
server, etc) it is probably just as useful.

> I would create an small applications once in a blue while, so I might
> have the opportunity to create one small application or two before the
> expiration period times out.

Tell me: would a "reduced version" (e.g. without the ability to create
encrypted binaries, perhaps without bluetooth support etc) of 8th be
something that would be attractive (at a one-time purchase, not a
subscription)? Please contact me (at the email you know) to discuss
further if so.

> A shame as I like your software, for simple applications any Forth would
> do if it can generate stand alone code and there are several Forth
> capable of doing that. The main application where your software would
> shine is not so simple so it might take more than 6 month to create it
> and work out the bugs.

Understood.

[Paul Rubin]

Ron Aaron <ramb...@gmail.com> writes:
> Tell me: would a "reduced version"... be attractive (at a one-time
> purchase, not a subscription)?

I also see the subscription scheme as annoying and think there should be
a one-time price for the current full version, with subscriptions
available for support and updates. That's how most other software
products work, including the main commercial Forths if I understand
correctly. Even if you have to raise prices to make up for lost
subscription revenue, a one-time price will likely lead to less customer
dissatisfaction.

[Cecil Bayona]

On 7/24/2016 11:45 PM, Ron Aaron wrote:
>
>
> On 25/07/2016 07:28, Cecil Bayona wrote:
>
>> My understanding is that you cannot generate a stand alone application
>> once the 6 month license expires encrypted or not, please correct me if
>> I am wrong. Without being able to generate a stand alone application
>> it's of limited use in my case, as mostly I would occasionally used it
>> to write simple tools for the most part.
>
> You do understand correctly. However, you can use 8th in 'script mode',
> e.g. invoke '8th your-script.8th' for as long as you want. It's not a
> standalone executable, but for applications you yourself use (or on a
> server, etc) it is probably just as useful.
>
>> I would create an small applications once in a blue while, so I might
>> have the opportunity to create one small application or two before the
>> expiration period times out.
>
> Tell me: would a "reduced version" (e.g. without the ability to create
> encrypted binaries, perhaps without bluetooth support etc) of 8th be
> something that would be attractive (at a one-time purchase, not a
> subscription)? Please contact me (at the email you know) to discuss
> further if so.

Interesting, but yes, encryption of an application is not vital at all
but creating a simple binary application would be necessary. Bluetooth
is little use currently as far as I can see, but depending on what else
is left out it could be workable. For example access to Networking would
be vital as some simple applications could be servers or clients
listening to the network, so would access to the OS would be necessary.
I will send you an email tomorrow, it's very late here, and I have a
doctors appointment early in the morning.

>
>
>> A shame as I like your software, for simple applications any Forth would
>> do if it can generate stand alone code and there are several Forth
>> capable of doing that. The main application where your software would
>> shine is not so simple so it might take more than 6 month to create it
>> and work out the bugs.
>
> Understood.
>

--
Cecil - k5nwa

[Ron Aaron]

On 25/07/2016 07:58, Paul Rubin wrote:

> I also see the subscription scheme as annoying and think there should be
> a one-time price for the current full version, with subscriptions
> available for support and updates. That's how most other software
> products work, including the main commercial Forths if I understand
> correctly. Even if you have to raise prices to make up for lost
> subscription revenue, a one-time price will likely lead to less customer
> dissatisfaction.

Thanks, Paul. We'll look at this very closely.

[Ron Aaron]

On 25/07/2016 08:05, Cecil Bayona wrote:

> Interesting, but yes, encryption of an application is not vital at all
> but creating a simple binary application would be necessary. Bluetooth
> is little use currently as far as I can see, but depending on what else
> is left out it could be workable. For example access to Networking would
> be vital as some simple applications could be servers or clients
> listening to the network, so would access to the OS would be necessary.
> I will send you an email tomorrow, it's very late here, and I have a
> doctors appointment early in the morning.

OK, thank you. Be well.

[franck....@gmail.com]

Le dimanche 24 juillet 2016 22:43:06 UTC+2, Cecil - k5nwa a écrit :
> Unfortunately for me, that list rarely list what the expected parameters
> are. Also some basic items are not defined, for example what is a
> "receiver" in some cases I gather that it is the top of the stack, but
> in some items I'm not sure.
>

The receiver is a concept used with OOP.

It is the "this" of some languages (C++, java, ...) or the
"self" of others (Smalltalk, Oforth, ...).

In Oforth, in order to implement OOP metamodel, there are different
kind of words.

1) Functions are the classical Forth words and they are declared the
same way. With functions, there is no receiver.

For instance :

: dist // ( a b -- f )
sq swap sq + sqrt ;


2) Methods are words that can have multiple implementations.
The implementation to run is choosen according to the top of the stack
when the method is called.
- This TOS is what is called the receiver.
- When the method is called, the receiver is removed from the stack.
- Into the method body, you can push back the receiver on the stack using "self".

You can think at the receiver as a parameter called "self" that is implicitely
declared on all methods.

If other parameters are needed, they are under the receiver.

For instance, #add is a method.
The signature for ListBuffer implementation is :
( x aListBuffer -- )
and the listbuffer will be the receiver.

ListBuffer new 10 over add 12 over add .
[10, 12] ok

You can find more informations into the first tutorial
(chapter X - Methods and polymorphism )

Franck

[franck....@gmail.com]

Le lundi 25 juillet 2016 04:09:11 UTC+2, hughag...@gmail.com a écrit :
>
> You're worrying about nothing! Quotations aren't going to be shared.
>
> Look at this thread:
> https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B126-150%5D
>
> I said that the rules are:
> 1.) A HOF calls a quotation with REX.
> 2.) A HOF can not call another HOF.
>
> So how would a quotation be shared?
>

Well, what can I say ? I'am not worrying about nothing as, in Oforth,
quotations can be shared.
These rules are simply not Oforth rules for the quotations.

If you write :
#[ 10 . ] &
the quotation will be performed in parallel into a separated task.

If you write :
#[ 10 . ] dup &
the quotation is now shared between two tasks.

And if you write :

: test( a -- b )
#[ 10 ->a a . ] &
12 ->a
a ;

If the quotation could update parent local, you couldn't tell what is
the value returned by #test (it could be 10 or 12) nor the value printed
by the other task (it could be 10 or 12).

> I would like to get multi-core support similar to Oforth in Straight Forth --- I'm not clear on how to do this, so maybe you are right, but I doubt it --- if quotations can't be supported along with multi-core support though, then I would just forget about multi-core support because quotations are more important.
>
> Straight Forth is primarily intended to be a platform for a cross-compiler, so I don't need multi-core support for this. Can Oforth be used for this? From what I've seen of it, the answer is no.
>
> Straight Forth is also intended to be used for numeric programs --- this could benefit from multi-core support in the cases where multiple calculations can be done in parallel because they don't use the result(s) of the other calculation(s) as arguments --- these cases are pretty rare though, so multi-core support may not be all that important.

If you target desktops or servers, a multi-threading support is more
important than quotations. Unless you dedicate your language for
cross compilation, of course.

> The only thing I can think of multi-core support being really useful for, is searching. If you are going to search through data for a match, you might as well let each core search part of the data and do this in parallel. There are also some inherently parallel programs, such as the Life game, but I've never seen any that had any real-world value. What do you use multi-core support for in oForth?

Multi-threading is used a lot when you write servers (TCP, HTTP, REST, ...)

> > And, even without this problem, imo, what quotations really need is to see
> > parent locals, but not to be able to update them. At least, I have never feel
> > the need to this.
>
> The whole point of having quotations is that they can upfeed data to the parent function! If you are not going to have that, then you might as well not have quotations at all --- just use regular functions.

No, I don't think so. Upfeeding data to the parent function is, at best,
a minor feature. I have written a lot of quotations and closure and never
feel the need of this.

> Look at that thread I provided the link for --- look at my hottie-counting program --- how would you do that in Oforth without using global variables?
>
> Of course, if you use global variables, your immutability and isolation are lost, which you described as "Oforth principles." Immutability and isolation are ideals, but they are going to be lost in a lot of cases --- it is better to use rquotations and local variables than to use global variables --- if you use global variables then you have no idea which functions might be modifying them and you have completely lost control.

This is not allowed in Oforth. There is no way to define a global
variable shared by different tasks.

VARIABLE word does not exist in Oforth. It is designed to forbid
the lost of immutability and isolation between tasks.
Allowing update of parent local would break this.

Franck

[endlessboo...@gmail.com]

https://www.youtube.com/watch?v=rqYnvrjrKIA