How do you attract young programmers to Forth if you don't contribute to "Forth hybrid" languages?

[Liang Ng]

I came across Forth when I was looking for a programming language that I can use easily on mobile phone -- basically without punctuation.

Eventually I realized the properties of the reverse polish notation -- it can be used to represent abstract syntax tree -- which means RPN can be used to translate into ANY programming language.

To be honest, do you think Forth is readily appealing to newbie programmers today?

I think Forth would attract intermediate to expert programmers, who have already mastered quite a few programming languages -- which is the norm nowadays.

And yet, RPN has the potential to help simplify programming by being the ONE UNIVERSAL programming language that can integrate with other programming languages in active use today -- which is practical benefit besides being theoretically appealing.

Regrettably, after a long pursuit for review, what I received were a couple of stern rejection -- no, we don't review non-Forth code.

Oh well. Perhaps a "Forth hybrid" language is too avant garde for some. However, without a Forth-hybrid language, how would you expect to attract younger programmers to Forth?

[Mark Wills]

It already exists. It's called Factor.

[minf...@arcor.de]

I find 'young programmers' sort of discriminating against elder programmers.
Not good.

[Liang Ng]

On Tuesday, 27 February 2018 20:59:14 UTC+8, minf...@arcor.de wrote:
> I find 'young programmers' sort of discriminating against elder programmers.
> Not good.

My apologies.

But no time to think of diplomatic language.

Suggestions welcome.

[foxaudio...@gmail.com]

I don't think keeping language discussions in specific forums is unusual. If we look at many
common languages they are like variations of the same thing. Yet you don't see Algol groups
discussing Pascal or Modula or Ada or C etc...

I suspect there would need to be a discussion group on Concatenative Languages to give you
a place to bootstrap acceptance of a new "Forth Family" language.

You are fighting human nature INMHO.

[Liang Ng]

On Tuesday, 27 February 2018 21:38:18 UTC+8, foxaudio...@gmail.com wrote:
> I don't think keeping language discussions in specific forums is unusual. If we look at many
> common languages they are like variations of the same thing. Yet you don't see Algol groups
> discussing Pascal or Modula or Ada or C etc...
>
> I suspect there would need to be a discussion group on Concatenative Languages to give you
> a place to bootstrap acceptance of a new "Forth Family" language.
>
> You are fighting human nature INMHO.

Other languages do not have the reverse polish notation properties of "being able to translate into other languages" -- except maybe LISP.

I invented a new term for this -- unitary tree programming languages, i.e. programming languages where the height of abstract syntax tree is equal to one or less. But even this get lambasted by one Alex M.

And the properties of "being able to translate into other languages", including programming languages as well as human natural languages, might just be the holy grail, the weapon to end all wars in computer science!!

Other languages are what Charles Moore referred to as "third generation programming languages" -- which I call "composite tree programming languages" where the height of the abstract syntax tree is greater than one.

[c...@forthworks.com]

> I came across Forth when I was looking for a programming language that
> I can use easily on mobile phone -- basically without punctuation.

My kids do fine programming in Python on their phones using the standard
virtual keyboards. One of them dabbles in Forth (my dialect) as well as
working on his own little RPN-oriented language. The need to access
symbols doesn't slow them down at all. (The environments help. On iOS,
the Pythonista IDE provides easy access to the main symbols used in
Python. My RETRO Forth does similar.)

> Eventually I realized the properties of the reverse polish notation
> -- it can be used to represent abstract syntax tree -- which means
> RPN can be used to translate into ANY programming language.

I have zero interest in this.

> To be honest, do you think Forth is readily appealing to newbie
> programmers today?

> I think Forth would attract intermediate to expert programmers, who
> have already mastered quite a few programming languages -- which is
> the norm nowadays.

I see interest in my Forth from both newer programmers and those
with experience. It's continually attracted users, though I can't
say what people other than me are doing with it.

> Oh well. Perhaps a "Forth hybrid" language is too avant garde for
> some. However, without a Forth-hybrid language, how would you expect
> to attract younger programmers to Forth?

How has Forth attracted users all these years? Sure it's not a big,
well-known language, but does it really need to be? Forth is a tool,
honed by usage, and (in my experience) at it's best once the user has
learned and adapted it to their needs.

Would a "Forth hybrid" bring new users to Forth? Not in my experience.
I've implemented a few, and learned some useful things in the process.
But none of them proved to be successful at attracting new users and
none were better enough than Forth to survive long term.

I'll continue to quietly promote my Forth, and write useful little
programs in it, publishing them and sharing when it makes sense. I'm
content to let growth come from those interested in it, and not those
who want something fundamentally different.

-- crc

[Paul Rubin]

Liang Ng <lsn...@gmail.com> writes:
> Regrettably, after a long pursuit for review, what I received were a
> couple of stern rejection -- no, we don't review non-Forth code.

The issue there is that since you haven't shown any interest in writing
Forth code yourself, it's perplexing that you're suggesting ways of
getting other people interested in it. We on clf are used to the idea
that Forth isn't popular in the wider world and there are lots of folks
out there who don't want to use it. It seems that you're one of them,
and that is fine!

You've got this PHP thing that you think is somehow similar to Forth,
but unless you actually use Forth for something, you might not
understand how shallow the similarity really is.

Why don't you write some Forth code and post it? That might help your
understanding.

[Alex]

On 27-Feb-18 13:44, Liang Ng wrote:
> On Tuesday, 27 February 2018 21:38:18 UTC+8, foxaudio...@gmail.com
> wrote:
>> I don't think keeping language discussions in specific forums is
>> unusual. If we look at many common languages they are like
>> variations of the same thing. Yet you don't see Algol groups
>> discussing Pascal or Modula or Ada or C etc...
>>
>> I suspect there would need to be a discussion group on
>> Concatenative Languages to give you a place to bootstrap acceptance
>> of a new "Forth Family" language.
>>
>> You are fighting human nature INMHO.
>
> Other languages do not have the reverse polish notation properties of
> "being able to translate into other languages" -- except maybe LISP.

Hmmm...

>
> I invented a new term for this -- unitary tree programming languages,
> i.e. programming languages where the height of abstract syntax tree
> is equal to one or less. But even this get lambasted by one Alex M.

Yes. To repeat:

The height of a tree is "the number of edges on the longest path between
the root and a leaf." A tree of height 1 has a maximal one edge between
the root node and any of its leaves. It is a list if there is a
sequencing order between the leaves.

A tree of height zero has no leaves (since there are zero edges), and
consists of only a root node. If it was an AST, it would represent the
null statement.

>
> And the properties of "being able to translate into other languages",
> including programming languages as well as human natural languages,
> might just be the holy grail, the weapon to end all wars in computer
> science!!

Then Google is the holy grail, and the job is done. I just asked "what
is one plus two times three?" and Google replied 7. "what is half of
twelve?" gets 6, and so on.

>
> Other languages are what Charles Moore referred to as "third
> generation programming languages" -- which I call "composite tree
> programming languages" where the height of the abstract syntax tree
> is greater than one.
>

Dijkstra's shunting yard algorithm is an example of how an operator
precedence AST can be turned into RPN -- that is, a list or its equivalent.

4th and 5th generation languages already exist in some numbers, so your
characterisation of "other languages" as all 3GLs is out of date; that's
because you're taking Charles Moore's statement out of its historical
context. He said this in the early 1970s, some 45+ years ago. Things
have moved on a bit since then, and his definition of Forth as a 4GL is
not what is meant today by a 4GL.

--
Alex

[Paul Rubin]

Alex <al...@rivadpm.com> writes:
> not what is meant today by a 4GL.

Does anyone still use terms like 4GL any more? Calling something a 4GL
makes it sound archaic to my ears.

[Liang Ng]

On Wednesday, 28 February 2018 05:39:03 UTC+8, Paul Rubin wrote:
> The issue there is that since you haven't shown any interest in writing
> Forth code yourself, it's perplexing that you're suggesting ways of
> getting other people interested in it. We on clf are used to the idea
> that Forth isn't popular in the wider world and there are lots of folks
> out there who don't want to use it. It seems that you're one of them,
> and that is fine!
>
> You've got this PHP thing that you think is somehow similar to Forth,
> but unless you actually use Forth for something, you might not
> understand how shallow the similarity really is.
>
> Why don't you write some Forth code and post it? That might help your
> understanding.

https://www.linkedin.com/pulse/learning-forth-2018-%E4%BC%8D%E6%A8%91%E7%9B%9B-%E5%8D%9A%E5%A3%AB-liang-ng-ph-d-/

[Paul Rubin]

Liang Ng <lsn...@gmail.com> writes:
> https://www.linkedin.com/pulse/learning-forth-2018-%E4%BC%8D%E6%A8%91%E7%9B%9B-%E5%8D%9A%E5%A3%AB-liang-ng-ph-d-/

I don't use Linkedin. Is that Forth code if yes, and can you post it here?
Thanks.

[Liang Ng]

LinkedIn Pulse is just blog, accessible to anyone.

It's a tutorial I wrote: Learning Forth in 2018.

[gavino himself]

booom!!

and furnace for the web apps!

[dxf...@gmail.com]

On Tuesday, February 27, 2018 at 10:44:37 PM UTC+11, Liang Ng wrote:
> I came across Forth when I was looking for a programming language that I can use easily on mobile phone -- basically without punctuation.
>
> Eventually I realized the properties of the reverse polish notation -- it can be used to represent abstract syntax tree -- which means RPN can be used to translate into ANY programming language.
>
> To be honest, do you think Forth is readily appealing to newbie programmers today?

If you're interested in attention to detail - and
in controller apps I suspect that's still the
case - then why wouldn't you love Forth? Now if
Forth were instead called Stoic then perhaps we
wouldn't get all these discussions about how it
needs to be made more attractive :)

[Mark Wills]

No. It has no functionality.

[dxf...@gmail.com]

No, you dont like the name Stoic? Because the
1970's language of the same name was criticized
by FIG? STOIC did have some popularity in the UK
among hobbyists. IIRC source was held in text
files rather than blocks (like most forths
today).

[Liang Ng]

On Monday, 5 March 2018 16:56:55 UTC+8, dxf...@gmail.com wrote:
> If you're interested in attention to detail - and
> in controller apps I suspect that's still the
> case - then why wouldn't you love Forth? Now if
> Forth were instead called Stoic then perhaps we
> wouldn't get all these discussions about how it
> needs to be made more attractive :)

I am in the midst of writing up a grant application to "use RPN as translation script for ALL programming languages".

The Biblical tale of Tower of Babel is quite striking on how programming languages, platforms, operating systems have defragmented programmers.

I like Forth for its language features -- but I cannot use it on web programming -- which is why I created Fifth (5GL).

I am not sure if you are interested in web and mobile programming -- which is the main preference by younger programmers today.

[Rudy Velthuis]

But you see Pascal groups (occasionally) discussing C, C# or C++, and
vice versa, and C++ groups discussing C# or Java, etc. etc.

--
Rudy Velthuis http://www.rvelthuis.de

"There is not now, nor has there ever been, nor will there ever be,
any programming language in which it is the least bit difficult to
write bad code." -- Flon's Law

[dxf...@gmail.com]

Neither of those areas particularly requires
forth. The same would apply to many languages.
IMO it's not about making Forth attractive but
whether it is still relevant i.e. does the world
need a flexible low-level language and skilled
programmers to operate it. For 40 years the
answer seems to be yes, despite all the changes
that have occurred in the industry over that
time. E.g. Forth Inc *still* gets contracts to
write space-related apps. Don't you think that
would be interesting to young programmers?

[Rudy Velthuis]

Liang Ng wrote:

> Other languages do not have the reverse polish notation properties of
> "being able to translate into other languages"

How does being able to translate into other languages relate to
"reverse Polish notation"?

Languages like C# and C++ are also translatable into C or Pascal, etc.
etc.

What you probably mean is that you can convert Forth into another
language if you modify it long enough. Well, yes and no, because you'll
have to rewrite almost everything, including the parser, so it does not
need spaces to separate words, etc. That is not much different from
writing a compiler in, say, C.

So Forth does things differently, but not better than other languages
can turn into "meta-languages" by extending them with libraries and so
on.

--
Rudy Velthuis http://www.rvelthuis.de

"In this world, nothing is certain but death and taxes."
-- Benjamin Franklin.

[Albert van der Horst]

In article <xn0l75utx...@nntp.aioe.org>,

Rudy Velthuis <newsg...@rvelthuis.de> wrote:
>Liang Ng wrote:
>
>> Other languages do not have the reverse polish notation properties of
>> "being able to translate into other languages"
>
>How does being able to translate into other languages relate to
>"reverse Polish notation"?
>
>Languages like C# and C++ are also translatable into C or Pascal, etc.
>etc.
>
>What you probably mean is that you can convert Forth into another
>language if you modify it long enough. Well, yes and no, because you'll
>have to rewrite almost everything, including the parser, so it does not
>need spaces to separate words, etc. That is not much different from
>writing a compiler in, say, C.

Well yes, it is much different.
Remember my definition of TOKEN and the combination of e.g.
: pascal-delimiters "-+*/=<>:;.{}()[],!" ;
and PREFIX added to pascal names that are operator, interpunction
or brackets ? Suddenly the text is broken into Pascal tokens,
not blank delimited strings.
That is a different world from Backus Nauer , lex and yacc.
I'm working on lisp now, and ( becomes a prefix which adds
a lisp wordlist to the top of the search order.

>
>So Forth does things differently, but not better than other languages
>can turn into "meta-languages" by extending them with libraries and so
>on.
>
>--
>Rudy Velthuis http://www.rvelthuis.de
>
>"In this world, nothing is certain but death and taxes."
> -- Benjamin Franklin.

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

[m...@iae.nl]

On Wednesday, March 7, 2018 at 1:06:23 AM UTC+1, Albert van der Horst wrote:
[..]

> Well yes, it is much different.
> Remember my definition of TOKEN and the combination of e.g.
> : pascal-delimiters "-+*/=<>:;.{}()[],!" ;
> and PREFIX added to pascal names that are operator, interpunction
> or brackets ? Suddenly the text is broken into Pascal tokens,
> not blank delimited strings.
> That is a different world from Backus Nauer , lex and yacc.
> I'm working on lisp now, and ( becomes a prefix which adds
> a lisp wordlist to the top of the search order.
>
> >
> >So Forth does things differently, but not better than other languages
> >can turn into "meta-languages" by extending them with libraries and so
> >on.

Flex and bison are used in the (ng)SPICE commandline interface.
I found it one of the most difficult to understand (or read!)
parts of the source code (especially how it interfaces with
the C compiler on different platforms). SPICE has an
interpreter/incremental compiler for behavioral sources that
is even more difficult to fathom. Now that I have an handle
on them, these tasks appear trivial to do directly in Forth.

-marcel

[john]

In article <p7nae4$r4o$1...@cherry.spenarnc.xs4all.nl>,
alb...@cherry.spenarnc.xs4all.nl says...

> Well yes, it is much different.
> Remember my definition of TOKEN and the combination of e.g.
> : pascal-delimiters "-+*/=<>:;.{}()[],!" ;
> and PREFIX added to pascal names that are operator, interpunction
> or brackets ? Suddenly the text is broken into Pascal tokens,
> not blank delimited strings.
>

Interesting Albert.
When I was looking around for the most widely used operators/seperators etc.
I found some web pages with various tables of languages - I'll try and dig out
the links if you want them. (I dont have them to hand right now sorry)
I think there's at least one wikipedia page.

--

john

=========================
http://johntech.co.uk
=========================

[minf...@arcor.de]

Am Mittwoch, 7. März 2018 01:06:23 UTC+1 schrieb Albert van der Horst:
> In article <xn0l75utx...@nntp.aioe.org>,
> Rudy Velthuis <newsg...@rvelthuis.de> wrote:
> >Liang Ng wrote:
> >
> >> Other languages do not have the reverse polish notation properties of
> >> "being able to translate into other languages"
> >
> >How does being able to translate into other languages relate to
> >"reverse Polish notation"?
> >
> >Languages like C# and C++ are also translatable into C or Pascal, etc.
> >etc.
> >
> >What you probably mean is that you can convert Forth into another
> >language if you modify it long enough. Well, yes and no, because you'll
> >have to rewrite almost everything, including the parser, so it does not
> >need spaces to separate words, etc. That is not much different from
> >writing a compiler in, say, C.
>
> Well yes, it is much different.
> Remember my definition of TOKEN and the combination of e.g.
> : pascal-delimiters "-+*/=<>:;.{}()[],!" ;
> and PREFIX added to pascal names that are operator, interpunction
> or brackets ? Suddenly the text is broken into Pascal tokens,
> not blank delimited strings.
> That is a different world from Backus Nauer , lex and yacc.
> I'm working on lisp now, and ( becomes a prefix which adds
> a lisp wordlist to the top of the search order.
>

A scanner or lexical analyzer needs rules nonetheless, BNF or not.
Otherwise it can become a head scratching mess.

In Forth the string + 1 + 2 + 3 is unambiguous with 3 add operations

Leave out the blanks as separators you get +1+2+3.
How do you break this to tokens? It could well just mean the three numbers 1 2 3

[foxaudio...@gmail.com]

Point taken. And here we have Forth people discussing all of the above. :-)

B

[Alex]

One of the reasons that I quite like recognizers. The terrible mess that
is a BURG.

...
mem: INDIRI4(addr) "dword ptr %0"
mem: INDIRU1(addr) "byte ptr %0"
mem: INDIRU2(addr) "word ptr %0"
mem: INDIRU4(addr) "dword ptr %0"
mem: INDIRP4(addr) "dword ptr %0"
rc: reg "%0"
rc: con "%0"

mr: reg "%0"
mr: mem "%0"

mrc0: mem "%0"
mrc0: rc "%0"
mrc1: mem "%0" 1
mrc1: rc "%0"

mrc3: mem "%0" 3
mrc3: rc "%0"
reg: addr "lea %c,%0\n" 1
reg: mrc0 "mov %c,%0\n" 1
reg: LOADI1(reg) "# move\n" 1
reg: LOADI2(reg) "# move\n" 1
reg: LOADI4(reg) "# move\n" 3
reg: LOADU1(reg) "# move\n" 1
reg: LOADU2(reg) "# move\n" 1
reg: LOADU4(reg) "# move\n" 3

...



--
Alex

[Alex]

On 06-Mar-18 23:50, Rudy Velthuis wrote:
> Liang Ng wrote:
>
>> Other languages do not have the reverse polish notation properties
>> of "being able to translate into other languages"
>
> How does being able to translate into other languages relate to
> "reverse Polish notation"?
>
> Languages like C# and C++ are also translatable into C or Pascal,
> etc. etc.
>
> What you probably mean is that you can convert Forth into another
> language if you modify it long enough. Well, yes and no, because
> you'll have to rewrite almost everything, including the parser, so it
> does not need spaces to separate words, etc. That is not much
> different from writing a compiler in, say, C.
>
> So Forth does things differently, but not better than other
> languages can turn into "meta-languages" by extending them with
> libraries and so on.
>

RPN isn't a terribly good format for an intermediate language, since the
tree structure is partially hidden (child etc links are either implied
or need auxiliary information on the list with each entry to assist with
the traversal). And Java gets compiled to Java bytecode (which is stack
based), has a far bigger set of tools and community than Forth, and
no-one that uses Java AFAIK is claiming that

> other languages do not have the reverse polish notation properties of

> "being able to translate into other languages"

Since the main reason for a computer language is its translation to
something executable, I fail to see Liang Ng's point.

--
Alex

[a...@littlepinkcloud.invalid]

Umm, what is this stuff?

Andrew.

[Alex]

Input to burg or iburg; they are BURS (Bottom Up Rewriting Systems); a
burg "reads a burg specification and writes a matcher [in C] that does
DP [dynamic programming] at compile time." The output is a generated
program in C, a hard-coded matcher that uses an AST as input and spits
out optimal code sequences. The techniques can be applied to Forth code
generation.

This one is Hanson & Proebstring's iburg. The BNF is simple, but that
deson't make the rewriting rules very pretty. I believe the horrendous
syntax is due to the expense of tokenizing and parsing this stuff in C.
The Forth version is a work-in-progress. The original idea was to be
iburg compliant, hence the requirement to process the odd input.

https://github.com/drh/iburg

--
Alex

[Anton Ertl]

Actually this looks like lburg input to me, and is probably part of
the lcc source code; the intermediate representation (IR) looks like that
of lcc. burg/iburg is a little more primitive; see
<https://github.com/drh/iburg/blob/master/sample4.brg>.

You need to understand the formalism and the IR to understand this
code. Likewise with lex/yacc. But once you understand that, these
tools help improve the code compared to hand-coded stuff. E.g., when
using burg/iburg/lburg, you get certain optimality guarantees that
help in maintenance: E.g., when you add a correct rule, the generated
code is not going to be more costly (wrt the specified cost) than
without that rule. Hand-coded stuff typically uses greedy algorithms,
that do not give you that guarantee.

I don't think this has much connection to recognizers.
burg/iburg/lburg don't do what recognizers do, and vice versa. The
tool among the mentioned ones that is closest to recognizers is lex,
but even there the differences are big; it does not make sense to use
lex for Forth, nor do I see that recognizers would be useful for
replacing lex in existing lex applications.

Back to *burg: Here's some code from the RAFTS Forth compiler:

/* rule #cost# reducing #assembling*/
addr: I_PLUS(reg, cons) #0# drop 2drop #
addr: reg #0# drop 2drop 0 #

reg: I_FETCH(addr) #1# load-inst #asm-fetchi

reg represents the contents of a register, cons a constant, addr an
effective address, I_PLUS and I_FETCH are the IR names for + and @.

The rule and cost determine which rule is selected, then the according
reducing code is performed, which builds up a machine-level
representation, and the assembling part finally generates the machine
code; the latter step is not performed in one step because RAFTS
performs instruction scheduling and register allocation between
reducing and assembling.

>they are BURS (Bottom Up Rewriting Systems); a
>burg "reads a burg specification and writes a matcher [in C] that does
>DP [dynamic programming] at compile time." The output is a generated
>program in C, a hard-coded matcher that uses an AST as input and spits
>out optimal code sequences. The techniques can be applied to Forth code
>generation.
>
>This one is Hanson & Proebstring's iburg. The BNF is simple, but that
>deson't make the rewriting rules very pretty.

These are regular tree rules, a tree variant of regular grammars
(Chomsky Type 3); i.e., they reduce a tree to a non-terminal, or
produce a tree from a non-terminal. The rewrite stuff discussed by
Pelegri-Llopart (who introduced the BURS acronym) allowed rules like

I_PLUS(x,y): I_PLUS(y,x)

or somesuch, but none of the *burg tools that I am aware of allowed
anything other than nonterminals on the left-hand-side of the
productions, so one cannot really call them rewriting; nevertheless,
the "R" stuck.

>I believe the horrendous
>syntax is due to the expense of tokenizing and parsing this stuff in C.

What syntax would you use? These tools use yacc for parsing;
tokenizing is hand-coded in C in iburg.

- 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 2017: http://euro.theforth.net/

[Anton Ertl]

Alex <al...@rivadpm.com> writes:
>RPN isn't a terribly good format for an intermediate language, since the
>tree structure is partially hidden (child etc links are either implied
>or need auxiliary information on the list with each entry to assist with
>the traversal).

Actually, RPN is pretty nice for trees. Compact, and easy to build an
in-memory tree (easier than with prefix, or quadruples). But for DAGs
you need stuff like DUP etc. in addition to RPN. Still easy on
reading, but harder to output.

[Alex]

On 07-Mar-18 16:36, Anton Ertl wrote:
> Alex <al...@rivadpm.com> writes:
>> RPN isn't a terribly good format for an intermediate language, since the
>> tree structure is partially hidden (child etc links are either implied
>> or need auxiliary information on the list with each entry to assist with
>> the traversal).
>
> Actually, RPN is pretty nice for trees. Compact, and easy to build an

Yes, RPN is nice for trees, but it's not so great for ILs...

> in-memory tree (easier than with prefix, or quadruples). But for DAGs
> you need stuff like DUP etc. in addition to RPN. Still easy on
> reading, but harder to output.
>
> - anton
>


--

Alex

[Alex]

It may well be. I'd only got part way through this exercise.

>
> I don't think this has much connection to recognizers.

No, that part doesn't, but the textual parsing of the burg input does
(or tokenization; the word parse is too overloaded in a Forth context).

It was my intention to have a set of pre coded Forth words where
appropriate; for instance %% %start %term and so on which are fixed.
Then to write a recognizer for the undefined non-terminals e.g. reg:
stmt: con: and the associated tree part e.g. ASGNI2(vreg,reg) and costs.
There is enough white space in such lines as

stmt: LTU4(mem,rc) "cmp %0,%1\njb %a\n" 5

to make that a reasonably simple division to use the standard parser for
this. The only nit is embedded trees such as

stmt: ASGNI4(addr,ADDI4(mem,con1)) "inc %1\n" 3

which requires the recognizer to generate definitions that correctly
recurse when doing the tree matching (that is, in the example above,
when matching on ASGNI4 check the right child for a match on ADDI4).
(Alternatively these rules could be rewritten to avoid the problem by
using an intermediate non terminal.)

Because of the nature of Forth, it is also not necessary to write an
fburg (Forth burg) to generate further Forth code; we can simply create
words directly from the burg input, and then use them directly on the
DAG. Plus, there's no restriction on the text or the cost fields; we
could equally support

: code-increment ( %1 -- ) ( generate an increment ) ... ;
: cost-increment ( -- n ) ( cost for increment ) ... ;

stmt: ASGNI4(addr,ADDI4(mem,con1)) code-increment cost-increment

without loss of feature but with a gain in functionality & a decrease in
repetitious strings.

>
>> I believe the horrendous
>> syntax is due to the expense of tokenizing and parsing this stuff in C.
>
> What syntax would you use? These tools use yacc for parsing;
> tokenizing is hand-coded in C in iburg.

%term INDIRI1=9
%term CVPP4=4247
%term CVPP8=8343
%term CVPP16=16535
%term CVPU4=4246
%term CVPU8=8342

The representation of terminals as constant integers is frankly
dreadful, and only needed because this is C. It's not required in a
Forth implementation; we can use the address of the constant or an NT/XT
associated with it instead to get a unique value.

--
Alex

[Anton Ertl]

Alex <al...@rivadpm.com> writes:
>On 07-Mar-18 15:51, Anton Ertl wrote:
>> I don't think this has much connection to recognizers.
>
>No, that part doesn't, but the textual parsing of the burg input does
>(or tokenization; the word parse is too overloaded in a Forth context).

I probably would just use the original burg/iburg (or lburg) scanner
and parser and dump the output in a more Forth-friendly way; IIRC we
did use burg directly for RAFTS, though, only replacing the C-code
generator with one that generates Forth code.

>>> I believe the horrendous
>>> syntax is due to the expense of tokenizing and parsing this stuff in C.
>>
>> What syntax would you use? These tools use yacc for parsing;
>> tokenizing is hand-coded in C in iburg.
>
>%term INDIRI1=9
>%term CVPP4=4247
>%term CVPP8=8343
>%term CVPP16=16535
>%term CVPU4=4246
>%term CVPU8=8342
>
>The representation of terminals as constant integers is frankly
>dreadful, and only needed because this is C. It's not required in a
>Forth implementation; we can use the address of the constant or an NT/XT
>associated with it instead to get a unique value.

It seems to me that they were not satisfied with just having unique
values (the generator could have enumerated those, or they could have
used enums), they wanted the possibility to specify specific integers
(and here there seems some system to the integers that they use). So
I don't think that C is to blame for that. The strict division
between compilation and run-time probably does lead to things that we
would do differently in Forth, though.

[john]

In article <2018Mar...@mips.complang.tuwien.ac.at>,
an...@mips.complang.tuwien.ac.at says...

> . The strict division
> between compilation and run-time probably does lead to things that we
> would do differently in Forth, though.
>

and in some as yet to be implemented new 'not quite forth anymore' designs...
;-)

[Alex]

On 08-Mar-18 16:19, Anton Ertl wrote:
> Alex <al...@rivadpm.com> writes:
>> On 07-Mar-18 15:51, Anton Ertl wrote:
>>> I don't think this has much connection to recognizers.
>>
>> No, that part doesn't, but the textual parsing of the burg input does
>> (or tokenization; the word parse is too overloaded in a Forth context).
>
> I probably would just use the original burg/iburg (or lburg) scanner
> and parser and dump the output in a more Forth-friendly way; IIRC we
> did use burg directly for RAFTS, though, only replacing the C-code
> generator with one that generates Forth code.

I don't have much C or C++ experience, and the MS Windows toolchain,
although apparently of high quality, is horrendously complex. It will be
quicker to write it in Forth (if I have any time at all...).

>
>>>> I believe the horrendous
>>>> syntax is due to the expense of tokenizing and parsing this stuff in C.
>>>
>>> What syntax would you use? These tools use yacc for parsing;
>>> tokenizing is hand-coded in C in iburg.
>>
>> %term INDIRI1=9
>> %term CVPP4=4247
>> %term CVPP8=8343
>> %term CVPP16=16535
>> %term CVPU4=4246
>> %term CVPU8=8342
>>
>> The representation of terminals as constant integers is frankly
>> dreadful, and only needed because this is C. It's not required in a
>> Forth implementation; we can use the address of the constant or an NT/XT
>> associated with it instead to get a unique value.
>
> It seems to me that they were not satisfied with just having unique
> values (the generator could have enumerated those, or they could have
> used enums), they wanted the possibility to specify specific integers
> (and here there seems some system to the integers that they use). So
> I don't think that C is to blame for that. The strict division
> between compilation and run-time probably does lead to things that we
> would do differently in Forth, though.

I believe what I showed you here and elsewhere was generated burg input,
but I now can't find the source. Perhaps that's the case.

--
Alex

[Alex McDonald]

On 08/03/18 16:52, john wrote:
> In article <2018Mar...@mips.complang.tuwien.ac.at>,
> an...@mips.complang.tuwien.ac.at says...
>> . The strict division
>> between compilation and run-time probably does lead to things that we
>> would do differently in Forth, though.
>>
>
> and in some as yet to be implemented new 'not quite forth anymore' designs...
> ;-)
>
>

Apologies, I sent you an email rather than replying to the post.


Other language compilers are becoming more like Forth in that respect.

https://dlang.org/blog/2016/11/18/project-highlight-the-new-ctfe-engine/

-- Alex

[john]

> In article <p7smsq$32u$1...@dont-email.me>, al...@rivadpm.com says...>

>
> Apologies, I sent you an email rather than replying to the post.
>
> Other language compilers are becoming more like Forth in that respect.
>
> https://dlang.org/blog/2016/11/18/project-highlight-the-new-ctfe-engine/
>
> -- Alex

No problem - lots of people seem to prefer to email me.
I dont think your email reached me though - I normally see the incoming
info even when my security silently drops it (I dont normally send bounce replies)

A popular mistake is spelling john without the H - there are now many similar
domain names to my own (which I chose at the time because there weren't of course)

If you get stuck with my firewall find some way to get a sending IP address to me or you can
just try any link to the web site to check access - if it works you arent blocked. (I dont use apache
blocking much - I prefer to block IP's)
If I dont reply to a serious email I probably havn't seen it .

-----------

I took a look at the link you provided. I havn't had much time to think it through
but on first appearance I'd say the example given doesn't seem to lend
itself to any gains or give any reasonable idea of what is being attempted short of doing whatever
you can before runtime. Which is standard practice anyway..

I'd say with my current understanding that the correct implementation for the description
would be a simple look up table. That suggests a seperate program to generate
the data at design time is all you need. I dont see any advance or anything new.

I'm not sure what is being attempted with the example other than that because no actual
concept or methodology is being explained on the page and onpage link is dead.

I'm all for doing as much at design time as possible -(You should see my proposed design
for the TIOS IDE - programmers are going to hate me) but I can't see how you can get the
output of a runtime variable at designtime without its ranges being known in advance - hence use
a lookup table.

If I've missed something please correct me. I am interested in other peoples work.

[minf...@arcor.de]

If I am not mistaken this CTFE feature is used in D to replace preprocessors
or macros.

[a...@littlepinkcloud.invalid]

Alex McDonald <al...@rivadpm.com> wrote:
>
> Other language compilers are becoming more like Forth in that respect.
>
> https://dlang.org/blog/2016/11/18/project-highlight-the-new-ctfe-engine/

That's interesting to see. But they still have the misfeature of a
different implementation of the compile-time language and the run-time
language, There are some things that Forth still does better than
"newer" languages.

Andrew.

[Anton Ertl]

Alex <al...@rivadpm.com> writes:
>On 08-Mar-18 16:19, Anton Ertl wrote:
>> Alex <al...@rivadpm.com> writes:
>>> On 07-Mar-18 15:51, Anton Ertl wrote:
>>>> I don't think this has much connection to recognizers.
>>>
>>> No, that part doesn't, but the textual parsing of the burg input does
>>> (or tokenization; the word parse is too overloaded in a Forth context).
>>
>> I probably would just use the original burg/iburg (or lburg) scanner
>> and parser and dump the output in a more Forth-friendly way; IIRC we
>> did use burg directly for RAFTS, though, only replacing the C-code
>> generator with one that generates Forth code.

And the reason for that is that burg is full of cleverness wrt. tree
automata generation and automata compression. We did not want to
reimplement that. And we wanted burg for Forth compilation speed.

>I don't have much C or C++ experience, and the MS Windows toolchain,
>although apparently of high quality, is horrendously complex. It will be
>quicker to write it in Forth (if I have any time at all...).

Something iburg-like, possibly. Something burg-like, no. I can dig
up the modified burg with Forth output if you want.

>>> %term INDIRI1=9
>>> %term CVPP4=4247
>>> %term CVPP8=8343
>>> %term CVPP16=16535
>>> %term CVPU4=4246
>>> %term CVPU8=8342

...

>I believe what I showed you here and elsewhere was generated burg input,
>but I now can't find the source. Perhaps that's the case.

These terminal definitions occur in the *.md files of lcc (except that
the value of INDIRI1 is 1093 in lcc), and looking at the makefile, it
does not appear that the .md files are output by a different tool.

[Anton Ertl]

OTOH, it's the kind of feature, which, according to commercial Forth
vendors their customers don't use, making any improvements in that
area (such as the ]] ... [[ syntax) unnecessary. So I guess that in a
few more years even mainstream languages will have surpassed Forth in
that area, too.

[dxf...@gmail.com]

On Sunday, March 11, 2018 at 2:07:01 AM UTC+11, Anton Ertl wrote:
> a...@littlepinkcloud.invalid writes:
> >Alex McDonald <al...@rivadpm.com> wrote:
> >>
> >> Other language compilers are becoming more like Forth in that respect.
> >>
> >> https://dlang.org/blog/2016/11/18/project-highlight-the-new-ctfe-engine/
> >
> >That's interesting to see. But they still have the misfeature of a
> >different implementation of the compile-time language and the run-time
> >language, There are some things that Forth still does better than
> >"newer" languages.
>
> OTOH, it's the kind of feature, which, according to commercial Forth
> vendors their customers don't use, making any improvements in that
> area (such as the ]] ... [[ syntax) unnecessary. So I guess that in a
> few more years even mainstream languages will have surpassed Forth in
> that area, too.

'mainstream languages' have exactly the same
problem as ANS-Forth. Change requires breaking
with the past - which neither you nor Forth's
vendors are willing to do for fear of losing
users and their support. Chuck had no such
inhibitions.

[Cecil Bayona]

On 3/10/2018 7:29 PM, dxf...@gmail.com wrote:
> 'mainstream languages' have exactly the same
> problem as ANS-Forth. Change requires breaking
> with the past - which neither you nor Forth's
> vendors are willing to do for fear of losing
> users and their support. Chuck had no such
> inhibitions.

Its interesting to see all the changes the Charles made to the language
in his quest for a smaller more concise language, in a constant quest to
simplify Forth. He was definitely not afraid of rocking the boat.

I particularly like his cmForth, and afterwards his machine Forth and
their simplicity, but I'm not fond of ColorForth mainly because of
aesthetics, the low resolution display is not appealing to me.

--
Cecil - k5nwa

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> a...@littlepinkcloud.invalid writes:
>>Alex McDonald <al...@rivadpm.com> wrote:
>>>
>>> Other language compilers are becoming more like Forth in that respect.
>>>
>>> https://dlang.org/blog/2016/11/18/project-highlight-the-new-ctfe-engine/
>>
>>That's interesting to see. But they still have the misfeature of a
>>different implementation of the compile-time language and the run-time
>>language, There are some things that Forth still does better than
>>"newer" languages.
>
> OTOH, it's the kind of feature, which, according to commercial Forth
> vendors their customers don't use, making any improvements in that
> area (such as the ]] ... [[ syntax) unnecessary.

What? Some commerical Forth vendors don't want to add your favoured
extensions, therefore thir customers don't do compile-time
programming? Are you serious? Even CREATE ... DOES> is an example of
that.

Andrew.

[a...@littlepinkcloud.invalid]

Cecil Bayona <cba...@cbayona.com> wrote:
> On 3/10/2018 7:29 PM, dxf...@gmail.com wrote:
>> 'mainstream languages' have exactly the same problem as
>> ANS-Forth. Change requires breaking with the past - which neither
>> you nor Forth's vendors are willing to do for fear of losing users
>> and their support. Chuck had no such inhibitions.
>
> Its interesting to see all the changes the Charles made to the language
> in his quest for a smaller more concise language, in a constant quest to
> simplify Forth. He was definitely not afraid of rocking the boat.

Or of making mistakes that he later had to back out. Getting rid of
source code was the most major one.

> I particularly like his cmForth,

There was also a polyFORTH port for Novix, and it was much better from
the point of view of writing real programs. Extreme minimalisim is
all well and good, but not always what you want if you need to ship an
application and get on with the rest of your life.

Andrew.

[Alex]

On 10-Mar-18 14:16, Anton Ertl wrote:
> Alex <al...@rivadpm.com> writes:


>> I don't have much C or C++ experience, and the MS Windows toolchain,
>> although apparently of high quality, is horrendously complex. It will be
>> quicker to write it in Forth (if I have any time at all...).
>
> Something iburg-like, possibly. Something burg-like, no. I can dig
> up the modified burg with Forth output if you want.

That would be appreciated, if it doesn't take you too much effort.


--
Alex

[Anton Ertl]

dxf...@gmail.com writes:
>On Sunday, March 11, 2018 at 2:07:01 AM UTC+11, Anton Ertl wrote:
>> a...@littlepinkcloud.invalid writes:
>> >Alex McDonald <al...@rivadpm.com> wrote:
>> >>
>> >> Other language compilers are becoming more like Forth in that respect.
>> >>
>> >> https://dlang.org/blog/2016/11/18/project-highlight-the-new-ctfe-engine/
>> >
>> >That's interesting to see. But they still have the misfeature of a
>> >different implementation of the compile-time language and the run-time
>> >language, There are some things that Forth still does better than
>> >"newer" languages.
>>
>> OTOH, it's the kind of feature, which, according to commercial Forth
>> vendors their customers don't use, making any improvements in that
>> area (such as the ]] ... [[ syntax) unnecessary. So I guess that in a
>> few more years even mainstream languages will have surpassed Forth in
>> that area, too.
>
>'mainstream languages' have exactly the same
>problem as ANS-Forth. Change requires breaking
>with the past

Adding features does not require breaking existing programs, certainly
not in Forth, and mainstream languages also add features, so
apparently they have ways to deal with that problem, too.

Removing features (even non-documented ones) from an implementation is
likely to break existing programs, so any sensible implementor will
try to avoid that (there are quite a number of implementors out there
who are missing that sense). De-standardizing features just
de-standardizes existing programs, which has no direct consequences,
but also no benefit.

An incompatible change in the standard for an existing word (such as
happened with PICK and NOT in Forth-83) breaks existing programs and
results in lots of practical problems: Do implementors support the
existing programs or the new standard? And even if they do both by
providing implementations of both, maintainers of existing programs
then have to decide to convert whole programs in one step. Python is
facing this problem with the incompatible Python 2->3 transition.

>which neither you nor Forth's
>vendors are willing to do for fear of losing
>users and their support. Chuck had no such
>inhibitions.

And as a result, he has hardly any users (even relative to other Forth
usage), despite the lip service paid to him and his ideas by many. I
guess that's ok for him, but that would not be ok for a standard.

[Anton Ertl]

That's what the vendors' claim.

>Are you serious?

Better ask them.

>Even CREATE ... DOES> is an example of
>that.

I guess that, if CREATE...DOES> was not in the standard already, any
proposal for it would face strong opposition; the vendors would argue
that their customers don't use it and don't ask for it, and are happy
with the non-standard solutions that the vendors provide to cater for
the needs that could be addressed with CREATE...DOES>. And of course,
you would oppose it because adding a feature is an anathema to the
minimalism that you use as guiding principle except when you don't.

[john]

In article <2018Mar1...@mips.complang.tuwien.ac.at>,
an...@mips.complang.tuwien.ac.at says...

> Removing features (even non-documented ones) from an implementation is
> likely to break existing programs, so any sensible implementor will
> try to avoid that
>

This is an issue I've given thought to myself.

Indeed your comment is the best approach where possible - but variations in
architecture and environment makes it complex. Many of us have watched the
issues of fonts and character sets come into play when the internet was
expanded out of the anglo-latin countries. I dont think I'm insulting anyone when
I say the current situation with that is cumbersome at best. The mess inside
lazarus/fpc around this issue shows just how hard it is to even document the
situation in a usable manner. What to include - what not include?

The ability of a TIL such as forth to pull itself up by it's bootstraps
from a very low starting point should make it possible to build in a
means of dealing with the loss of features fairly efficiently..

I'm not yet sure if anything can be implemented that would be
more efficient than allowing a simple library inclusion however.
I thought maybe some form of meta-data - but maybe not.

This touches on both my software and hardware designs - one thing I'm
trying to do is to have a small number of variations in my CPU design
and allow the lower design CPU's to have a software module to make up
for hardware loss - very similar to having a software floating point for a system
with no hardware FP processor. the idea being to allow everything to at least run.

If anyone has any solution based ideas that are more efficient on that I'd
welcome seeing them.

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> a...@littlepinkcloud.invalid writes:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> a...@littlepinkcloud.invalid writes:
>>>>Alex McDonald <al...@rivadpm.com> wrote:
>>>>>
>>>>> Other language compilers are becoming more like Forth in that respect.
>>>>>
>>>>> https://dlang.org/blog/2016/11/18/project-highlight-the-new-ctfe-engine/
>>>>
>>>>That's interesting to see. But they still have the misfeature of a
>>>>different implementation of the compile-time language and the run-time
>>>>language, There are some things that Forth still does better than
>>>>"newer" languages.
>>>
>>> OTOH, it's the kind of feature, which, according to commercial Forth
>>> vendors their customers don't use, making any improvements in that
>>> area (such as the ]] ... [[ syntax) unnecessary.
>>
>>What? Some commerical Forth vendors don't want to add your favoured
>>extensions, therefore thir customers don't do compile-time
>>programming?
>
> That's what the vendors' claim.

Gosh.

>>Are you serious?
>
> Better ask them.

I remember one vendor saying something sort-of in that direction, but
only vaguely.

>>Even CREATE ... DOES> is an example of
>>that.
>
> I guess that, if CREATE...DOES> was not in the standard already, any
> proposal for it would face strong opposition;

Of course it would, and it should: it would be a large change to the
language. These things have to be discussed in detail, and every
significant change should be tested.

I can't quite imagine Forth without some means of making user-defined
data words, but today, I don't think you'd necessarily choose
CREATE ... DOES>. That "return in the middle" is rather hacky, and
perhaps a solution using quotations would work better.

> the vendors would argue that their customers don't use it and don't
> ask for it, and are happy with the non-standard solutions that the
> vendors provide to cater for the needs that could be addressed with
> CREATE...DOES>.

> And of course, you would oppose it because adding a feature is an
> anathema to the minimalism that you use as guiding principle except
> when you don't.

It's not really _my_ guiding principle. Of course, the Basic
Principle that is the origin of Forth's design has to be balanced with
functionality: I would draw the line in a very different place than,
say, Chuck Moore. But it's vitally important to remind people of the
principle from time to time, because there is no other opposing
pressure. After all, it only takes a half-dozen instructions; so why
not?

Andrew.

[Anton Ertl]

a...@littlepinkcloud.invalid writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> I guess that, if CREATE...DOES> was not in the standard already, any
>> proposal for it would face strong opposition;
>
>Of course it would, and it should: it would be a large change to the
>language. These things have to be discussed in detail, and every
>significant change should be tested.

Yes, they should be discussed in detail, but they are not. There is
fundamental opposition, with arguments that have nothing to do with
the details (neither "my customers don't use this" nor "adding
features is against the Basic Principle" can be overcome by discussing
or changing details), so the details are not discussed.

And once the supporters of a proposal have convinced these
fundamentalists that the basic idea of the proposal is actually worth
supporting, they certainly don't want to rock the boat by discussing
details (that is, if they have any energy left for discussing the
proposal). In this way the fundamental opposition we see in the last
years can lead to lower-quality proposals.

Of course, if you mean the ever-popular name discussion with
"details", yes, this is happening. But that's all. Already stack
effects are hardly discussed.

>I can't quite imagine Forth without some means of making user-defined
>data words, but today, I don't think you'd necessarily choose
>CREATE ... DOES>. That "return in the middle" is rather hacky, and
>perhaps a solution using quotations would work better.

Yes. But the discussion would not be along these lines of the best
interface for this functionality. Instead we would read again and
again that the functionality is not needed, because "my customers
don't use it" and because "it's against the Basic Principle".

>Of course, the Basic
>Principle that is the origin of Forth's design has to be balanced with
>functionality

Balance! Now that's an idea I have never seen when you argued "Basic
Principle!" against proposals. It's just that in some proposals you
argue "Basic Principle!", and in others you don't.

[Stephen Pelc]

On Mon, 12 Mar 2018 09:14:52 -0500, a...@littlepinkcloud.invalid wrote:

>>>What? Some commerical Forth vendors don't want to add your favoured
>>>extensions, therefore thir customers don't do compile-time
>>>programming?
>>
>> That's what the vendors' claim.
>
>Gosh.

Don't believe everything you read on the internet.

Vendors are correctly cautious about adding new features. In
particular, we are now being told that recognisers are the
"one true way" to avoid all the problems with words with
"non-default compilation semantics". As my paper at EuroForth
2017 demonstrates, words that were previously "state-smart" can
be implemented completely correctly according to Forth-94 and
Forth-2012, providing that the Forth kernel is correctly
implemented ... and almost none of them are.

The diatribe about "state-smart words are evil" has been running
for 20 years or more. However, the correct statement is probably
along the lines "Words with non-default compilation semantics
need to be correctly implemented".

Sometimes it really does take 20 years for the lights to go on.

Stephen


--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441
web: http://www.mpeforth.com - free VFX Forth downloads

[Albert van der Horst]

In article <IsKdne9SU7bBFjvH...@supernews.com>,

The first thing to realise is that CREATE can always be the first
word in the definition.
With my oop I have replaced
: meta CREATE build-field DOES> work-on-field ;
with
class meta
M: name-for-doer work-on-field M;
build-field
endclass

The M: defines a method, a quotation is not much use here because
you must be able to name methods, so then you have special syntax
anyway in order to couple the two.

Now the basic idea borrowed from DOES> is that methods are
inserted on the fields where they are used.
This works with multiple fields.
And we get
{
M: name-for-doer work-on-field M;
build-field } +
as in repeat the enclosed stuff 1 or more times.

Once one realizes that also there are multiple methods
possible for the same fields,
then one discovers there are no fields, just setters and getters.

class variable
M: V@ @ M;
M: V! ! M;
,
endclass

So this could replace CREATE DOES>

<SNIP>
>Andrew.
--
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

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> a...@littlepinkcloud.invalid writes:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> I guess that, if CREATE...DOES> was not in the standard already, any
>>> proposal for it would face strong opposition;
>>
>>Of course it would, and it should: it would be a large change to the
>>language. These things have to be discussed in detail, and every
>>significant change should be tested.
>
> Yes, they should be discussed in detail, but they are not. There is
> fundamental opposition, with arguments that have nothing to do with
> the details (neither "my customers don't use this" nor "adding
> features is against the Basic Principle" can be overcome by discussing
> or changing details), so the details are not discussed.

I have seen considerable such discussion here.

> And once the supporters of a proposal have convinced these
> fundamentalists that the basic idea of the proposal is actually
> worth supporting, they certainly don't want to rock the boat by
> discussing details (that is, if they have any energy left for
> discussing the proposal). In this way the fundamental opposition we
> see in the last years can lead to lower-quality proposals.

Every proposal must be tested for its value. That there is already a
way to do X in Forth and we don't need another one is a valid
objection, and we should discuss that before getting distracted by
details of names or stack effects,

Also, it's important to take a broad overview of the whole language
and environment when considering how well a proposal fits with what's
already there.

> Of course, if you mean the ever-popular name discussion with
> "details", yes, this is happening. But that's all. Already stack
> effects are hardly discussed.

So discuss it, then.

>>I can't quite imagine Forth without some means of making user-defined
>>data words, but today, I don't think you'd necessarily choose
>>CREATE ... DOES>. That "return in the middle" is rather hacky, and
>>perhaps a solution using quotations would work better.
>
> Yes. But the discussion would not be along these lines of the best
> interface for this functionality.

I don't believe that at all.

> Instead we would read again and again that the functionality is not
> needed, because "my customers don't use it" and because "it's
> against the Basic Principle".

These are both excellent arguments. The first part is no less than
"This proposal is useless in the context of real-world programs that
people write." It's an appropriate counter to the toy "cute"
proposals we sometimes see.

>>Of course, the Basic Principle that is the origin of Forth's design
>>has to be balanced with functionality
>
> Balance! Now that's an idea I have never seen when you argued "Basic
> Principle!" against proposals.

I am providing balance; in other words, I am providing a counter-
argument. I don't have to provide both sides of an argument. Neither
do you. This is how it's supposed to work.

> It's just that in some proposals you argue "Basic Principle!", and
> in others you don't.

Of course: sometimes it's appropriate. Sometimes it's not important,
sometimes it is. Sometimes people need reminding., more frequently
than I would like.

Andrew.

[a...@littlepinkcloud.invalid]

Albert van der Horst <alb...@cherry.spenarnc.xs4all.nl> wrote:
> So this could replace CREATE DOES>

Nice. One other observation is that DOES> is no more than a way of
creating a class of objects, but with only one method.

Andrew.

[a...@littlepinkcloud.invalid]

Stephen Pelc <ste...@mpeforth.com> wrote:
> On Mon, 12 Mar 2018 09:14:52 -0500, a...@littlepinkcloud.invalid wrote:
>
>>>>What? Some commerical Forth vendors don't want to add your favoured
>>>>extensions, therefore thir customers don't do compile-time
>>>>programming?
>>>
>>> That's what the vendors' claim.
>>
>>Gosh.
>
> Don't believe everything you read on the internet.

Don't worry, I didn't!

Andrew.

[Anton Ertl]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <IsKdne9SU7bBFjvH...@supernews.com>,
> <a...@littlepinkcloud.invalid> wrote:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> I guess that, if CREATE...DOES> was not in the standard already, any
>>> proposal for it would face strong opposition;
>>
>>Of course it would, and it should: it would be a large change to the
>>language. These things have to be discussed in detail, and every
>>significant change should be tested.
>>
>>I can't quite imagine Forth without some means of making user-defined
>>data words, but today, I don't think you'd necessarily choose
>>CREATE ... DOES>. That "return in the middle" is rather hacky, and
>>perhaps a solution using quotations would work better.
>
>The first thing to realise is that CREATE can always be the first
>word in the definition.

Sure you can refactor your words to satisfy this restriction, but why
should you? Here are some examples of where this restriction would
hurt:

falign here 10 floats allot create , does> @ swap floats +
\ thanks to the lack of standard-guaranteed alignment

wordlist create , does> @ ...

noname create ... does> ...

['] create execute-parsing ... does> ...

>With my oop I have replaced
> : meta CREATE build-field DOES> work-on-field ;
>with
> class meta
> M: name-for-doer work-on-field M;
> build-field
> endclass
>
>The M: defines a method, a quotation is not much use here because
>you must be able to name methods

In CREATE...DOES> you do not have to name the stuff after the DOES>,
and it is usually not done, because there is no point. But if you
want to name the word, then yes, with a modern DOES> replacement you
use a colon definition instead of a quotation; e.g.:

\ With a named word:
: work-on-field
work on field ;

: meta create build-field ['] work-on-field set-does> ;

\ With a quotation:
: meta create build-field [: work on field ;] set-does> ;

Note that these SET-DOES>-using variants are more efficient than using
"DOES> work-on-field ;", because the DOES> variant performs two levels
of calls at run-time, whereas the SET-DOES> variants perform only one.
[On Forth systems with tail-call optimization such as SwiftForth this
difference would be smaller, on systems with inlining it would vanish.]

[Stephen Pelc]

On Tue, 13 Mar 2018 04:10:53 -0500, a...@littlepinkcloud.invalid wrote:

>Nice. One other observation is that DOES> is no more than a way of
>creating a class of objects, but with only one method.

DOES> performs another important function. It tells the compiler
that what is before DOES> and what is after DOES> are effectively
separate words. We have no other (standard) way to do this at the
moment except to use quotations for the fragments. Using quotations
for this purpose leads to very clumsy notation compared to what we
have been able to do beforehand.

Note that this issue arose with the rise of optimising compilers.

[Albert van der Horst]

In article <2018Mar1...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>In article <IsKdne9SU7bBFjvH...@supernews.com>,
>> <a...@littlepinkcloud.invalid> wrote:
>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>> I guess that, if CREATE...DOES> was not in the standard already, any
>>>> proposal for it would face strong opposition;
>>>
>>>Of course it would, and it should: it would be a large change to the
>>>language. These things have to be discussed in detail, and every
>>>significant change should be tested.
>>>
>>>I can't quite imagine Forth without some means of making user-defined
>>>data words, but today, I don't think you'd necessarily choose
>>>CREATE ... DOES>. That "return in the middle" is rather hacky, and
>>>perhaps a solution using quotations would work better.
>>
>>The first thing to realise is that CREATE can always be the first
>>word in the definition.
>
>Sure you can refactor your words to satisfy this restriction, but why
>should you? Here are some examples of where this restriction would
>hurt:
>
>falign here 10 floats allot create , does> @ swap floats +
>\ thanks to the lack of standard-guaranteed alignment
>
>wordlist create , does> @ ...
>
>noname create ... does> ...
>
>['] create execute-parsing ... does> ...

None of these examples use create to make a meta word.
So they are besides the point.

>
>>With my oop I have replaced
>> : meta CREATE build-field DOES> work-on-field ;
>>with
>> class meta
>> M: name-for-doer work-on-field M;
>> build-field
>> endclass
>>
>>The M: defines a method, a quotation is not much use here because
>>you must be able to name methods
>
>In CREATE...DOES> you do not have to name the stuff after the DOES>,
>and it is usually not done, because there is no point. But if you
>want to name the word, then yes, with a modern DOES> replacement you
>use a colon definition instead of a quotation; e.g.:
>
>\ With a named word:
>: work-on-field
> work on field ;
>
>: meta create build-field ['] work-on-field set-does> ;
>
>\ With a quotation:
>: meta create build-field [: work on field ;] set-does> ;
>
>Note that these SET-DOES>-using variants are more efficient than using
>"DOES> work-on-field ;", because the DOES> variant performs two levels
>of calls at run-time, whereas the SET-DOES> variants perform only one.
>[On Forth systems with tail-call optimization such as SwiftForth this
>difference would be smaller, on systems with inlining it would vanish.]

I've now ample experience with my kind of objects.
It was based on a current object, but it can easily be made
to work with an object on the stack.
The Probst lisp made me realize I can have M:r that starts with
<offset> +
instead of M: that starts with
^object @ +

I'm confident that this can be optimized as well as any other
field/method scheme.

set-does> is clunky because it is contextual. It works on
something that happens to be most recent. This is in fact more
harmful than the much dreaded global variables.
Remember STATE ? At least that is in the spotlight and
it is well documented.

>--
>- anton

[minf...@arcor.de]

Am Dienstag, 13. März 2018 13:54:06 UTC+1 schrieb Stephen Pelc:
> On Tue, 13 Mar 2018 04:10:53 -0500, a...@littlepinkcloud.invalid wrote:
>
> >Nice. One other observation is that DOES> is no more than a way of
> >creating a class of objects, but with only one method.
> DOES> performs another important function. It tells the compiler
> that what is before DOES> and what is after DOES> are effectively
> separate words. We have no other (standard) way to do this at the
> moment except to use quotations for the fragments. Using quotations
> for this purpose leads to very clumsy notation compared to what we
> have been able to do beforehand.
>

I wouldn't call it clumsy. The after DOES> part is hidden and does not appear
in the dictionary. It is also auto-IMMEDIATE in a way. So one obtains a lot
with a very tight syntax.

Of course it does not solve other needs like nice-looking definition of words
with dual semantics like TO. BTW for such I am using a word <COMPILES.

[Albert van der Horst]

In article <5aa7c8ac....@news.eternal-september.org>,

Stephen Pelc <ste...@mpeforth.com> wrote:
>On Tue, 13 Mar 2018 04:10:53 -0500, a...@littlepinkcloud.invalid wrote:
>
>>Nice. One other observation is that DOES> is no more than a way of
>>creating a class of objects, but with only one method.

>DOES> performs another important function. It tells the compiler
>that what is before DOES> and what is after DOES> are effectively
>separate words. We have no other (standard) way to do this at the
>moment except to use quotations for the fragments. Using quotations
>for this purpose leads to very clumsy notation compared to what we
>have been able to do beforehand.

This detracts from the disadvantages.
- we are restricted to objects with one method
- other properties (fields) of the object require the notation
' object >BODY or even ['] object >BODY
1. An execution token is not proper to derive data addresses
from, a dictionary entry address 1) could be.
2. the ' requires that the object has a name.
This is equally backwards as having no anonymous functions,
the dark times before quotations.

The notation as I suggested is an other solution; I pointed out
that IMO quotations are next to unusable for this kind of thing.

The example of Probst lisp generates anonymous `` structs '' all
the time. I've modified it out using my type of classes.
Because a word BUILD-xxx is defined automatically for each class
a whole number of building words disappear from the source.
(There after introducing anonymous function for xt's that are
just filled in in a table also helps a lot.)

>Note that this issue arose with the rise of optimising compilers.

I don't see this connection, maybe you can elaborate?
>
>Stephen


1) Sometimes called "name token" a notation that
suggests that anonymous objects are impossible.

Groetjes Albert

[minf...@arcor.de]

This comes from trying to extend the DOES> mechanism to OOP.
Dick Pountain wrote a whole book about it.

IMHO the thing is that the DOES> method does not require a message.
It just shoots like Django. Unusable for OOP.

And message passing styles never found any consensus. So DIY prevails.
But this is an old story ad nauseam.

[Anton Ertl]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2018Mar1...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>In article <IsKdne9SU7bBFjvH...@supernews.com>,
>>> <a...@littlepinkcloud.invalid> wrote:
>>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>>> I guess that, if CREATE...DOES> was not in the standard already, any
>>>>> proposal for it would face strong opposition;

...

>>>The first thing to realise is that CREATE can always be the first
>>>word in the definition.
>>
>>Sure you can refactor your words to satisfy this restriction, but why
>>should you? Here are some examples of where this restriction would
>>hurt:
>>
>>falign here 10 floats allot create , does> @ swap floats +
>>\ thanks to the lack of standard-guaranteed alignment
>>
>>wordlist create , does> @ ...
>>
>>noname create ... does> ...
>>
>>['] create execute-parsing ... does> ...
>
>
>None of these examples use create to make a meta word.
>So they are besides the point.

Whatever "a meta word" is supposed to be. These are examples of using
CREATE in conjunction with DOES> (or a DOES>-replacement), and they
are right to the point, which is about CREATE...DOES>. Maybe you
intended to discuss a different point, but failed to make it clear
what that point is.

>>> : meta CREATE build-field DOES> work-on-field ;

...

>>In CREATE...DOES> you do not have to name the stuff after the DOES>,
>>and it is usually not done, because there is no point. But if you
>>want to name the word, then yes, with a modern DOES> replacement you
>>use a colon definition instead of a quotation; e.g.:
>>
>>\ With a named word:
>>: work-on-field
>> work on field ;
>>
>>: meta create build-field ['] work-on-field set-does> ;
>>
>>\ With a quotation:
>>: meta create build-field [: work on field ;] set-does> ;

...

>set-does> is clunky because it is contextual. It works on
>something that happens to be most recent.

Just like DOES> and IMMEDIATE. I actually would prefer to do both
functions in one word, and have suggested <DOES-CREATE several times
here (to little resonance). For the example above this would look as
follows:

: meta [: work on field ;] <does-create build-field ;

However, if you consider all the various things we want to attach to a
word (a name or its lack, execution/interpretation semantics and its
optimizer implementation, compilation semantics/immediacy, TO
semantics), providing all that as parameters to a single word would be
pretty monstrous; and even if we had such a word, if a system or
future standard wanted to add an additional feature, that word would
prove insufficient. I do not have a solution for this problem yet.

>This is in fact more
>harmful than the much dreaded global variables.
>Remember STATE ? At least that is in the spotlight and
>it is well documented.

The problem with STATE-smartness is that the problems occur in corner
cases, often far from the cause, possibly affecting a different user
than the author. All spotlight and documentation does not change
that.

By contrast, while the implicit state of the "most recent definition"
is not a really good interface, it has not proven particularly
troublesome. I guess that this use of an implicit state is relatively
local in most cases, and at least intentional in the other cases. And
that bugs that come from this design are already exposed and fixed in
the development phase of the program.

[Albert van der Horst]

If you had placed your comment behind this line, you would
have made a fool of yourself. Now I just assume you're shooting
from the hip.

>
>- anton

Groetjes Albert

[silex....@gmail.com]

On Tuesday, February 27, 2018 at 4:44:37 AM UTC-7, Liang Ng wrote:
> I came across Forth when I was looking for a programming language that I can use easily on mobile phone -- basically without punctuation.
>
> Eventually I realized the properties of the reverse polish notation -- it can be used to represent abstract syntax tree -- which means RPN can be used to translate into ANY programming language.
>
> To be honest, do you think Forth is readily appealing to newbie programmers today?
>
> I think Forth would attract intermediate to expert programmers, who have already mastered quite a few programming languages -- which is the norm nowadays.
>
> And yet, RPN has the potential to help simplify programming by being the ONE UNIVERSAL programming language that can integrate with other programming languages in active use today -- which is practical benefit besides being theoretically appealing.
>
> Regrettably, after a long pursuit for review, what I received were a couple of stern rejection -- no, we don't review non-Forth code.
>
> Oh well. Perhaps a "Forth hybrid" language is too avant garde for some. However, without a Forth-hybrid language, how would you expect to attract younger programmers to Forth?

I am such a programmer. I asked around for a good language to begin with. This amounted to two people. Person one has a successful business out of his garage, and had no experience with Unix machines. Person two develops software for embedded machines called "street lights", that have to blink in different colors at different times, in a place called "New York City."

Person one was a fan of object oriented programming. Person two hates java, thought that python was elegant, and when I needed an old laptop, but didn't have the experience to install a POSIX distro, he had a few choices ready for me.

So, person one used high level, high abstraction type programming, because it's the lingua-de-jour, or at least the language set for a successful small business app developer. Person two seemed to actually understand programming from some other...non commercially oriented place, where the code and it's structure could be examined with seeming independence from the project.

Person two gave me a copy of the 2nd edition of Starting Forth.

In closing, I think you have to take each "newbie" at their own interest level. My personal interest skewed towards shell scripting, and discovering the CLI for the first time. In a way, by recommending Forth, person two got me to look at a hybrid language, from what I understand on this blog-post.

At the end of the day, I'm a Humanities Major who only recently declared a second undergraduate specialty in the college of science. Born out of frustration with the widespread adoption of complex geospatial tools for archaeological research, my focus on forth is because I truly want to understand.

If you assume that the newbie you're dealing with is profit or project oriented, that goes on the stack first.

yourassumption thenewbie *
might return a weird value.

goodluck toyou +

[Paul Rubin]

silex....@gmail.com writes:
> At the end of the day, I'm a Humanities Major who only recently
> declared a second undergraduate specialty in the college of
> science. Born out of frustration with the widespread adoption of
> complex geospatial tools for archaeological research, my focus on
> forth is because I truly want to understand.

For practical use, I think you are better off with Python, since I
expect a lot of your colleagues will use it, there's tons of GIS
libraries for it, etc. You can even control traffic lights with it
(MicroPython). Forth IMHO is worth being interested in if you're into
languages for their own sake, or if you have special requirements
(typically embedded) for which Forth is particularly suited.