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

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

RfD: new double syntax

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

Contents

  RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-01 17:18 +0000
    Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 11:45 -0700
      Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-01 14:46 -0400
    Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-01 11:47 -0700
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:54 +0000
    Re: RfD: new double syntax mhx@iae.nl - 2016-07-01 11:48 -0700
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:52 +0000
    Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-01 09:10 -1000
      Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 19:10 -0700
        Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 06:23 +0000
    RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-01 20:54 -0700
      RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-01 21:18 -0700
        Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 22:26 -0700
          Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 22:32 +0000
            Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 01:16 -0400
              Re: RfD: new double syntax Ron Aaron <rambamist@gmail.com> - 2016-07-03 08:34 +0300
                Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 03:00 -0400
                  Re: RfD: new double syntax Ron Aaron <rambamist@gmail.com> - 2016-07-03 10:20 +0300
                  Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 08:29 +0000
              Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 23:10 -0700
                Re: RfD: new double syntax Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-02 23:20 -0700
                  Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 03:02 -0400
        Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:20 +0000
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:11 +0000
    Re: RfD: new double syntax josv@planet.nl - 2016-07-02 00:26 -0700
      Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-01 22:22 -1000
        Re: RfD: new double syntax "HAA" <someone@microsoft.com> - 2016-07-02 22:02 +1000
          Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-02 11:19 -1000
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:02 +0000
    Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-02 04:03 -0500
      Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 13:44 +0000
        Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 07:38 -0700
          Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 07:42 -0700
          Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 22:44 +0000
        Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-02 09:58 -0500
        Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-02 11:32 -1000
        Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-03 00:27 +0000
        Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 08:05 -0700
        Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 03:50 -0500
          Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 03:53 -0500
    Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 17:32 +0000
      Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-02 10:52 -0700
        Re: RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-02 13:03 -0700
        Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 15:02 +0000
          Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-03 11:18 -0700
            Re: RfD: new double syntax Coos Haak <chforth@hccnet.nl> - 2016-07-03 21:19 +0200
      Re: RfD: new double syntax Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-03 11:36 +0100
        Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-03 06:58 -0700
          Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 14:21 +0000
            Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-03 07:55 -0700
            Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-03 08:08 -0700
              Dealing with multiple recognizers (was: RfD: new double syntax) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 15:13 +0000
                Re: Dealing with multiple recognizers (was: RfD: new double syntax) hughaguilar96@gmail.com - 2016-07-03 09:57 -0700
            Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-05 01:12 -0400
              Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-05 07:56 -0700
                Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-05 11:18 -0400
          Re: RfD: new double syntax JennyB <jennybrien@googlemail.com> - 2016-07-03 08:15 -0700
          Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-03 12:42 -0500
            Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-03 09:32 -1000
              Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 07:34 -0700
            Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-04 10:35 -0700
            Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-04 09:00 -0700
              Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 09:51 -0700
            Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 11:20 -0500
              Re: RfD: new double syntax Howerd <howerdo@yahoo.co.uk> - 2016-07-06 04:08 -0700
                Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-06 06:24 -0500
                  Re: RfD: new double syntax Alex McDonald <alex@rivadpm.com> - 2016-07-06 12:38 +0100
                    Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-06 06:46 -0500
                  Re: RfD: new double syntax Howerd <howerdo@yahoo.co.uk> - 2016-07-06 13:37 -0700
                    Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-07 03:28 -0500
                      Re: RfD: new double syntax Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-04 23:59 +0000
                        Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-04 19:26 -0500
                      Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-04 17:34 -0700
                        Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-05 02:57 -0700
                          Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-05 13:15 -0700
                            Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-06 01:56 -0700
                              Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-07 17:22 -0700
                                Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-08 04:56 -0700
                                  Re: RfD: new double syntax josv@planet.nl - 2016-08-08 08:50 -0700
                                    Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-08 12:26 -0700
                                      Re: RfD: new double syntax josv@planet.nl - 2016-08-08 15:41 -0700
                                        Re: RfD: new double syntax mhx@iae.nl - 2016-08-08 23:06 -0700
                                          Re: RfD: new double syntax josv@planet.nl - 2016-08-09 00:57 -0700
                                        Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-09 03:05 -0700
                                          Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-08-10 01:46 -0700
                                  Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-10 19:07 -0700
                                    Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-11 05:24 -0700
                          Re: RfD: new double syntax josv@planet.nl - 2016-08-06 04:50 -0700
                        Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-05 12:01 -0500
            Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-04 08:51 -0500
            Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 04:03 -0500
        Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 14:56 +0000
          Re: RfD: new double syntax Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-03 22:00 +0100

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

#49886

In your previous message you claim yo be able to run 10000 tasks parallel.
When I played with parallel execution In Win32Forth ( on a i7) I came to the conclusion that it makes no sense to run more  parallel tasks parallel than the number of hardware threads that are present in the CPU, in order to gain speed.

So I  became interested in your system when you told us that you ran 10000 tasks.

The only thing that remains interesting is the distribution of a large task over several threads.
I guess Oforth has solved that also.

In Win32Forth one can use:  Parallel: ( limit IndexLow cfa -- ) 
After which the large task is distributed over all the initialized threads or all the hardware threads.

Jos

On August 8th, 2016 21:26:50 UTC+2 franck....@gmail.com wrote:
> Le lundi 8 août 2016 17:50:28 UTC+2, jo...@planet.nl a écrit :
> > > (but I don't like to directly expose the cores at the API level).
> > 
> > How many cores does your system have?
> > 
> > Jos
> > 
> 
> You mean my laptop ?
> 
> I'm not sure to understand how this is related to my previous post but
> it is a Core i7 with 4 physical cores and 8 threads (hyperthreading). 
> (when I ask the OS how many processors the system have, it answers 8).
> 
> Franck

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

#49889

On Tuesday, August 9, 2016 at 12:41:58 AM UTC+2, jo...@planet.nl wrote:
> In your previous message you claim yo be able to 
> run 10000 tasks parallel.
> When I played with parallel execution In Win32Forth
> ( on a i7) I came to the conclusion that it makes 
> no sense to run more  parallel tasks parallel than
> the number of hardware threads that are present in
> the CPU, in order to gain speed.

That is one aspect of it. When programming a large application
like a MIDI sequencer, it would make sense to design each 
widget as a separate task and let them run all of the time.

Even on a desktop Forth it may make sense to have separate
tasks that process stdin, stdout and stderr, or do file
input / output or graphics processing. WORDS could be
a background task that optimizes the hash function depending
on use, or rearranges the LRU mechanism when it has nothing
else to do.

-marcel

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

#49896

I agree. 
But I don't think you would use 10000 tasks to handle one activity.

Jos

On Tuesday, August 9, 2016 08:06:31 UTC+2 m...@iae.nl wrote:
> On Tuesday, August 9, 2016 at 12:41:58 AM UTC+2, jo...@planet.nl wrote:
> > In your previous message you claim yo be able to 
> > run 10000 tasks parallel.
> > When I played with parallel execution In Win32Forth
> > ( on a i7) I came to the conclusion that it makes 
> > no sense to run more  parallel tasks parallel than
> > the number of hardware threads that are present in
> > the CPU, in order to gain speed.
> 
> That is one aspect of it. When programming a large application
> like a MIDI sequencer, it would make sense to design each 
> widget as a separate task and let them run all of the time.
> 
> Even on a desktop Forth it may make sense to have separate
> tasks that process stdin, stdout and stderr, or do file
> input / output or graphics processing. WORDS could be
> a background task that optimizes the hash function depending
> on use, or rearranges the LRU mechanism when it has nothing
> else to do.
> 
> -marcel

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

#49901

Le mardi 9 août 2016 00:41:58 UTC+2, jo...@planet.nl a écrit :
> In your previous message you claim yo be able to run 10000 tasks parallel.

This theorical example was not to demonstrate gain speed, of course.
It was only to calculate memory used when you run 10000 tasks.

> When I played with parallel execution In Win32Forth ( on a i7) I came to the conclusion that it makes no sense to run more  parallel tasks parallel than the number of hardware threads that are present in the CPU, in order to gain speed.
>

It depends of what your tasks are doing. If some tasks are waiting for I/O
or sleeping, ... it makes perfectly sense to have more tasks than the 
number of hardware cores.

A server (TCP, HTTP, ...) that creates one task by request can create hundreds 
(even thousands) of tasks per seconds.

Even a browser running on a laptop can create hundred of tasks/threads.
(my firefox with 7 tabs open runs more than 100 threads).

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

#49919

On Tuesday, August 9, 2016 at 3:05:57 AM UTC-7, franck....@gmail.com wrote:
> Le mardi 9 août 2016 00:41:58 UTC+2, jo...@planet.nl a écrit :
> > In your previous message you claim yo be able to run 10000 tasks parallel.
> 
> This theorical example was not to demonstrate gain speed, of course.
> It was only to calculate memory used when you run 10000 tasks.

Reading about Oforth makes me increasingly dubious that I will be able to support multi-core system in Straight Forth comparable to Oforth.

I would like to support multi-core processors. Maybe I will do this in a very limited way. I could allow the programmer to define a quotation and run it on a separate processor in parallel with the main code being run on the main program. I would have to require this to be a restricted kind of quotation --- not a typical quotation --- it would have its own rules for what it is allowed to do (not access global memory). Most, perhaps all, of these parallel quotations would be short and would do numeric calculations. I would likely not bother with multi-tasking such as Franck is doing, but would only run the restricted quotations in parallel if there are few enough that they can be run on separate cores, but otherwise they would just be run sequentially --- you are not going to have 10,000 of them --- you are going to have 2, 3 or 4 of them.

I don't see Straight Forth competing directly against Oforth because my goals are much different from Franck's. Straight Forth is primarily for cross-compiling of Forth to micro-controllers, and secondarily for numeric programs using 64-bit fixed-point with an assumed unity of 2^32 --- most of these would be CAM (Computer-Aided Manufacture), meaning that they generate gcode programs for CNC machines. By comparison, Oforth is a big language competing against Common Lisp and all of the Lisp-derivative languages (Python, Ruby, Factor, etc.).

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

#49937

franck.bensusan@gmail.com writes:
> Even if it is not bad, I don't see any reason to choose this model 
> compared to immutability + incremental GC.

Incremental GC schemes usually require doing a "big" (slow) GC once in a
while.  Do you avoid that somehow?

> Oforth has a small task/channel model that also allows to run big amount
> of tasks in parallel with limited memory.

Oh I didn't know that.  It's good to find out.  For some reason I
thought Oforth used threads for concurrency.

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

#49952

Le jeudi 11 août 2016 04:07:17 UTC+2, Paul Rubin a écrit : 
> Incremental GC schemes usually require doing a "big" (slow) GC once in a
> while.  Do you avoid that somehow?

I don't know about this "big" GC that occurs once in a while related to 
an incremental scheme. This does not exist in Oforth. I'd be
interested to know why some incremental schemes need this "big" GC.

Oforth actually has two different GC, but this is not related to
the fact that they are incremental or not. They are related to
optimization using immutability of objects. They were there long before 
the GC has switched to an incremental GC.

There is a restrict GC that runs every 120 ms. This GC takes into
account that attributes of an immutable object can't change and they
are not checked (neither marked not sweep).

And there is a global GC that checks all objects whether they are 
immutable or not. It occurs every 10 restrict GC.

Those two kind of GC are incremetal and allow the tasks to run between 
each step.


For instance, with the binarytree benchmark, on a Core i7, with 4 workers, 
elapsed time is about 6,3 seconds. 

Each restrict GC duration is about 15/20 milliseconds every 120 ms and each
GC step is about 100 microseconds (with the tasks running between each step,
which is included into those 15 milliseconds).

Each global GC duration is about 45/50 milliseconds every 1200 ms 
The mark phase is much more longer than with a restrict GC.
Each GC step is also 100 microseconds.


> > Oforth has a small task/channel model that also allows to run big amount
> > of tasks in parallel with limited memory.
> 
> Oh I didn't know that.  It's good to find out.  For some reason I
> thought Oforth used threads for concurrency.

Yes, Oforth will automatically create new workers (threads) if needed, but
won't create more workers than number of cores available (or no more than n
where n is the value of --Wn command line option). 
All resumable tasks can run on any worker available (even if it is not the 
worker that created the task). 

Franck

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

#49812

Hi,
In order not to forget the release I often use:
: LockExecute  ( cfa lock - ) dup>r lock execute  r> unlock ;

Jos

On August 5th, 2016 11:57:39 UTC+2 franck....@gmail.com wrote:
> Le vendredi 5 août 2016 02:34:46 UTC+2, Paul Rubin a écrit :
> > The situation seems to be that it's clean and it works, but the slowdown
> > gets bad once there are lots of cores and lots of contention.  I've been
> > hearing of some improved approaches, but who knows.
> > 
> > [Some of] the Erlang guys have felt for a long while that shared memory
> > is ultimately doomed, as core counts increase and cache interlocks get
> > more and more complicated.  So they want to use message passing for
> > everything.  OTOH the current BEAM (Erlang) VM uses message passing for
> > small objects, but (limited) shared memory for certain large ones.
> 
> Hi,
> 
> imo, what is doomed is not shared memory but shared mutable memory.
> 
> In Oforth, an object can be shared between tasks only if it is immutable.
> So there is no need for locks, mutex, ...
> 
> But I find Erlang principles quite conservative as they copy each object
> they pass to another task. Even if I understand the benefits, I can't 
> resign myself to this...
> 
> For me, being able to share immutable objects between tasks without the need 
> of copy them seems a good trade-off.
> 
> Franck

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

#49802

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> But TM hasn't caught on as I would have expected.
> 
> The situation seems to be that it's clean and it works, but the slowdown
> gets bad once there are lots of cores and lots of contention.

Sure, but that's inevitable anyway, surely.  Once you have lots of
contention and large transactions you're in trouble.  The trick with
shared-memory transactions is the same as the trick with anything
else: immutable data where possible, small shared state.  The
transactions themselves are small.

> I've been hearing of some improved approaches, but who knows.
> 
> [Some of] the Erlang guys have felt for a long while that shared memory
> is ultimately doomed, as core counts increase and cache interlocks get
> more and more complicated.  So they want to use message passing for
> everything.  OTOH the current BEAM (Erlang) VM uses message passing for
> small objects, but (limited) shared memory for certain large ones.

And that last approach makes perfect sense.

Andrew.

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

#48787

On 7/4/2016 4:03 AM, Andrew Haley wrote:
> Cecil Bayona <cbayona@cbayona.com> wrote:
>> On 7/3/2016 8:58 AM, Gerard Sontag wrote:
>>> Hello from an unexperience reader,
>>> Why not create a new VARIABLE (name TBD) which will contain the preferred char indicating double.
>>> The point character would be the default value letting old programs running.
>>> For those who want to use another char it will be set at the beginning.
>>> Candidates (for me) are underscore, caret and backslash
>>
>> There is a programming concept called concurrency,
>
> Gosh, really?

There is a wide variety of programmers on this list including many that 
although they claim to be "Expert Forth Programmers", have never created 
any reasonable application. Myself, I don't claim to be an expert Forth 
programmer, although I have written various programs in Forth and other 
languages in the past and will continue to do so in the future. And yes 
really, it seems to be a concept that escapes many "Forth Programmers", 
along with a list of many other concepts, that are not part of "the 
spirit of Forth", that does sound religious doesn't it.
>
>> it allows a set of code to be simultaneously be executed by separate
>> threads, a very useful thing. The gist of it does not allow for
>> fixed variables to determine the state of code, as two copies of the
>> code running at the same time might need different set of states.
>
> It's a USER variable.  USER variables have been in Forth since the
> early 1970s.  They are very far from messy, and are a fundamental part
> of Forth design.  They are fast, easy to use, and avoid the problem of
> passing state on the stack.
>
> Andrew.
>
So is "User Variables" in the Forth Standard? I ask because there isn't 
a single mention of it in the "Standard", I'm aware what they were, but 
are they approved anymore? If they were they would be in the "Standard", 
maybe my computer has a search problem and can't find the subject in the 
"Standards" document. Would not defining  user variables involve carnal 
knowledge of the compiler internals, a no,no since it's not in the 
"spirit of Forth"?And in an embedded applications, are we to have 
multitude of pages of local variables where there is little to no RAM 
available?

Maybe it's "locals" that is being referred to, but they are messy, 
create them, copy the original values into them, maybe change them, but 
what about the existing code in the compiler, they have no clue that one 
is using a new private copy, very messy. Perhaps maybe "quotation" will 
come to the rescue here so a routine can read it's parent local 
variables, but sadly no, what is being pushed has no guarantee of 
accessing the parents local variables, so we are still messy.

It's a sad day, in Forth Land, no wonder so many persons here are cranky.
-- 
Cecil - k5nwa

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

#48791

Cecil Bayona <cbayona@cbayona.com> wrote:
> On 7/3/2016 8:58 AM, Gerard Sontag wrote:
>> Hello from an unexperience reader,
>> Why not create a new VARIABLE (name TBD) which will contain the preferred char indicating double.
>> The point character would be the default value letting old programs running.
>> For those who want to use another char it will be set at the beginning.
>> Candidates (for me) are underscore, caret and backslash
>
> There is a programming concept called concurrency,

Gosh, really?

> it allows a set of code to be simultaneously be executed by separate
> threads, a very useful thing. The gist of it does not allow for
> fixed variables to determine the state of code, as two copies of the
> code running at the same time might need different set of states.

It's a USER variable.  USER variables have been in Forth since the
early 1970s.  They are very far from messy, and are a fundamental part
of Forth design.  They are fast, easy to use, and avoid the problem of
passing state on the stack.

Andrew.

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

#48751

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 02/07/2016 18:32, Anton Ertl wrote:
>> Bernd Paysan suggested an alternative solution: Just make unprefixed
>> doubles obsolescent (and eventually non-standard), but instead of
>> adding a new prefix for doubles, just require one of the existing
>> prefixes if you want to write a double.  I.e.,:
>>
>> 1.  \ proposed obsolescent, eventually non-standard
>> #1. \ double
>> $1. \ double
>> %1. \ double
>
>How would a double integer be entered in a base without a prefix? 

With something like 

0. s" kf3s7" >number 2drop

I think these cases are so rare that such a fallback is good enough
despite its cumbersomeness.

Or, once we have user-defined recognizers, make this a little less
cumbersome by defining a user-defined recognizer for double of the
desired base, or for doubles of the current BASE (maybe using the "*1"
syntax, or maybe using something else).

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

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

#48765

On 03/07/2016 15:56, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 02/07/2016 18:32, Anton Ertl wrote:
>>> Bernd Paysan suggested an alternative solution: Just make unprefixed
>>> doubles obsolescent (and eventually non-standard), but instead of
>>> adding a new prefix for doubles, just require one of the existing
>>> prefixes if you want to write a double.  I.e.,:
>>>
>>> 1.  \ proposed obsolescent, eventually non-standard
>>> #1. \ double
>>> $1. \ double
>>> %1. \ double
>>
>> How would a double integer be entered in a base without a prefix?
>
> With something like
>
> 0. s" kf3s7" >number 2drop
>
> I think these cases are so rare that such a fallback is good enough
> despite its cumbersomeness.

You are surely joking, that has to be one of the the worst workarounds 
I've seen. Even if it is rare we ought to have consistency for inputting 
doubles whatever the value of BASE. Anyway shouldn't 0. have a prefix in 
your example?

>
> Or, once we have user-defined recognizers, make this a little less
> cumbersome by defining a user-defined recognizer for double of the
> desired base, or for doubles of the current BASE (maybe using the "*1"
> syntax, or maybe using something else).
>

-- 
Gerry

[toc] | [prev] | [standalone]

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

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

csiph-web