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

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

Russians about standard (survey taken in 2010 )

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

Contents

  Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 13:49 -0700
    Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-11 17:11 -0400
      Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 14:40 -0700
        Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-11 18:17 -0400
          Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 15:26 -0700
            Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-11 19:11 -0400
            Re: Russians about standard (survey taken in 2010 ) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-11 13:13 -1000
            Re: Russians about standard (survey taken in 2010 ) The Beez <the.beez.speaks@gmail.com> - 2017-04-14 06:11 -0700
        Re: Russians about standard (survey taken in 2010 ) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-11 13:12 -1000
          Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 16:38 -0700
            Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 16:46 -0700
              Re: Russians about standard (survey taken in 2010 ) Paul Rubin <no.email@nospam.invalid> - 2017-04-11 17:17 -0700
                Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 17:45 -0700
                Re: Russians about standard (survey taken in 2010 ) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-12 04:27 -0500
              Re: Russians about standard (survey taken in 2010 ) The Beez <the.beez.speaks@gmail.com> - 2017-04-14 06:13 -0700
                Re: Russians about standard (survey taken in 2010 ) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:23 -1000
            Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-11 20:17 -0400
              Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 17:35 -0700
                Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-11 20:43 -0400
                  Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 17:47 -0700
                    Re: Russians about standard (survey taken in 2010 ) Julian Fondren <julian.fondren@gmail.com> - 2017-04-11 18:36 -0700
                      Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-12 16:35 -0700
                        Re: Russians about standard (survey taken in 2010 ) Paul Rubin <no.email@nospam.invalid> - 2017-04-12 17:27 -0700
                          Re: Russians about standard (survey taken in 2010 ) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-13 03:06 +0200
                            Re: Russians about standard (survey taken in 2010 ) Paul Rubin <no.email@nospam.invalid> - 2017-04-12 21:06 -0700
                        Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-12 20:00 -0700
                          Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-13 06:44 -0700
                            Re: Russians about standard (survey taken in 2010 ) Alex <alex@rivadpm.com> - 2017-04-13 15:44 +0100
                              Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-13 14:04 -0700
                                Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-14 11:08 -0700
                                  Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-14 13:23 -0700
                                    Re: Russians about standard (survey taken in 2010 ) Alex <alex@rivadpm.com> - 2017-04-14 22:42 +0100
                                  Re: Russians about standard (survey taken in 2010 ) Alex <alex@rivadpm.com> - 2017-04-14 22:38 +0100
                                Re: Russians about standard (survey taken in 2010 ) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 13:44 +0200
                            Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-14 10:28 -0700
                              Re: Russians about standard (survey taken in 2010 ) Alex <alex@rivadpm.com> - 2017-04-14 22:24 +0100
                              Re: Russians about standard (survey taken in 2010 ) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 13:54 +0200
                                Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-15 15:02 -0700
                                  Re: Russians about standard (survey taken in 2010 ) Julian Fondren <julian.fondren@gmail.com> - 2017-04-15 15:40 -0700
                                    Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-16 10:28 -0700
                                      Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-17 22:12 -0400
                                        Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-18 23:37 -0700
                                          Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-19 15:31 -0400
                                  Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-15 20:43 -0400
                                    Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-15 18:14 -0700
                                      Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-15 21:49 -0400
                                      Re: Russians about standard (survey taken in 2010 ) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-04-16 20:20 +0100
                                        Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-16 20:41 -0700
                                          Re: Russians about standard (survey taken in 2010 ) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-04-17 09:03 +0100
                                        Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-16 20:49 -0700
                                          Re: Russians about standard (survey taken in 2010 ) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-04-17 09:25 +0100
                                            Re: Russians about standard (survey taken in 2010 ) Alex <alex@rivadpm.com> - 2017-04-17 16:32 +0100
                                              Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-17 22:19 -0400
                                                Re: Russians about standard (survey taken in 2010 ) Alex <alex@rivadpm.com> - 2017-04-18 13:51 +0100
                                                  Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-19 02:15 -0400
                                                  Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-19 10:54 -0700
                                                    Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-19 11:03 -0700
                                            Re: Russians about standard (survey taken in 2010 ) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-17 12:37 -1000
                              Re: Russians about standard (survey taken in 2010 ) hughaguilar96@gmail.com - 2017-04-15 17:18 -0700
                                Re: Russians about standard (survey taken in 2010 ) Alex <alex@rivadpm.com> - 2017-04-16 09:07 +0100
                    Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-11 23:26 -0400
                      Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-12 16:47 -0700
                        Re: Russians about standard (survey taken in 2010 ) rickman <gnuarm@gmail.com> - 2017-04-12 19:53 -0400
                Re: Russians about standard (survey taken in 2010 ) Julian Fondren <julian.fondren@gmail.com> - 2017-04-11 19:03 -0700
                  Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-12 16:45 -0700
            Re: Russians about standard (survey taken in 2010 ) JUERGEN <epldfpga@aol.com> - 2017-04-12 01:15 -0700
              Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-12 16:51 -0700
    Re: Russians about standard (survey taken in 2010 ) lehs <skydda.barnen@gmail.com> - 2017-04-11 18:47 -0700
    Re: Russians about standard (survey taken in 2010 ) Mark Wills <markwills1970@gmail.com> - 2017-04-12 01:19 -0700
      Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-12 16:57 -0700
    Re: Russians about standard (survey taken in 2010 ) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-12 09:14 +0000
      Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-12 17:00 -0700
    Re: Russians about standard (survey taken in 2010 ) "HAA" <someone@microsoft.com> - 2017-04-13 10:15 +1000
      Re: Russians about standard (survey taken in 2010 ) "HAA" <someone@microsoft.com> - 2017-04-13 13:17 +1000
        Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-13 06:46 -0700
      Re: Russians about standard (survey taken in 2010 ) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-13 05:59 -0700
        Re: Russians about standard (survey taken in 2010 ) "HAA" <someone@microsoft.com> - 2017-04-14 11:26 +1000

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

#57083

On Tuesday, April 11, 2017 at 7:47:04 PM UTC-5, Ilya Tarasov wrote:
> 
> List your question/answers and I will create a new survey.

Please allow me.

On Tuesday, April 11, 2017 at 3:49:31 PM UTC-5, Ilya Tarasov wrote:
> Question was; what you will do with new Standard?

Question #1: what will you do with an update (in language, OS, CPU
architecture, etc.) that breaks your existing code while providing
gee-whiz neat tools that you could use for the production of new
backwards-incompatible code? (major version update of a non-standard
language, like Ruby)

Question #2: what will you do with an update that breaks all or most
of your code and that provides tools that can only be used for the
production of new completely incompatible code, but which is better in
the eyes of the great sages? (major debacle in non-standard language
-- perl6, python3)

Question #3: what will you do with an update that breaks nothing but
that comes with some closures of CVEs and also random experimental
features that will show up in future CVEs? (typical browser update)

Question #4: what will you do with an update that defines a bunch of
obnoxious features loved by people who fundamentally hate your
language and which won't be usable without a transpiler for the next
five years, but which you can more or less ignore? (typical ECMAScript
standard update)

Question #5: what will you do with an update that defines some new
features that your vendor may or may not implement, and that breaks
only code you can't run because you don't own ones-complement hardware
anymore? (typical standardized-language standard update)

> Professionals:
> 1. Will switch to it immediately - 0 votes
> 2. Will try to adopt - 1 vote
> 3. My projects has highest priority - 5 votes
> 4. We will wait and see - 4 votes

Answers:

1. Will adopt immediately and rewrite all code if necessary. That
feature you wanted? I'll add it in three months to three years after
the rewrite. Maybe.

2. Will adopt whenever convenient and only because it won't break
much.

3. Will use for future projects--existing projects can stay as they
are.

4. I wrote a lot of code using PARSE-WORD and I resent the hell out of
having to remember that it's PARSE-NAME now!

Meanwhile, what does this answer mean?

> 3. My expectations has highest priority

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

#57186

среда, 12 апреля 2017 г., 4:36:40 UTC+3 пользователь Julian Fondren написал:
> On Tuesday, April 11, 2017 at 7:47:04 PM UTC-5, Ilya Tarasov wrote:
> > 
> > List your question/answers and I will create a new survey.
> 
> Please allow me.
> 
> On Tuesday, April 11, 2017 at 3:49:31 PM UTC-5, Ilya Tarasov wrote:
> > Question was; what you will do with new Standard?
> 
> Question #1: what will you do with an update (in language, OS, CPU
> architecture, etc.) that breaks your existing code while providing
> gee-whiz neat tools that you could use for the production of new
> backwards-incompatible code? (major version update of a non-standard
> language, like Ruby)
> 
> Question #2: what will you do with an update that breaks all or most
> of your code and that provides tools that can only be used for the
> production of new completely incompatible code, but which is better in
> the eyes of the great sages? (major debacle in non-standard language
> -- perl6, python3)
> 
> Question #3: what will you do with an update that breaks nothing but
> that comes with some closures of CVEs and also random experimental
> features that will show up in future CVEs? (typical browser update)
> 
> Question #4: what will you do with an update that defines a bunch of
> obnoxious features loved by people who fundamentally hate your
> language and which won't be usable without a transpiler for the next
> five years, but which you can more or less ignore? (typical ECMAScript
> standard update)
> 
> Question #5: what will you do with an update that defines some new
> features that your vendor may or may not implement, and that breaks
> only code you can't run because you don't own ones-complement hardware
> anymore? (typical standardized-language standard update)

All of questions listed above are not a question (one) for survey. You are forcing a certain answer - 'we need a standard, because all situations are bad'.

But you are referring to Ruby, python, perl etc. Please tell me, can you write your own implementation of them? How many months you will need, if you ever can? Comparing to Forth, claiming as easy to write and flexible, such arguments are inconsistent. If we agreed Forth is flexible and easy to write, a problem with incompatibility may be solved by rewriting a part of Forth. This is why those who use Forth for real work, often prefers to have your own, based on the common and known ideas, rather than rely on someone's.

> > Professionals:
> > 1. Will switch to it immediately - 0 votes
> > 2. Will try to adopt - 1 vote
> > 3. My projects has highest priority - 5 votes
> > 4. We will wait and see - 4 votes
> 
> Answers:
> 
> 1. Will adopt immediately and rewrite all code if necessary. That
> feature you wanted? I'll add it in three months to three years after
> the rewrite. Maybe.
> 
> 2. Will adopt whenever convenient and only because it won't break
> much.
> 
> 3. Will use for future projects--existing projects can stay as they
> are.
> 
> 4. I wrote a lot of code using PARSE-WORD and I resent the hell out of
> having to remember that it's PARSE-NAME now!

This is a question of project management. If you forgot about certain part of code, you should plan it before and describe it. 
 
> Meanwhile, what does this answer mean?
> 
> > 3. My expectations has highest priority

I change 'projects' to 'expectation' to highlight hobbyists has no their own projects :) But they usually like to issue many advises and theories how Forth must looks. The survey shows most of hobbyists want to see a Standard..., but don't want to use it! So why I need to take care about them? ;)

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

#57195

Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
> But you are referring to Ruby, python, perl etc. Please tell me, can
> you write your own implementation of them? How many months you will
> need, if you ever can? 

Ruby and Python, yes, I think so, a small number of months.  Perl: no
idea.  There are many versions some of which are very complicated.

> Comparing to Forth, claiming as easy to write and flexible, 

I'm not even so sure of this.  I sometimes think about how to implement
Forth, but there are always some pieces of the puzzle I find missing.
And yet I've implemented Lisp and found it easy and natural.  

Ruby and Python are basically Lisp with some syntax sugar and a few
other language-specific special features that don't seem too difficult.
There are several independent implementations of Python.  I don't know
if that's also true of Ruby, though maybe you could count Elixir.

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

#57200

In article <87a87ljgmr.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
>> But you are referring to Ruby, python, perl etc. Please tell me, can
>> you write your own implementation of them? How many months you will
>> need, if you ever can?
>
>Ruby and Python, yes, I think so, a small number of months.  Perl: no
>idea.  There are many versions some of which are very complicated.
>
>> Comparing to Forth, claiming as easy to write and flexible,
>
>I'm not even so sure of this.  I sometimes think about how to implement
>Forth, but there are always some pieces of the puzzle I find missing.
>And yet I've implemented Lisp and found it easy and natural.

I've that feeling about Lisp. It boils down to familiarity I guess.
In 2000 we had 5 members on the board of the Dutch Forth Chapter.
Everybody except me had developped at least one Forth. Then I started
with ciforth.

>
>Ruby and Python are basically Lisp with some syntax sugar and a few
>other language-specific special features that don't seem too difficult.
>There are several independent implementations of Python.  I don't know
>if that's also true of Ruby, though maybe you could count Elixir.

You say that because of familiarity with Lisp. I cannot recognize
Lisp features in Python. Let's take memoizing. Python has an
akward syntax for that. It is undoubtedly present in Lisp and
I probably would find that easy to understand and transparent.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#57208

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> You say that because of familiarity with Lisp. I cannot recognize
> Lisp features in Python. Let's take memoizing. Python has an
> akward syntax for that. It is undoubtedly present in Lisp and
> I probably would find that easy to understand and transparent.

Python doesn't have any syntax for memoization that I know of, but you
could do it with a decorator, i.e. a higher-order function that wraps
another function when you use some special syntax to do so.  E.g.  this
prints the 1000th fibonacci number almost instantly, while a
non-memoized version of the recursive fibonacci function would
basically never finish:

    import sys

    def memoize(func):
        memo = { }   # empty dictionary
        def mem_func(*args):
            if args in memo: return memo[args]
            memo[args] = func(*args)
            return memo[args]
        return mem_func

    @memoize
    def fibonacci(n):
        if n in [0,1]: return 1
        return fibonacci(n-1) + fibonacci(n-2)

    sys.setrecursionlimit(10000)
    print fibonacci(1000)

In Lisp (maybe easier, Scheme) you can do similar things without the
syntactic hair, by defining a HOF that does the memoization, using
macros, etc.

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

#57204

On Wednesday, April 12, 2017 at 4:35:17 PM UTC-7, Ilya Tarasov wrote:
> But you are referring to Ruby, python, perl etc. Please tell me, can you write your own implementation of them? How many months you will need, if you ever can? Comparing to Forth, claiming as easy to write and flexible, such arguments are inconsistent. If we agreed Forth is flexible and easy to write, a problem with incompatibility may be solved by rewriting a part of Forth. This is why those who use Forth for real work, often prefers to have your own, based on the common and known ideas, rather than rely on someone's.

A good point here, is that there is no money to be made in writing a Ruby, Python, Perl, etc. system. There is no money to be made in writing a Forth system either. Desktop-computer software is given away for free --- the days of CompUSA and its shrink-wrapped boxes containing disks and printed manuals are long gone (I may have bought the last copy of Turbo Assembler and Turbo Debugger which I got out of the bargain bin of a store that was going out of business).

The only way to make money is by building micro-controller boards and selling them (for example: Testra sells motion-control boards based on the RACE processor). These micro-controller boards need to be programmed to do something, and Forth is a good language for this.

I am not in favor of developing a Forth standard for micro-controllers however. I'm dubious that this can be done, because the programs are so I/O dependent that they aren't going to be portable anyway --- portability is the point of having a standard, so a standard for non-portable programs is meaningless. Some people (Mark Wills, for example) believe that a Forth standard for micro-controllers is possible, and is desirable, and the I/O can be abstracted out (so long as you stick to common I/O such as UARTS etc. that are the same everywhere). Maybe so! He has more experience than I do in that field --- I'm certainly not qualified --- maybe him and others in that field could develop a Forth standard (Raimond Dragomir's LFTforth would be a good start).

HAA is right that asking Forth programmers if they want a Forth standard is like asking people if they believe in God. Which god? Which standard? What is the goal of the standard?

I am in favor of developing a Forth standard for a desktop-computer Forth that would be useful as the host system for a cross-compiler. This is pretty easy! Here is what is needed:

1.) FIND has to work, obviously.

2.) We can go back to CONTEXT and CURRENT as we had in Forth-83. These would be used by the cross-compiler --- the cross-compiled Forth would not support vocabularies however --- to support vocabularies in the cross-compiled Forth you need a dual-xt system in the host Forth, which is complicated, and it is solving a non-problem because vocabularies in the target Forth aren't useful anyway.

3.) LITERAL etc. have to be vectored so the cross-compiled Forth can have literal numbers in the colon words.

4.) We need a string-stack (I have already written this in ANS-Forth).

5.) Make my rquotations standard. They already work under VFX and SwiftForth --- it is only necessary to guarantee that they will work under any standard Forth system.

6.) Make the control-flow stack distinct (can't be the data-stack as in ANS-Forth).

7.) We need the following words:
    VOCNO@ ( xt -- vocno )
    SMUDGE@ ( xt -- smudged? )
    SMUDGEABLE@ ( xt -- smudge-ready? )
    IMMEDIATE@ ( xt -- immediate? )
    VOCNO! ( vocno xt -- )
    SMUDGE! ( flag xt -- )
    SMUDGEABLE! ( flag xt -- )
    IMMEDIATE! ( flag xt -- )
    LATEST ( -- xt )  \ the latest definition compiled
    DICTIONARY-TRAVERSE ( xt -- )  \ execute the XT for every dictionary entry, giving it the xt of the entry
    :NAME ( vocno -- )  \string: name --  \ like colon except uses NAME as the name and puts the word in the VOCNO vocabulary

Note that in #7 above none of the words I described (except :NAME) can be written in ANS-Forth or Forth-200x.

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

#57232

четверг, 13 апреля 2017 г., 6:00:08 UTC+3 пользователь hughag...@gmail.com написал:
> On Wednesday, April 12, 2017 at 4:35:17 PM UTC-7, Ilya Tarasov wrote:
> > But you are referring to Ruby, python, perl etc. Please tell me, can you write your own implementation of them? How many months you will need, if you ever can? Comparing to Forth, claiming as easy to write and flexible, such arguments are inconsistent. If we agreed Forth is flexible and easy to write, a problem with incompatibility may be solved by rewriting a part of Forth. This is why those who use Forth for real work, often prefers to have your own, based on the common and known ideas, rather than rely on someone's.
> 
> A good point here, is that there is no money to be made in writing a Ruby, Python, Perl, etc. system. There is no money to be made in writing a Forth system either. Desktop-computer software is given away for free --- the days of CompUSA and its shrink-wrapped boxes containing disks and printed manuals are long gone (I may have bought the last copy of Turbo Assembler and Turbo Debugger which I got out of the bargain bin of a store that was going out of business).
> 
> The only way to make money is by building micro-controller boards and selling them (for example: Testra sells motion-control boards based on the RACE processor). These micro-controller boards need to be programmed to do something, and Forth is a good language for this.

Yes, we are selling final products with Forth inside and can design it faster and with more flexibility than based on other approaches. Indeed there is no strict limitation for other languages, but most effective solutions are Forth-based.
 
> I am not in favor of developing a Forth standard for micro-controllers however. I'm dubious that this can be done, because the programs are so I/O dependent that they aren't going to be portable anyway --- portability is the point of having a standard, so a standard for non-portable programs is meaningless. Some people (Mark Wills, for example) believe that a Forth standard for micro-controllers is possible, and is desirable, and the I/O can be abstracted out (so long as you stick to common I/O such as UARTS etc. that are the same everywhere). Maybe so! He has more experience than I do in that field --- I'm certainly not qualified --- maybe him and others in that field could develop a Forth standard (Raimond Dragomir's LFTforth would be a good start).

Embedded world is not too easy indeed. With a lot of platforms it is hard to find a proper abstraction, as you mentioned above. More important, there is a huge difference between low-cost and high-end platforms. This leads to difference between desired Forth features for them. For a low-cost MCU we may need just cross-compiler, without interpreter inside (just capable to run our simple Forth code developed and debugged on PC). For a high-end, we may need a vocabularies support, file system, network etc. 

Anyway, right from the start, embedded programmer usually need to provide a hardware abstraction layer, written in Forth or provided by assembler or C libraries. Forth is often used for data processing and IO access. So a brief list of words may looks like
DUP DROP SWAP OVER ROT @ ! + - AND OR XOR INPORT OUTPORT IF THEN ELSE BEGIN AGAIN UNTIL WHILE REPEAT DO LOOP I J CREATE DOES> VARIABLE CONSTANT 

EVALUATE is needed if external text access is used for that system. Other wordsets are optional and heavily depended on platform (including floating point, file access, IO access, even EMIT KEY). For most cases, EMIT is written in Forth because consist of port write commands.
 
> HAA is right that asking Forth programmers if they want a Forth standard is like asking people if they believe in God. Which god? Which standard? What is the goal of the standard?
> 
> I am in favor of developing a Forth standard for a desktop-computer Forth that would be useful as the host system for a cross-compiler. This is pretty easy! Here is what is needed:
> 
> 1.) FIND has to work, obviously.
> 
> 2.) We can go back to CONTEXT and CURRENT as we had in Forth-83. These would be used by the cross-compiler --- the cross-compiled Forth would not support vocabularies however --- to support vocabularies in the cross-compiled Forth you need a dual-xt system in the host Forth, which is complicated, and it is solving a non-problem because vocabularies in the target Forth aren't useful anyway.
> 
> 3.) LITERAL etc. have to be vectored so the cross-compiled Forth can have literal numbers in the colon words.

Yes.
 
> 4.) We need a string-stack (I have already written this in ANS-Forth).

I feel it is optional. But yes, since it is Forth-specific, feature must be described.
 
> 5.) Make my rquotations standard. They already work under VFX and SwiftForth --- it is only necessary to guarantee that they will work under any standard Forth system.

Again, it is optional. But each feature, impossible to implement without source texts changing, ust be described.
 
> 6.) Make the control-flow stack distinct (can't be the data-stack as in ANS-Forth).

Yes.
 
> 7.) We need the following words:
>     VOCNO@ ( xt -- vocno )
>     SMUDGE@ ( xt -- smudged? )
>     SMUDGEABLE@ ( xt -- smudge-ready? )
>     IMMEDIATE@ ( xt -- immediate? )
>     VOCNO! ( vocno xt -- )
>     SMUDGE! ( flag xt -- )
>     SMUDGEABLE! ( flag xt -- )
>     IMMEDIATE! ( flag xt -- )
>     LATEST ( -- xt )  \ the latest definition compiled
>     DICTIONARY-TRAVERSE ( xt -- )  \ execute the XT for every dictionary entry, giving it the xt of the entry
>     :NAME ( vocno -- )  \string: name --  \ like colon except uses NAME as the name and puts the word in the VOCNO vocabulary
> 
> Note that in #7 above none of the words I described (except :NAME) can be written in ANS-Forth or Forth-200x.

This is an example of the statement above. If some feature is impossible to reach in Forth, it must be provided and described.

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

#57235

On 4/13/2017 14:44, Ilya Tarasov wrote:
> четверг, 13 апреля 2017 г., 6:00:08 UTC+3 пользователь hughag...@gmail.com написал:
>> On Wednesday, April 12, 2017 at 4:35:17 PM UTC-7, Ilya Tarasov wrote:

>>
>> 3.) LITERAL etc. have to be vectored so the cross-compiled Forth can have literal numbers in the colon words.
> 
> Yes.

Why? An example would be helpful.

>   
>> 4.) We need a string-stack (I have already written this in ANS-Forth).
> 
> I feel it is optional. But yes, since it is Forth-specific, feature must be described.
>   
>> 5.) Make my rquotations standard. They already work under VFX and SwiftForth --- it is only necessary to guarantee that they will work under any standard Forth system.
> 
> Again, it is optional. But each feature, impossible to implement without source texts changing, ust be described.
>   
>> 6.) Make the control-flow stack distinct (can't be the data-stack as in ANS-Forth).
> 
> Yes.

Again, why?

>   
>> 7.) We need the following words:
>>      VOCNO@ ( xt -- vocno )
>>      SMUDGE@ ( xt -- smudged? )
>>      SMUDGEABLE@ ( xt -- smudge-ready? )
>>      IMMEDIATE@ ( xt -- immediate? )
>>      VOCNO! ( vocno xt -- )
>>      SMUDGE! ( flag xt -- )
>>      SMUDGEABLE! ( flag xt -- )
>>      IMMEDIATE! ( flag xt -- )
>>      LATEST ( -- xt )  \ the latest definition compiled
>> DICTIONARY-TRAVERSE ( xt -- ) \ execute the XT for every
>> dictionary
entry, giving it the xt of the entry
>> :NAME ( vocno -- ) \string: name -- \ like colon except uses NAME
>> as
the name and puts the word in the VOCNO vocabulary
>> 
>> Note that in #7 above none of the words I described (except :NAME)
can be written in ANS-Forth or Forth-200x.
> 
> This is an example of the statement above. If some feature is
impossible to reach in Forth, it must be provided and described.

All the SMUDGE words are about dictionary implementation.

DICTIONARY-TRAVERSE exists in Forth 2012 as TRAVERSE-WORDLIST.

IMMEDIATE! is implementation specific, and providing it would break a 
number of existing systems that don't use an IMMEDIATE flag.

-- 
Alex

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

#57264

> >> 3.) LITERAL etc. have to be vectored so the cross-compiled Forth can have literal numbers in the colon words.
> > 
> > Yes.
> 
> Why? An example would be helpful.

Because of not a lot, but important pieces of code, regarding to cross-compiling and adding support for number formats not built-in. It may be useful and costs almost nothing. I don't see any reasons why don't do this easy thing, if asked.
 
> >> 6.) Make the control-flow stack distinct (can't be the data-stack as in ANS-Forth).
> > 
> > Yes.
> 
> Again, why?

2 
: someword .... THEN ;
.

If 2 is a code for IF, missed IF inside someword will not be recognized. Using separate control-flow stack we always can be sure only control-flow informations is on the stack, and can add an additional checking.
 
> >   
> >> 7.) We need the following words:
> >>      VOCNO@ ( xt -- vocno )
> >>      SMUDGE@ ( xt -- smudged? )
> >>      SMUDGEABLE@ ( xt -- smudge-ready? )
> >>      IMMEDIATE@ ( xt -- immediate? )
> >>      VOCNO! ( vocno xt -- )
> >>      SMUDGE! ( flag xt -- )
> >>      SMUDGEABLE! ( flag xt -- )
> >>      IMMEDIATE! ( flag xt -- )
> >>      LATEST ( -- xt )  \ the latest definition compiled
> >> DICTIONARY-TRAVERSE ( xt -- ) \ execute the XT for every
> >> dictionary
> entry, giving it the xt of the entry
> >> :NAME ( vocno -- ) \string: name -- \ like colon except uses NAME
> >> as
> the name and puts the word in the VOCNO vocabulary
> >> 
> >> Note that in #7 above none of the words I described (except :NAME)
> can be written in ANS-Forth or Forth-200x.
> > 
> > This is an example of the statement above. If some feature is
> impossible to reach in Forth, it must be provided and described.
> 
> All the SMUDGE words are about dictionary implementation.
> 
> DICTIONARY-TRAVERSE exists in Forth 2012 as TRAVERSE-WORDLIST.
> 
> IMMEDIATE! is implementation specific, and providing it would break a 
> number of existing systems that don't use an IMMEDIATE flag.

Almost all here is implementation-specific. It is important to describe, but not too important to implement any auxiliary word and define any system constant.

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

#57298

On Thursday, April 13, 2017 at 2:04:28 PM UTC-7, Ilya Tarasov wrote:
> > >> 3.) LITERAL etc. have to be vectored so the cross-compiled Forth can have literal numbers in the colon words.
> > > 
> > > Yes.
> > 
> > Why? An example would be helpful.
> 
> Because of not a lot, but important pieces of code, regarding to cross-compiling and adding support for number formats not built-in. It may be useful and costs almost nothing. I don't see any reasons why don't do this easy thing, if asked.

This allows the built-in outer-interpreter to be used for the cross-compiler --- the alternative is to write a custom outer-interpreter for the cross-compiler, but this is needless complication.

> > >> 6.) Make the control-flow stack distinct (can't be the data-stack as in ANS-Forth).
> > > 
> > > Yes.
> > 
> > Again, why?
> 
> 2 
> : someword .... THEN ;
> .
> 
> If 2 is a code for IF, missed IF inside someword will not be recognized. Using separate control-flow stack we always can be sure only control-flow informations is on the stack, and can add an additional checking.

This is for meta-compilation. In ANS-Forth it is necessary to assume that the control-flow data is on the data-stack, which means that you don't have access to your own data on the data-stack. The solution is to store your own data in >R or local variables (see 1ARRAY etc. in the novice-package as an example). This is doable but it is needless complication.

> > >> 7.) We need the following words:
> > >>      VOCNO@ ( xt -- vocno )
> > >>      SMUDGE@ ( xt -- smudged? )
> > >>      SMUDGEABLE@ ( xt -- smudge-ready? )
> > >>      IMMEDIATE@ ( xt -- immediate? )
> > >>      VOCNO! ( vocno xt -- )
> > >>      SMUDGE! ( flag xt -- )
> > >>      SMUDGEABLE! ( flag xt -- )
> > >>      IMMEDIATE! ( flag xt -- )
> > >>      LATEST ( -- xt )  \ the latest definition compiled
> > >> DICTIONARY-TRAVERSE ( xt -- ) \ execute the XT for every
> > >> dictionary
> > entry, giving it the xt of the entry
> > >> :NAME ( vocno -- ) \string: name -- \ like colon except uses NAME
> > >> as
> > the name and puts the word in the VOCNO vocabulary
> > >> 
> > >> Note that in #7 above none of the words I described (except :NAME)
> > can be written in ANS-Forth or Forth-200x.
> > > 
> > > This is an example of the statement above. If some feature is
> > impossible to reach in Forth, it must be provided and described.
> > 
> > All the SMUDGE words are about dictionary implementation.
> > 
> > DICTIONARY-TRAVERSE exists in Forth 2012 as TRAVERSE-WORDLIST.
> > 
> > IMMEDIATE! is implementation specific, and providing it would break a 
> > number of existing systems that don't use an IMMEDIATE flag.
> 
> Almost all here is implementation-specific. It is important to describe, but not too important to implement any auxiliary word and define any system constant.

Alex McDonald doesn't understand what the purpose of a standard is. The purpose is not to maximize the number of existing systems that can be considered standard without any modification. This was Elizabeth Rather's goal with ANS-Forth, and this is why ANS-Forth is rife with ambiguity (all of those existing systems were incompatible with each other).

The purpose of a standard is to standardize. For example, IF etc. have to be standardized as being immediate. You can't have IF immediate in some system, non-immediate in other systems, and neither immediate or non-immediate in yet other systems (because the concept of immediacy doesn't exist). 

I'm not opposed to innovation in Forth design, but that is not what a standard is for --- with a standard, you have to settle on something that is reasonably useful and standardize it --- then your standard programs will be portable between standard systems. Innovative people such as Ilya worry that I'm trying to put them in a straight-jacket and prevent them from innovating --- I'm not --- I'm just saying, that if they want their programs to be portable, then they have to stay within the standard, and for the most part they have to stick with novice-level programming techniques rather than make the program a demonstration of their advanced-level skill (you don't need a helicopter if you are going to the store to buy a bottle of vodka; an ordinary car should be sufficient).

All of those words above are standardized so we get an abstraction layer above the implementation. We don't want to expose the implementation in the standard, such as the dictionary header (where exactly the immediate flag is). The use of an abstraction layer is well known. For example, in C++ or Object Pascal or whatever, we typically have GET-xxx and SET-xxx methods for accessing data in an object, but the data itself is PRIVATE so the user can't directly access it. Similarly, we should have STATE@ rather than STATE so the user can't directly access the STATE data (because writing to it is not allowed; it is supposed to be read-only). Similarly, we have MS@ for providing the current time in milliseconds (because there is no MS variable; it is a timer internally).

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

#57318

On Friday, April 14, 2017 at 11:08:26 AM UTC-7, hughag...@gmail.com wrote:
> The purpose of a standard is to standardize. For example, IF etc. have to be standardized as being immediate. You can't have IF immediate in some system, non-immediate in other systems, and neither immediate or non-immediate in yet other systems (because the concept of immediacy doesn't exist). 
> ...
> Similarly, we should have STATE@ rather than STATE so the user can't directly access the STATE data (because writing to it is not allowed; it is supposed to be read-only). 

Anton Ertl hates STATE-smart words! In order to get Anton on board with this standard, it might be a good idea to not have STATE@ at all.

STATE@ is used to write STATE-smart words. You have an immediate word, and it tests STATE@ to determine what it is supposed to do. I agree that this is problematic --- you end of with an abomination such as OpenForth in which IF worked either inside or outside of a colon word --- or ' worked either inside or outside of a colon word (it is better to have ['] and ' to "let the dictionary do the deciding").

So, perhaps the best solution is this:
STATE@ has these values:
-1 interpreting outside of a colon word
 1 interpreting inside of a colon word inside of [ ] brackets
 0 compiling inside of a colon word

But, STATE@ is not exposed to the user, so the user doesn't need to know about these values. The user only needs to know one rule:
"Any word declared as IMMEDIATE will abort with an error message if used when interpreting outside of a colon word. It will execute inside of colon word, whether compiling or (if it is in [ ] brackets) interpreting."

This should make Anton Ertl happy, because STATE-smart words are banned. This would be in keeping with my goal of having a standard that allows programs to be portable but mostly requires the programmers to stick with novice-level programming. Writing STATE-smart words is intermediate-level programming, and it usually results in shooting yourself in the foot, so it can be banned without any great loss. I might write some STATE-smart words myself though (because I'm advanced-level and I won't shoot myself in the foot) --- I would put them in the standard so the compiler-writer has to write them, because the compiler-writer has STATE@ available which the user doesn't. An example would be the words generated by FIELD because you might want these available when interpreting outside of a colon word (mostly for testing purposes) --- it is extremely unlikely that these would be given to FIND, but if they are then you have just shot yourself in the foot --- I could actually special-case these in FIND so FIND aborts with an error message if it is given a STATE-smart word (all STATE-smart words are in the standard, so I know about all of them when I write FIND).

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

#57327

On 4/14/2017 21:23, hughaguilar96@gmail.com wrote:
> ither inside or outside of a colon word --- or ' worked either inside
> or outside of a colon word (it is better to have ['] and ' to "let
> the dictionary do the deciding").
> 
> So, perhaps the best solution is this: STATE@ has these values: -1
> interpreting outside of a colon word 1 interpreting inside of a colon
> word inside of [ ] brackets 0 compiling inside of a colon word
> 
> But, STATE@ is not exposed to the user, so the user doesn't need to
> know about these values. The user only needs to know one rule: "Any
> word declared as IMMEDIATE will abort with an error message if used
> when interpreting outside of a colon word. It will execute inside of
> colon word, whether compiling or (if it is in [ ] brackets)
> interpreting."
> 
> This should make Anton Ertl happy, because STATE-smart words are
> banned. This would be in keeping with my goal of having a standard
> that allows programs to be portable but mostly requires the
> programmers to stick with novice-level programming. Writing
> STATE-smart words is intermediate-level programming, and it usually
> results in shooting yourself in the foot, so it can be banned without
> any great loss. I might write some STATE-smart words myself though
> (because I'm advanced-level and I won't shoot myself in the foot) ---
> I would put them in the standard so the compiler-writer has to write
> them, because the compiler-writer has STATE@ available which the user
> doesn't. An example would be the words generated by FIELD because you
> might want these available when interpreting outside of a colon word
> (mostly for testing purposes) --- it is extremely unlikely that these
> would be given to FIND, but if they are then you have just shot
> yourself in the foot --- I could actually special-case these in FIND
> so FIND aborts with an error message if it is given a STATE-smart
> word (all STATE-smart words are in the standard, so I know about all
> of them when I write FIND).

This entire post is 100% unadulterated horseshit. You cannot build 
systems or standards or applications based on this kind of crazy thinking.

-- 
Alex

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

#57326

On 4/14/2017 19:08, hughaguilar96@gmail.com wrote:
.
> 
> Alex McDonald doesn't understand what the purpose of a standard is.
> The purpose is not to maximize the number of existing systems that
> can be considered standard without any modification. This was
> Elizabeth Rather's goal with ANS-Forth, and this is why ANS-Forth is
> rife with ambiguity (all of those existing systems were incompatible
> with each other).
> 
> The purpose of a standard is to standardize. 
> 

If I'd only known earlier. The purpose of [X] is to [X]ize, pick your X. 
I'm impressed.

 > All of those words above are standardized so we get an abstraction
 > layer above the implementation. We don't want to expose the
 > implementation in the standard,

Yet every time you write here, you implement, not standardize.

       SMUDGE@ ( xt -- smudged? )
       SMUDGEABLE@ ( xt -- smudge-ready? )
       IMMEDIATE@ ( xt -- immediate? )
       SMUDGE! ( flag xt -- )
       SMUDGEABLE! ( flag xt -- )
       IMMEDIATE! ( flag xt -- )

All of these words force a specific implementation on the dictionary. 
All of them. They not only contradict your position, they are useless in 
a standard. Because (and I know you don't get this) they tell you how 
something is to be done, rather than describing what is to be done.

-- 
Alex

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

#57364

In article <603c278d-8a97-4ddc-88e7-fb97c1aae0e4@googlegroups.com>,
Ilya Tarasov  <ilya74.tarasov@gmail.com> wrote:
>> >> 3.) LITERAL etc. have to be vectored so the cross-compiled Forth can have literal numbers in the colon words.
>> >
>> > Yes.
>>
>> Why? An example would be helpful.
>
>Because of not a lot, but important pieces of code, regarding to cross-compiling and adding support for number formats not built-in. It may be useful and costs almost nothing. I don't see any reasons why don't do this easy thing, if asked.
>
>> >> 6.) Make the control-flow stack distinct (can't be the data-stack as in ANS-Forth).
>> >
>> > Yes.
>>
>> Again, why?
>
>2
>: someword .... THEN ;
>.
>
>If 2 is a code for IF, missed IF inside someword will not be recognized. Using separate control-flow stack we always can be sure only control-flow informations is on the stack, and can add an additional checking.
>
>> >
>> >> 7.) We need the following words:
>> >>      VOCNO@ ( xt -- vocno )
>> >>      SMUDGE@ ( xt -- smudged? )
>> >>      SMUDGEABLE@ ( xt -- smudge-ready? )
>> >>      IMMEDIATE@ ( xt -- immediate? )
>> >>      VOCNO! ( vocno xt -- )
>> >>      SMUDGE! ( flag xt -- )
>> >>      SMUDGEABLE! ( flag xt -- )
>> >>      IMMEDIATE! ( flag xt -- )
>> >>      LATEST ( -- xt )  \ the latest definition compiled
>> >> DICTIONARY-TRAVERSE ( xt -- ) \ execute the XT for every
>> >> dictionary
>> entry, giving it the xt of the entry
>> >> :NAME ( vocno -- ) \string: name -- \ like colon except uses NAME
>> >> as
>> the name and puts the word in the VOCNO vocabulary
>> >>
>> >> Note that in #7 above none of the words I described (except :NAME)
>> can be written in ANS-Forth or Forth-200x.
>> >
>> > This is an example of the statement above. If some feature is
>> impossible to reach in Forth, it must be provided and described.
>>
>> All the SMUDGE words are about dictionary implementation.
>>
>> DICTIONARY-TRAVERSE exists in Forth 2012 as TRAVERSE-WORDLIST.
>>
>> IMMEDIATE! is implementation specific, and providing it would break a
>> number of existing systems that don't use an IMMEDIATE flag.
>
>Almost all here is implementation-specific. It is important to
>describe, but not too important to implement any auxiliary word and
>define any system constant.

What is worse, an xt cannot know whether a word is
immediate, only a dictionary entry address (by some called
"name token" ) can. So it is a design error.
Think of the situation for the xt's of noname definitions
and closures.
A large amount of text will be needed in the standard
to prevent complaints of "ambiguousness". Then, probably
the same persons, will complain that the standard becomes too
complicated.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#57296

On Thursday, April 13, 2017 at 6:44:55 AM UTC-7, Ilya Tarasov wrote:
> четверг, 13 апреля 2017 г., 6:00:08 UTC+3 пользователь hughag...@gmail.com написал:
> Embedded world is not too easy indeed. With a lot of platforms it is hard to find a proper abstraction, as you mentioned above. More important, there is a huge difference between low-cost and high-end platforms. This leads to difference between desired Forth features for them. For a low-cost MCU we may need just cross-compiler, without interpreter inside (just capable to run our simple Forth code developed and debugged on PC). For a high-end, we may need a vocabularies support, file system, network etc. 

Well, focus on the low-end first --- it is easier because there is less variety of features --- it is likely more useful too.

> > 3.) LITERAL etc. have to be vectored so the cross-compiled Forth can have literal numbers in the colon words.
> 
> Yes.

This is so obvious as to be beyond question. Anybody who knows anything about cross-compilation should agree with this without hesitation.

> > 4.) We need a string-stack (I have already written this in ANS-Forth).
> 
> I feel it is optional. But yes, since it is Forth-specific, feature must be described.

Well, the two things that programs work with are numbers and text. So, both have to be supported, or you have a toy language with no practical value (ANS-Forth).

I can email you STRING-STACK.4TH an STRING-STACK.TXT so you get your description. Also, it will be in the next novice-package release.

> > 5.) Make my rquotations standard. They already work under VFX and SwiftForth --- it is only necessary to guarantee that they will work under any standard Forth system.
> 
> Again, it is optional. But each feature, impossible to implement without source texts changing, ust be described.

I wouldn't consider this to be optional. This is easy to implement and hugely useful (this puts Forth ahead of C).

Here it is:
--------------------------------------------------------------------------

\ ******
\ ****** R[ ]R quotations.
\ ****** https://groups.google.com/forum/#!topic/comp.lang.forth/3LSqmBIZuzY
\ ****** This is highly non-standard! ANS-Forth (section 3.2.3.3.) says:
\ ****** A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;
\ ******

\ In the stack-picture comments, RQ is a continuation (a vector to a quotation).

\ HumptyDumpty invented rquotations --- this was very good programming --- I hadn't thought of it.
\ What I call REX0 he called RCALL --- also, he didn't have REX which I invented (this only works in VFX and SwiftForth).
\ If only REX0 is used, rquotations can be used under any ANS-Forth system (theoretically non-standard though).
\ REX is a lot more useful though because the HOF almost always needs to have locals.

\ My improved version for VFX or SwiftForth should be easy to port to other ANS-Forth systems --- any Forth system with locals.
\ Some assembly-language is required, but it is pretty straight forward.

VFX? SwiftForth? or [if]

: rexit     ( --   )    rdrop ;
: (r:)      ( -- rq )   r@ 5 + ;    \ 5 is the size of a JMP instruction in 32-bit x86
: r[        ( -- rq )   postpone (r:)  postpone ahead ;  immediate
: ]r        ( --   )    postpone rexit  postpone then ;  immediate

: rex0      ( rq -- )   >r ;                                    \ requires the HOF to not have locals

\ REX0 is the same as EXECUTE
\ We don't use EXECUTE however because in the other version (not VFX or SwiftForth) REX0 is different.
    
VFX? [if]

code rex    ( rq -- )                                           \ requires the HOF to have locals
    push edi                    \ this is the HOF's LF which won't be used by the quotation
    mov edi, 0 [edi]            \ this is the parent's LF which will be used by the quotation
    mov eax, ebx
    mov ebx, 0 [ebp]  lea ebp, w [ebp]
    call eax
    pop edi                     \ restore HOF's LF
    next, end-code
    
[then]

SwiftForth? [if]

156 constant lf-offset  \ this is the offset for the local-frame in the user-variables (ESI is the user-variable base)

code rex    ( rq -- )                                           \ requires the HOF to have locals
    lf-offset [esi] edx mov
    edx push                    \ this is the HOF's LF which won't be used by the quotation
    -4 [edx] eax mov            \ this is the old ESP
    0 [eax] eax mov             \ this is the parent's LF which will be used by the quotation
    eax lf-offset [esi] mov
    ebx eax mov  [drop]
    eax call
    lf-offset [esi] pop         \ restore HOF's LF  
    ret end-code
    
[then]

[else] \ this was written by HumptyDumpty and works on gForth, SwiftForth and VFX

: rexit     ( --   )        RDROP ;
: (r:)      ( -- rq )       R@  false ;
: r[        ( -- rq )       postpone (r:)   postpone IF   ;     immediate
: ]r        ( --   )        postpone REXIT  postpone THEN ;     immediate

: rex0      ( rq -- )       >R  true ;                          \ requires the HOF to not have locals

\ REX is not supported in HumptyDumpty's code.

[then]

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

#57325

On 4/14/2017 18:28, hughaguilar96@gmail.com wrote:
> On Thursday, April 13, 2017 at 6:44:55 AM UTC-7, Ilya Tarasov wrote:
>> четверг, 13 апреля 2017 г., 6:00:08 UTC+3 пользователь
>> hughag...@gmail.com написал: 
> 
>>> 3.) LITERAL etc. have to be vectored so the cross-compiled Forth
>>> can have literal numbers in the colon words.
>> 
>> Yes.
> 
> This is so obvious as to be beyond question. Anybody who knows
> anything about cross-compilation should agree with this without
> hesitation.

Why? This isn't an explanation.

-- 
Alex

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

#57365

In article <61fd9c93-94c6-4ee0-83ba-a766de1dbae2@googlegroups.com>,
 <hughaguilar96@gmail.com> wrote:
>On Thursday, April 13, 2017 at 6:44:55 AM UTC-7, Ilya Tarasov wrote:
>> =D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 13 =D0=B0=D0=BF=D1=80=D0=B5=
>=D0=BB=D1=8F 2017 =D0=B3., 6:00:08 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=
>=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C hughag...@gmail.com =D0=BD=D0=B0=D0=
>=BF=D0=B8=D1=81=D0=B0=D0=BB:
>> Embedded world is not too easy indeed. With a lot of platforms it is hard=
> to find a proper abstraction, as you mentioned above. More important, ther=
>e is a huge difference between low-cost and high-end platforms. This leads =
>to difference between desired Forth features for them. For a low-cost MCU w=
>e may need just cross-compiler, without interpreter inside (just capable to=
> run our simple Forth code developed and debugged on PC). For a high-end, w=
>e may need a vocabularies support, file system, network etc.=20
>
>Well, focus on the low-end first --- it is easier because there is less var=
>iety of features --- it is likely more useful too.
>
>> > 3.) LITERAL etc. have to be vectored so the cross-compiled Forth can ha=
>ve literal numbers in the colon words.
>>=20
>> Yes.

No. I can have the same effect by placing number denotations in the
metacompiler vocabulary in ciforth.

Once again one cannot think outside ones own implementation.
By the way, being able to do that is an absolute requirement
for being on a standards committee, or writing proposals for a
standard.

>
>This is so obvious as to be beyond question. Anybody who knows anything abo=
>ut cross-compilation should agree with this without hesitation.

See above.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#57392

суббота, 15 апреля 2017 г., 14:52:54 UTC+3 пользователь Albert van der Horst написал:
> >ve literal numbers in the colon words.
> >>=20
> >> Yes.
> 
> No. I can have the same effect by placing number denotations in the
> metacompiler vocabulary in ciforth.

I'm not asking how else you can have the same effect. I see vectored LITERAL is useful, very easy to implement and open ways to handle numbers. Declining this looks like a kind of hierarchy establishing ("I told you even a simple thing must be accepted by me!"), but this has no effect on skilled programmer.
 
> Once again one cannot think outside ones own implementation.

A short survey in my team:
1. Are you happy having Forth technology? 
Yes - 5 
No - 0
2. Do you think we need to communicate with other forthers in the world even they don't want to be an equal partners?
No, it is just time wasting, leave them alone - 4
Hmm, let's try, maybe it will be some useful - 1

So I'm trying :)

> By the way, being able to do that is an absolute requirement
> for being on a standards committee, or writing proposals for a
> standard.

Such a goal of the life! :)

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

#57393

On Saturday, April 15, 2017 at 5:02:34 PM UTC-5, Ilya Tarasov wrote:
> 2. Do you think we need to communicate with other forthers in the world even they don't want to be an equal partners?
> No, it is just time wasting, leave them alone - 4
> Hmm, let's try, maybe it will be some useful - 1
> 
> So I'm trying :)

Suppose that other forthers in the world wanted to be equal partners
with you.

How would you know that this is the case?

How would circumstances not look exactly as they do right now?



For my part I find Forth subjects interesting and, more severely, fail
to find interest in most non-Forth subjects. What's popular to talk
about on /r/programming or Hacker News isn't popular with me. So I
talk here mostly to encourage the occasional post of interest.

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

#57454

воскресенье, 16 апреля 2017 г., 1:40:36 UTC+3 пользователь Julian Fondren написал:
> On Saturday, April 15, 2017 at 5:02:34 PM UTC-5, Ilya Tarasov wrote:
> > 2. Do you think we need to communicate with other forthers in the world even they don't want to be an equal partners?
> > No, it is just time wasting, leave them alone - 4
> > Hmm, let's try, maybe it will be some useful - 1
> > 
> > So I'm trying :)
> 
> Suppose that other forthers in the world wanted to be equal partners
> with you.
> 
> How would you know that this is the case?
> 
> How would circumstances not look exactly as they do right now?

I can tell some stories about non-equal partnership. Earlier when one of my translators becomes known I had contact with SP-Forth team. They claims it was 'standard de-facto for Russia' :) Indeed, it is ANS-compatible since I don't remember exactly, but long time ago. I ask them some questions about goals, criteria, perspective plans, with no answer. Just 'we have cool stuff here and we are ANS-compatible, don't be individual and come to our team'. At that time it was very hard, because of several successfully projects done and several peoples near me was greatly impressed by Forth abilities. Of course, my main goal was to meet real demands of practical programmers near me, not fantasies of distant ones. Now SP-Forth is bad enough and his author no longer use Forth at this work.

Near 2003, known enough in Russia Technoforth company ask me... to stop my Forth activity :) They have read my articles and his CEO writes me a letter with proposal to become their regional sales manager ('because it seems you know something about Forth'). Near 2008 their big customer cancel partnership with them and start to work with my team. It was surprisingly for me, because they told me nothing about existing relation with Technoforth and I took absolutely nothing effort to represent Technoforth in bad light. Shortly after this they were gone from business.

The scenario was very predictable
- We are great! Join us!
- Ok, let's start, and I have some proposals for you to improve Forth accordingly to our positive experience.
- We don't need your proposals, just join us and start to do that we order! 
<Several years>
<They are feels bad or gone>

Now I want to take a look on ANS-committee & Forth Inc :)

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

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

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

csiph-web