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

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

What about code blocks (not Forth blocks)?

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

Contents

  What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-17 23:56 -0800
    Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-18 01:14 -0800
      Re: What about code blocks (not Forth blocks)? Mark Wills <markrobertwills@yahoo.co.uk> - 2013-12-18 01:34 -0800
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 02:33 -0800
        Re: What about code blocks (not Forth blocks)? Coos Haak <chforth@hccnet.nl> - 2013-12-18 14:36 +0100
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 06:24 -0800
            Re: What about code blocks (not Forth blocks)? Coos Haak <chforth@hccnet.nl> - 2013-12-19 02:54 +0100
              Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 22:12 -0800
        Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-18 05:43 -0800
    Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-18 11:21 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 04:31 -0800
        Re: What about code blocks (not Forth blocks)? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2013-12-18 04:49 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 05:12 -0800
    Re: What about code blocks (not Forth blocks)? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-18 08:26 -1000
      Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-18 11:03 -0800
        Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 11:21 -0800
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 11:19 -0800
        Re: What about code blocks (not Forth blocks)? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-18 10:08 -1000
          Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-18 21:58 +0100
            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-19 14:15 +1100
              Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 13:32 +0000
                Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-20 21:07 +1100
                  Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 12:35 +0000
                    Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 13:02 +0000
                    Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-22 14:19 +1100
                      Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-22 10:15 +0000
                        Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-24 12:30 +1100
                          Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-24 16:48 +0000
                            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-28 11:08 +1100
                              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-28 11:40 +0000
                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-26 18:03 +0000
                            Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-26 10:34 -0800
                              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-27 15:53 +0000
                                Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 17:26 +0000
                                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-28 17:53 +0000
                                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 18:21 +0000
                                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 14:49 +0000
                                        Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-29 20:45 +0000
                                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:08 +0000
                                            Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-30 20:00 +0000
                                  Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-28 18:04 +0000
                                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 18:47 +0000
                                      Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 19:12 +0000
                            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-28 11:09 +1100
                              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-28 13:45 +0000
            Re: What about code blocks (not Forth blocks)? Elizabeth D Rather <erather@forth.com> - 2013-12-18 19:04 -1000
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-19 09:25 +0000
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 05:00 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 23:41 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 01:00 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 02:47 -0800
            Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-19 11:23 +0000
              Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 03:52 -0800
    Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-19 15:58 +0000
      Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 10:05 -0800
        Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 20:07 +0000
          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 12:33 -0800
            Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 20:33 +0000
              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-19 20:52 +0000
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 18:52 -0800
            Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-28 12:52 -0600
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-28 11:47 -0800
                Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 07:39 -0600
                  Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 08:11 -0800
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 15:25 +0000
                Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 08:15 -0800
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 16:03 +0000
                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-29 20:54 +0000
                      Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-29 13:38 -0800
                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:04 +0000
                        Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-30 20:05 +0000
                          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-30 16:49 -0800
                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 17:27 +0000
                Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 16:40 -0600
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:51 +0000
                    Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 11:15 -0600
                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:37 +0000
                        Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:07 -0600
          Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 13:50 +0000
        Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2013-12-19 21:49 -0800
          Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 08:56 +0000
            Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-04-03 19:13 -0700
          Re: What about code blocks (not Forth blocks)? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 05:35 +0000
            Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-11 12:59 +0100
              Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-11 23:44 -0700
                Re: What about code blocks (not Forth blocks)? Julian Fondren <ayrnieu@gmail.com> - 2014-03-12 11:48 -0700
                  Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-12 20:21 +0100
                    Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-12 23:35 -0700
                      Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-14 14:25 +0000
                        Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-14 16:36 +0100
                          Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2014-03-14 11:27 -0700
                          Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-16 17:38 -0700
                            Re: What about code blocks (not Forth blocks)? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-17 03:35 -0400
                          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-17 20:36 -0700
                            Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-18 13:13 +0000
                              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-18 14:28 +0000
                              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-18 10:10 -0700
                              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-25 12:54 -0700
                                Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-25 23:09 -0700
                                Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-26 13:49 +0000
                                  Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-26 22:07 +0100
                            Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-20 22:11 -0700
                          Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-28 22:18 -0700
                            Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-29 10:57 +0000
                    Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-13 16:42 +0000
            Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-11 12:51 +0000
              Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-11 14:54 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 21:36 -0800
        Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 16:56 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 23:24 -0800
        Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-20 02:05 -0800
        Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 12:41 +0000
          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 17:46 +0000
            Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-21 08:11 -0800
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-23 10:07 +0000
                Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-23 19:31 +0100
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-26 17:45 +0000

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

#27376

on 20/12/2013 05:49:03, Aguilar the Amnesiac wrote:
[snip]
> 
> Bernd Payson kicked me off the Forth-200x mailing list for saying
> this. 

No, you posted offensive nonsense on several occasions, you were asked to
stop posting offensive nonsense, and then you asked to be kicked off the
list. The moderator (not Bernd) obliged you.

How quickly you've forgotten.

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

#29278

On Friday, December 20, 2013 1:56:12 AM UTC-7, Alex McDonald wrote:
> on 20/12/2013 05:49:03, Aguilar the Amnesiac wrote:
> [snip]
> 
> > Bernd Payson kicked me off the Forth-200x mailing list for saying
> > this. 
> 
> No, you posted offensive nonsense on several occasions, you were asked to
> stop posting offensive nonsense, and then you asked to be kicked off the
> list. The moderator (not Bernd) obliged you.
> 
> How quickly you've forgotten.

I tried responding to this post at the time that it was written, but my response got censured by Google Groups for "group abuse." I'll try again though, as all of that censoring seems to have stopped now:

Actually, I don't need to memorize this stuff, as I have saved all of my emails. This is what Elizabeth Rather said:

Hugh has been hanging around c.l.f for several years, now. He originally got mad at FORTH, Inc. because we insisted on charging for an upgrade to SwiftForth 3.0 for people who had bought 2.x > a year earlier. He has had one programming job, paying $10/hr, on which he wrote a cross-compiler for a microcontroller for a project. He was fired at the end of the project, and has since been working as a taxicab driver. He is actively homophobic, and developed his hatred for me when I called him on a particularly vitriolic attack on a c.l.f poster who dared to mention his partner. Pretty much everyone on c.l.f has his number.

Hope you are doing well. Ned and i are enjoying life in Hawaii, and hope you are, too!

Aloha,
Elizabeth


And this was my response:

You're lying. For one thing, I have worked at several programming jobs. You know this, because I have mentioned the C/C++ and the IBM370 assembly-language jobs on comp.lang.forth. Also, I wasn't fired from Testra after writing MFX (the cross-compiler for the MIniForth). I did another large project for them later on. After that I quit because I wasn't getting a raise and because I wasn't getting health benefits even though the other employee was --- basically, because it was a dead-end job. I've worked as a machinist since then --- cab-driving is just something that I do when I'm unemployed --- right now I working in construction.

How would you know anything about Testra business decisions? They don't like you either, and aren't talking to you. One time I asked John Hart why he was using UR/Forth rather than SwiftForth, and he said that he can't stand you personally, but he got along with Ray Duncan okay. I didn't know you at the time. This was fine with me though, as I had disassembled the heck out of UR/Forth on my own time prior to getting hired, and so I already had a leg up on the job. After I left Testra I bought a copy of SwiftForth on my own, and I found that it was slow, buggy and generally no good (I've seen shareware Forths that were better) --- I wouldn't have been able to write MFX using SwiftForth, although I had succeeded with UR/Forth.

When I worked at Testra I was told that you had previously given them a sales pitch for Forth Inc. to write the cross-compiler. You wanted an "exorbitant" amount of money though, and you obviously didn't know anything about the subject on a technical level, which is why I got hired instead. I think that you hate me because I stole the job from you. There are only a tiny handful of companies in the world who are building a Forth-engine and are willing to pay for its development (because it is going to be used in a commercial product, rather than just be a hobbyist toy). You felt that Forth Inc. deserved the job, and that I stole it from you. 

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

#29007

hughaguilar96@yahoo.com wrote:

> I said that, to be useful, the quotation needs to have access
> to the creator function's local variables. The idea is that
> you have a word (like EACH in my novice package) that
> traverses a data-structure. It is given the xt of a quotation,
> and it EXECUTEs this xt for every node in the data-structure,
> giving the quotation that node's address as a parameter. The
> quotation needs to have access to the creator function's local
> variables so that it can communicate back information that it
> obtains from the data-structure nodes.
> 
> Bernd Payson kicked me off the Forth-200x mailing list for saying this.

Tyranny.

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

#29009

WJ wrote:
>> Bernd Payson kicked me off the Forth-200x mailing list for saying this.
> 
> Tyranny.

I didn't kick him out.  He got kicked out himself because he deliberately 
asked for it, saying we had no spine if we wouldn't kick him out for all the 
damage, abuse, insults, and name-calling he did.  We discussed that, and of 
course knew he would blame us (especially me) to have kicked him out, but 
since several people already had left the group, because they couldn't stand 
his diatribes, we decided to grant his wish, in agreement.  We call that 
democracy; tyranny is when some lone psycho rules (and Hugh certainly is a 
psycho).  The owner of the list then did the actual kicking.  We didn't even 
know why he was on the list, because he long ago said he haited all of us 
and he had given up on the Forth 200x effort, and he wanted to do his own 
"standard" instead.  However, he's a complete non-achiever, so he rather 
damages the achievements of others than doing something himself.  He's quite 
good at damaging.

Because he's obviously misprepresenting my argument, I repeat it here:

Forth is a stack-based language.  The way to pass and return parameters to a 
function is the stack.  The way to pass and return parameters from a 
quotation therefore also is the stack.  The downside of this is that the 
higher-order function has to move its own state either onto the return stack 
or into local variables.

Example: We have TRAVERSE-WORDLIST as higher order function to traverse a 
wordlist.  So you can define WORD-COUNT as follows:

: word-count ( wid -- )
  0 [: ( n nt -- n+1 ) drop 1+ ;] rot traverse-wordlist ;

This is the Forth way do to it: You dodge the accidential complexity induced 
by people who can't keep things simple.  I know how to create nested 
functions (that's the actual terminology of what Hugh wants), they require 
creating a trampoline or similar structure.  I know how to create closures, 
they require a trampoline-object on the heap (and probably garbage 
collection to get rid of those objects).  This is all doable, but it 
needlessly increases complexity, because the right way to pass parameters 
and return them in Forth is *on the stack*.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#29018

On Tuesday, March 11, 2014 4:59:27 AM UTC-7, Bernd Paysan wrote:
> WJ wrote:
> >> Bernd Payson kicked me off the Forth-200x mailing list for saying this.
> 
> > Tyranny.
> 
> I didn't kick him out.  He got kicked out himself because he deliberately 
> asked for it, saying we had no spine if we wouldn't kick him out for all the 
> damage, abuse, insults, and name-calling he did.  

Your "quotations" were really the last straw for me. You were totally faking it! If you don't know how to implement quotations (and you obviously don't), then just admit that you don't know how and don't implement anything. It was grossly dishonest of you to put some syntactic sugar around :NONAME and claim that you have implemented quotations. I DO NOT ASSOCIATE WITH SUCH DISHONEST PEOPLE AS YOURSELF! Your attitude seems to be that faking it is okay, because Forthers are all losers anyway, and your sycophants (Bezemeer, for example) will continue to suck up to you, so everything is cool. It is not cool though --- you are a phony!

> We discussed that, and of 
> course knew he would blame us (especially me) to have kicked him out, but 
> since several people already had left the group, because they couldn't stand 
> his diatribes, we decided to grant his wish, in agreement.  

Most likely those people left the group because they knew that you were faking your quotations. There are a lot of people in the world who have a basic knowledge of computer science, which is all that it takes to see through your fakery.

> We call that 
> democracy; tyranny is when some lone psycho rules (and Hugh certainly is a 
> psycho).  The owner of the list then did the actual kicking.  We didn't even 
> know why he was on the list, because he long ago said he haited all of us 
> and he had given up on the Forth 200x effort, and he wanted to do his own 
> "standard" instead.  However, he's a complete non-achiever, so he rather 
> damages the achievements of others than doing something himself.  He's quite 
> good at damaging.

I'm not damaging your "achievement" in implementing quotations, because you didn't implement quotations. :NONAME has been in ANS-Forth since 1994, and I recall that there was something similar in Forth-83. All you did was put some syntactic sugar around :NONAME --- that is not an achievement --- that is black mark on Forthers everywhere.

> Because he's obviously misprepresenting my argument, I repeat it here:
> Forth is a stack-based language.  The way to pass and return parameters to a 
> function is the stack.  The way to pass and return parameters from a 
> quotation therefore also is the stack.  The downside of this is that the 
> higher-order function has to move its own state either onto the return stack 
> or into local variables.

Yep, that is the downside! You are dumping all of the complexity onto the application programmer --- forcing him to write his higher-order function in a grossly contorted manner --- rather than have the language internalize the complexity by implementing quotations correctly.

> Example: We have TRAVERSE-WORDLIST as higher order function to traverse a 
> wordlist.  So you can define WORD-COUNT as follows:
> 
> : word-count ( wid -- )
>   0 [: ( n nt -- n+1 ) drop 1+ ;] rot traverse-wordlist ;
> 
> This is the Forth way do to it: You dodge the accidential complexity induced 
> by people who can't keep things simple.  

Since when are you the god of Forth, who decides what the "Forth way" is? 

You are not dodging any complexity. You are dumping all of the complexity on to the application programmer in that he has to figure out a way for his quotation to communicate with the creator function --- either a contorted writing of the higher-order function as described above, or global variables --- this is so that YOU can dodge the effort of figuring out how to implement quotations correctly.

You example was fake. You showed an example in which the higher-order function TRAVERSE-WORDLIST was not written by the application programmer but was part of Forth-200x (and you didn't show its source-code, which is where the complexity is). There are only a tiny handful of these though --- most of the time, the application programmer will be the one implementing the higher-order function. This has to be done every time that a data structure is implemented (linked list, LLRB tree, etc.).

> I know how to create nested 
> functions (that's the actual terminology of what Hugh wants), they require 
> creating a trampoline or similar structure.  

No you don't! I have never seen any evidence to support your contention that you know how to implement this stuff.

I've got it figured out. Also, on the Forth-200x mailing list I said that I didn't know how to implement nested quotations, but I have since figured that out too (figuring out complex code like this doesn't happen overnight, as I rely on the solutions to just come to me by and by). I can have nested quotations all of which will have access to the creator function's local variables. I do need to dedicate an extra register, but modern processors have plenty of registers so this is not a problem. The quotation should run at the same speed as colon functions or just negligibly slower --- I haven't tested the speed yet as I need more of my language working before I can have a meaningful test.

I'm not going to tell you how to implement quotations.

I don't know what a "trampoline" is, as I've never heard that term. The books that I have read on compiler writing call it a "display table." I don't really care about terminology anyway, because I understand computers in my head without words.

> I know how to create closures, 
> they require a trampoline-object on the heap (and probably garbage 
> collection to get rid of those objects).  This is all doable, but it 
> needlessly increases complexity, because the right way to pass parameters 
> and return them in Forth is *on the stack*.

This is a staw-man argument --- I have never asked for Forth-200x to have closures. They can out-live the creator function because the creator function's locals are in the heap rather than on the stack, but this is a solution to a non-problem, as there is no real purpose in having them out-live the creator function --- and it results in a grossly inefficient implementation (this gross inefficiency being a big part of why Scheme/Lisp aren't used in the real world), and it requires GC (which I think is a bad fit for Forth).

> Bernd Paysan
> "If you want it done right, you have to do it yourself"

This quote that you put on the end of your posts is the most ironic thing about you --- you are totally faking it with your :NONAME quotations.

You should have asked me to implement quotations a long time ago, and then Forth-200x would have acquired real quotations without any ado --- but you were too busy calling me a "psycho" and "stupid" and so forth, so you missed that opportunity. You just want to be a big chief, and you can't stand the idea that anybody else in the Forth community might know anything whatsoever --- you call me these vulgar names because you can't bring yourself to call me or anybody else a peer (except Elizabeth Rather, or course, as you need her permission to continue to be a big chief on the Forth-200x committee).

P.S. for WJ: You have never written a Forth program in your life and you know nothing about the subject. I don't need your support --- stop claiming that my arguments against Forth-200x prove your point that Ruby is the best language --- piss off!

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

#29031

On Wednesday, March 12, 2014 1:44:59 AM UTC-5, hughag...@yahoo.com wrote:
> It was grossly dishonest of you to put some syntactic sugar
> around :NONAME and claim that you have implemented quotations.

[: ." <-- :NONAME" ;] execute

: however ( -- )
  [: ." <-- obviously not :NONAME" ;] execute ;

What you are probably groping at is that [: doesn't create
closures, so it can't be used as analogues in other languages are
often used [when they are used in textbooks].  So if your goal is
to make Paul Graham's Accumulator Generator, or to recreate
SICP's banking example, then [: does very little for you.

But in Forth, you know, we have already vocabularies, ways to
behead words, 'linear scoping', CREATE..DOES> , object systems...

So this:

(let ((balance 0))
  (defun deposit (n) (incf balance n))
  (defun withdraw (n) (decf balance n))
  (defun balance () balance))

Works just fine in Forth as:

variable balance
: deposit ( u -- )  balance +! ;
: withdraw ( u -- )  negate balance +! ;
: balance ( -- u )  balance @ ;

And if you want multiple accounts, or if you want an account-creator,
then you can do the same thing Lisp does in the real world: use some
kind of object system.  You really, really don't need to do this:

\ SICP's make-account with hypothetical Hugh-approved [:

create 'withdraw
create 'deposit

: make-account { balance -- dispatcher }
  [: ( n -- balance )
    balance +  to balance  balance ;]  { withdraw }
  [: ( n -- balance )
     balance over >= if
       balance swap -  to balance  balance exit
     then true abort" Insufficient funds" ;]  { deposit }
  [: ( n a -- )
     dup 'withdraw = if drop withdraw execute exit then
     'deposit = if deposit execute exit then
     true abort" Unknown request - MAKE-ACCOUNT" ;] ;

10000 make-account constant Bob
500 'withdraw Bob execute .  \ outputs: 9500

UserRPL, Joy, Factor, Retro, and blah don't have their analogues
of [: out of a desperate need to close over variables.
(UserRPL's 'code blocks' also didn't close over variables.)
Maybe studying any of these langauges will help you understand
what some benefits of [: might be.  

Although I feel as if you've already been given a perfectly good
example of a non-closure use of [: in Forth, which wouldn't benefit at
all from the ability to close over variables.

Anonymous subroutines in Perl can also close over variables.  You
know how they're used 99% of the time in Perl?  They're used to
pass code to grep and map, and the only variables involved are
for data that would be more naturally passed on the stack in Forth.

So in summary,

> This is a staw-man argument --- I have never asked for Forth-200x
> to have closures. They can out-live the creator function because
> the creator function's locals are in the heap rather than on the
> stack, but this is a solution to a non-problem, as there is no
> real purpose in having them out-live the creator function

... oh?  Are you... are you sure?  You're super angry and you
babbled something about computer science, so I just assumed that
you were super angry about something more substantial :-/ 

OK.

New guess at to what Hugh's problem even is:

If I want to pass arguments to a quotation, or maintain state on
the stack, then my higher-order word has to manage this.  If I
take the really obvious route and have all higher-worder words
keep the data stack clean, then this is also more work for my
higher-order words.  It strikes me that local variables would
make things much easier.

For example,

\ boring, no problems here:
: example1 ( -- )
  s" hello" [: cr emit ;] each-char ;

\ this burdens EACH-CHAR with keeping the data stack clean,
\ when it would otherwise likely keep at least the XT on
\ the stack.
: example2 ( -- )
  0 s" hello" [: cr emit 1+ ;] each-char
  cr ." Number of chars: " . ;

\ Hugh's ideal version.  EACH-CHAR doesn't have to do any
\ extra work to keep the stack clear for the quotation, and
\ the quotation also doesn't have to dig past the arguments
\ provided by EACH-CHAR to reach EXAMPLE3's stack:
: example3 ( -- )
  0 { c }  s" hello" [: cr emit  1 +to c ;] each-char
  cr ." Number of chars: " c . ;

That last version doesn't work.  The point of all of the
accusations of "gross dishonesty" and fraudulence and tyranny is
that EXAMPLE3 doesn't work.  Instead of using local variables in
EXAMPLE3, you have to use them (or the return stack) in
EACH-CHAR.  Which is a terrible burden on EACH-CHAR even though
it's exactly what's desired for EXAMPLE3


-- Julian

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

#29033

Julian Fondren wrote:

> If I want to pass arguments to a quotation, or maintain state on
> the stack, then my higher-order word has to manage this.  If I
> take the really obvious route and have all higher-worder words
> keep the data stack clean, then this is also more work for my
> higher-order words.  It strikes me that local variables would
> make things much easier.
> 
> For example,
> 
> \ boring, no problems here:
> : example1 ( -- )
> s" hello" [: cr emit ;] each-char ;
> 
> \ this burdens EACH-CHAR with keeping the data stack clean,
> \ when it would otherwise likely keep at least the XT on
> \ the stack.
> : example2 ( -- )
> 0 s" hello" [: cr emit 1+ ;] each-char
> cr ." Number of chars: " . ;
> 
> \ Hugh's ideal version.  EACH-CHAR doesn't have to do any
> \ extra work to keep the stack clear for the quotation, and
> \ the quotation also doesn't have to dig past the arguments
> \ provided by EACH-CHAR to reach EXAMPLE3's stack:
> : example3 ( -- )
> 0 { c }  s" hello" [: cr emit  1 +to c ;] each-char
> cr ." Number of chars: " c . ;

Thanks for actually formulating it out.  Yes, that's Hugh's problem (ok, the 
real problem of Hugh is something else... ;-).  And yes, you can see that 
using locals for this stuff makes it more ugly, even though you use +TO for 
incrementing c.  This stuff is not natural to Forth, nested functions are 
Algol-style.

: each-char ( .. addr u xt -- .. ) \ xt: ( .. char -- .. )
  { xt } bounds DO  I c@ xt execute  LOOP ;

can use a local variable without being ugly; here, there's actually a 
benefit from the local variable, because the return stack version looks 
ugly:

: each-char ( .. addr u xt -- .. ) \ xt: ( .. char -- .. )
  -rot bounds DO  i c@ swap dup >r execute r>  LOOP  drop ;

I've written several higher-order words, and always used local variables to 
keep the stack empty.  This is easy to do, and therefore the right way, 
because Forth's philosophy is "keep it simple".

In any case: quotations are not yet part of Forth200x, because nobody made 
an RfD.  They are a de-facto standard, as several Forth systems already 
implement them or have free (and pretty simple) implementations ready.  
Their usefulness is still somewhat debated.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#29034

On Wednesday, March 12, 2014 12:21:57 PM UTC-7, Bernd Paysan wrote:
> I've written several higher-order words, and always used local variables to 
> keep the stack empty.  This is easy to do, and therefore the right way, 
> because Forth's philosophy is "keep it simple".

You are dumping all of the complexity onto the application programmer. This is complexity that should be internalized into the language. The "keep it simple" philosophy is supposed to be for the application programmer, not the compiler-writer --- dumb-head!

Also, the higher-order function is iterative, so writing it in a contorted manner (using local variables or the return-stack to hold internal data) results in inefficient code.

Linked lists are one of the simplest data structures in existence. Here is FFL's complicated and inefficient code for traversing a linked list:

: snl-execute      ( i*x xt snl -- j*x )
  snl-first@       \ walk = first
  BEGIN
    nil<>?         \ while walk<>nil do
  WHILE
    2>r
    2r@ swap execute  \ execute xt with node
    2r>
    snn-next@      \  walk = walk->next
  REPEAT
  drop
;

Here is my version in the novice package:

: each ( i*x head 'toucher -- j*x )   
\ toucher: i*x node -- j*x
    >r
    begin  dup while
        r@  over .fore @ >r
        execute  r> repeat drop
    rdrop ;

There is some history here. FFL originally didn't hold its internal state on the return-stack, but simply held it on the data-stack. I pointed out that this prevents the data-stack from being used for communication between the quotation (what I call a "toucher" in the novice package) and the function that is calling EACH (EACH is called SNL-EXECUTE in FFL). Also at that same time, somebody here on comp.lang.forth pointed out that my EACH was inefficient because it used 2>R 2R@ and 2R> at every iteration. This was a valid criticism, so I upgraded my EACH to use >R R@ and R> and an OVER, which is more efficient. Now I see that FFL has been upgraded to hold its internal data on the return-stack. Humorously however, FFL has used my original inefficient code rather than my upgraded more efficient code. This points out that writing higher-order functions such as EACH is overly complicated. I didn't initially figure out how to do this efficiently and it was only my second attempt that was efficient, and the FFL geniuses never figured out how to do this efficiently. As for Bernd's suggestion to use local variables in EACH, that is so grossly inefficient (especially on SwiftForth) that I never even considered doing that. In my slide-rule program, for example, I have dozens of uses of EACH on lists containing up to 15,000 nodes, so efficiency is an issue --- I can about double the speed of the program under SwiftForth just by using the assembly-language version of EACH rather than the version shown above that is written in high-level Forth.

The above example was for EACH for singly-linked lists, which is a pretty simple example. FIND-NODE is more complicated:

: find-node ( i*x head 'toucher -- j*x node|false )             
\ toucher: i*x node -- j*x flag
    >r
    begin  dup while
        r@  over .fore @ >r  over >r
        execute if  r>  2rdrop  exit then
        rdrop  r> repeat
    rdrop ;

Singly-linked lists are the most basic data-structure of all. These higher-order functions get more complicated that this, with more advanced data-structures such as binary trees.

I think that most Forth application programmers are never going to figure out how to write these higher-order functions due to the complexity level. If they do figure out how to write them, the code is going to be inefficient because it is holding its internal data on the return-stack or in locals, whereas Forth functions normally hold their data on the data-stack. Bernd is making Forth-200x application-programming way more complex and inefficient than it needs to be --- all because he is incapable of figuring out how to implement quotations that have access to the creator function's local variables.

Bernd's "quotations" (which are just some syntactic sugar for :NONAME) are totally fake. It is as if he painted a brick gold and claimed he had a gold bar from Fort Knox. So I come along and scrape the paint off with my pocket knife, revealing his gold bar to be a brick --- then he complains that I have "damaged his achievement," and accuses me of being a "psycho." Bernd is just dishonest and incompetent --- I don't want to have anything to do with Forth-200x, because I refuse to accept him as a leader, primarily because of his fake quotation implementation.

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

#29040

on 13/03/2014 06:35:42, hughaguilar wrote:
[snip]
> 
> Here is my version in the novice package:
> 
>: each ( i*x head 'toucher -- j*x )
> \ toucher: i*x node -- j*x
> >r
> begin  dup while
> r@  over .fore @ >r
> execute  r> repeat drop
> rdrop ;
> 
> There is some history here. FFL originally didn't hold its internal
> state o n the return-stack, but simply held it on the data-stack. I
> pointed out tha t this prevents the data-stack from being used for
> communication between th e quotation (what I call a "toucher" in the
> novice package) and the functio n that is calling EACH (EACH is called
> SNL-EXECUTE in FFL). Also at that sa me time, somebody here on

That someone was me. 


https://groups.google.com/forum/#!original/comp.lang.forth/kH8lPSKdW30/_NzkfGsgnbkJ

> comp.lang.forth pointed out that my EACH was inef ficient because it
> used 2>R 2R@ and 2R> at every iteration. This was a vali d criticism,
> so I upgraded my EACH to use >R R@ and R> and an OVER, which i s more
> efficient. Now I see that FFL has been upgraded to hold its internal
> data on the return-stack. Humorously however, FFL has used my original
> ine fficient code rather than my upgraded more efficient code. This
> points out that writing higher-order functions such as EACH is overly
> complicated. I d idn't initially figure out how to do this efficiently
> and it was only my se cond attempt that was efficient, and the FFL

It was my code you used. Still, that's fine; it was offered and you
accepted.

> geniuses never figured out how to do this efficiently. As for Bernd's
> suggestion to use local variables i n EACH, that is so grossly
> inefficient (especially on SwiftForth) that I ne ver even considered
> doing that. In my slide-rule program, for example, I ha ve dozens of

And then you slide downhill into name calling and generally being an
asshole. Why?

[mucho snipped]

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

#29041

Alex McDonald wrote:

>> geniuses never figured out how to do this efficiently. As for Bernd's
>> suggestion to use local variables i n EACH, that is so grossly
>> inefficient (especially on SwiftForth) that I ne ver even considered
>> doing that. In my slide-rule program, for example, I ha ve dozens of
> 
> And then you slide downhill into name calling and generally being an
> asshole. Why?

That's Hugh.  That's why he is in my killfile.  However, as usual, his 
argument is also insane from a technical point of view.  He suggests using a 
nested function which accesses locals through a displacement pointer and 
which gets called through a trampoline, which is for sure more inefficient 
than having a normal local in the higher order function.

In Gforth, read-accessing one of the top four locals is as efficient as DUP 
or OVER.  This is nothing you should be worried about.  I did some 
benchmarks with this string mapping function, and the results for counting a 
string with 100 million characters on my 3 GHz Core i7 is (gforth-fast):

: smap1 { xt } bounds ?do i c@ xt execute loop ;           
: smap2 -rot bounds ?do i c@ swap dup >r execute r> loop drop ;

smap1: 0.609232534s
smap2: 0.669535732s

I conclude that in a case like this you should use locals in such a case.  
It makes your program more readable, less error-prone (can't forget the drop 
after the loop!) and at the same time faster.

For what's it's worth, git Gforth's mini-oof2.fs has a building block 
(callables) which can be used to build objects which are callable as xts.  
This allows the functional equivalent of a real closure.  Let's do it and 
create a counter closure instead of counting on the stack.  The call 
overhead is similar to a trampoline.  Of course, this is just a building 
block, so there is no nice syntax for it.  You have to derive the class 
callable, and add your fields.

require callable.fs                                       
callable class  field: cnt  end-class counter
counter new constant cnt1
[: drop 1 cnt +! ;] cnt1 callable!

smap1: 1.211342292s

So we come to the conclusion that Hugh dismissed an implementation choice 
that would give him a 10% performance gain and he rather pursues an 
implementation choice that will give him a two-fold slowdown.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#29043

On Friday, March 14, 2014 4:36:08 PM UTC+1, Bernd Paysan wrote:
> Alex McDonald wrote:
[..]
> I conclude that in a case like this you should use locals in such a case.  
> It makes your program more readable, less error-prone (can't forget the drop 
> after the loop!) and at the same time faster.
[..]


The inefficiency is not in the local, it is in the DO LOOP.

-marcel
------------------------------------------------------------
ANEW -smap

#100000000 =: /size
[UNDEFINED] addr [IF] /size allocate ?allocate =: addr [THEN]
VARIABLE cnt

: smap1 LOCALS| xt | bounds ?do i c@ xt execute loop ;           
: smap2  -rot bounds ?do i c@ swap dup >r execute r> loop drop ;
: smap3    >S bounds ?do i c@ S execute  loop -S ;
: smap4    >S bounds ?do i c@ S execute  i 1+  c@ S execute  i 2+  c@ S execute  i 3 + c@ S execute 4 +loop -S ;

:NONAME ( char -- ) drop 1 cnt +! ; =: xt1

: TEST ( -- )
	cnt OFF	CR ." \ smap1: " TIMER-RESET  addr /size xt1 smap1 .ELAPSED  space cnt ? 
	cnt OFF	CR ." \ smap2: " TIMER-RESET  addr /size xt1 smap2 .ELAPSED  space cnt ? 
	cnt OFF	CR ." \ smap3: " TIMER-RESET  addr /size xt1 smap3 .ELAPSED  space cnt ? 
	cnt OFF	CR ." \ smap4: " TIMER-RESET  addr /size xt1 smap4 .ELAPSED  space cnt ? ;

\ 3 GHz Core i7 is (gforth-fast)
\ smap1: 0.609232534s
\ smap2: 0.669535732s

\ 2.66 GHz Core i7 iForth 5.0
\ smap1: 0.458 seconds elapsed. 100000000
\ smap2: 0.345 seconds elapsed. 100000000
\ smap3: 0.377 seconds elapsed. 100000000
\ smap4: 0.267 seconds elapsed. 100000000  ok

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

#29052

On Wednesday, March 12, 2014 12:21:57 PM UTC-7, Bernd Paysan wrote:
> And yes, you can see that 
> using locals for this stuff makes it more ugly, even though you use +TO for 
> incrementing c.  This stuff is not natural to Forth, nested functions are 
> Algol-style.
> ...
> I've written several higher-order words, and always used local variables to 
> keep the stack empty.  This is easy to do, and therefore the right way, 
> because Forth's philosophy is "keep it simple".

Does anybody else notice the lack of self-consistency in Bernd's argument? On one hand, he disparages my idea of quotations having access to the creator function's local variables as being "Algol-like" because of my reliance on the creator function having local variables that the quotation communicates through. On the other hand though, his idea is that the higher-order function that is calling the quotation (such as my EACH that traverses a linked list) should use local variables, which is grossly Algol-like.

The higher-order function (such as EACH) has to be written in a contorted inefficient manner so that it can allow the quotation to communicate with the creator function on the data-stack. Most of the time however, the quotation doesn't need to communicate with the creator function at all! For example, in my slide-rule program that used EACH so much, I never had the quotation (called a "toucher" in the novice package) communicate upwards at all. Just off-hand, I would say that such communication is needed maybe 10% of the time (this will vary a lot with the kind of program being written, but I doubt that it would be over 50% for anybody). With Bernd's scheme (or my scheme as currently implemented in the novice package), the inefficiency bites the programmer 100% of the time. If quotations are implemented correctly, so that they have access to the creator function's local variables, there is no requirement that the application programmer use local variables at all --- except in the minority of cases in which some communication is necessary. Also, most of the time, there is only one local variables --- by comparison, even the simplest higher-order function will have several local variables (EACH has 2 items on the return-stack, or it could be written with 2 local variables). Also, as I have said before, the higher-order function is iterative, so the inefficiency of it using local variables or the return-stack is multiplied hundreds or thousands of times compared to the creator function above it that is not iterative (and the creator function only needs locals maybe 10% of the time, as discussed earlier) --- as a general rule-of-thumb, using the data stack in Forth is much more efficient than using local variables (more concise too), so long as you have fewer than 4 parameters in use and hence can avoid doing excessive stack-juggling.

Bernd should really stop calling my stuff "nested functions." Mine are anonymous, similar to Factor's quotations --- they don't have names like in Algol or the early Pascal implementations, which does result in somewhat bloated source-code. 

> Their usefulness is still somewhat debated.

The only thing that is debatable is the usefulness of your hokey "quotations" that are just syntactic sugar for :NONAME --- most Forthers (including myself) rarely or never use :NONAME and consider it to be marginally useful at best. I didn't use :NONAME anywhere in the novice package, to the best of my recollection.

On the other hand, lots of languages use quotations or closures as their primary feature, and they are considered hugely useful. A lot of programmers have largely chilled out on OOP which was the silver-bullet of the 1990s, but they have found quotations or closures to be much more useful --- I'm in this category.

I liked Factor's quotations, but largely dropped Factor because I didn't like its dynamic-OOP --- so I am now focused on introducing quotations into Forth, but continuing to ignore OOP.

On the subject of Factor, it uses quotations for control-structures. I considered doing that in my own language too. I decided to stick with traditional Forth control-structures however, because I don't want to get too far away from good-old Forth (and I don't want to give Rod ammo for saying that my language isn't Forth anymore). Also, I couldn't figure out how to make quotation-based control-structures as efficient as traditional-Forth control-structures. Slava is generating machine-code, whereas I am generating ITC --- my system is easier to implement, but it is also more difficult to improve with optimization --- if I were to generate machine-code I would have more options available to me in regard to optimization, but that would also entail more work than I'm willing to invest. Factor also uses quotations instead of stack-juggling words (with DIP and all that), but I never considered doing that in my language as I thought that made Factor ugly compared to traditional Forth.

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

#29056

On Sun, 16 Mar 2014 20:38:35 -0400, <hughaguilar96@yahoo.com> wrote:

> Does anybody else notice the lack of self-consistency in Bernd's  
> argument?

Notice?  What Bernd says?  No...  Well, not that I'd admit to, anyway.

Of course, I have to ask if it was worth my time to read it.
Was it?  You're commenting on it, as if it was...

> On one hand, he disparages my idea of quotations [...]
> On the other hand, lots of languages use quotations or closures
> as their primary feature, [...]

It's a mutually exclusive argument.  He preemptively attempted to
exclude any and all possibilities that would allow for a viable
solution being posted by you.

> [Hugh apparently thinking we really care about his quotations?]
>

Hugh, ignore Bernd.  Do want you want.  Do what you think is best.
Do what you think works best.  Etc.

> Bernd should really stop calling my stuff "nested functions."

Why?  Why do you _care_ what *he* calls *your* stuff? ...  Everyone
else around here seems to be a non-caring sociopath.

> Mine are anonymous, [...]

Yeah!  What ... ?  Why?  Seriously, I've asked the same thing about
C's new anonymous objects.  The answer to that question seems to be
infinite silence.  Once the code is compiled, it's all anonymous.

> On the other hand, lots of languages use quotations or closures as
> their primary feature, and they are considered hugely useful.

The primary feature of many other languages are procedures or functions.
Although that's more noticeable in languages like C and Pascal, Forth
and even BASIC are in that category.  The point being:

Why do you need two primary methods of grouping and sequencing code
for execution?  Isn't one method sufficient?  I'm saying that octagonal
wheels might have some benefit when they're new, especially in the winter
or with off-road driving in mud, but over time, they'll naturally wear
into round ones which roll a bit easier...

> A lot of programmers have largely chilled out on OOP which was the
> silver-bullet of the 1990s, [...]

I didn't really see the point of OOP in regards to C++.  Yes, there
are some nice features, e.g., object.action syntax.  That can be
emulated in C with a struct and a loop.  But, for the most part all
OOP seemed to do was hide the code that would be eventually be
executed and make it difficult to determine which code would actually
be executed.  What purpose does that serve?  Have you ever tried to
track down a #define or where a global variable is initialize within
millions of lines of code?  I have: 5Mloc...  At best, OOP allows one to
"overload" the parameters to functions.  That's convenient, occasionally.
But, just how do you know which types are *disallowed* as parameters
when many multiple types of parameters are allowed to be passed to that
procedure because it's overloaded?  Do you have to look up that functions'
numerous parameter declarations?  PIA, if so...  Are these all in one
place or distributed all over the place?  More PIA, if so...  Do you have
to compile the code to find out?  That's bad language design, if so...

> [...] found quotations or closures to be much more useful --- I'm in
> this category.

Some people like GOTO's too...  Others like programming in hexadecimal.
A bunch of people around here prefer RPN, or so I've heard.

> On the subject of Factor, it uses quotations for control-structures.
> I considered doing that in my own language too.

It's your language.  Do what you want.  Are you asking for input from
others on your language design?  Forth is for those asking about Forth.
Try comp.lang.misc or comp.compilers.

> I decided to stick with traditional Forth control-structures however,
> because I don't want to get too far away from good-old Forth [...].

Why?  Aren't you afraid you might forgo or overlook some important
discovery by doing so?  Why are you forcing yourself to be constrained
to the conventional models you apparently hate?

> (and I don't want to give Rod ammo for saying that my language isn't
> Forth anymore).

If it's your language, just for you, why does it matter if it's Forth?
Is it because you desire that Forthers to adopt your language?  If the
result of adding quotations to Forth is novel, don't you want to be
known for creating a new, better language than Forth, say 1DUPF++ ,
instead of just being known for "fixing" Forth? ...

FYI, 1DUPF++ is a take on C++ but for Forth where 'F' represent Forth:
   1 DUP F + +

> Also, I couldn't figure out how to make quotation-based
> control-structures as efficient as traditional-Forth control-structures.

That's a bad start.  Work on it.  You might develop a new, better,
faster, leaner, quotation model that works with procedural languages.

> [...] whereas I am generating ITC [...]

Forth is primarily procedure or function based.  Each high-level Forth
word is a procedure or function.  ENTER or DOCOL is the procedure's call.
EXIT or SEMIS is the procedure's exit.  The interpreted implementations
of the Forth language is well designed for procedures but not so well
for branching.  This is why BRANCH and 0BRANCH or ?BRANCH are awkward
to implement within an ITC Forth.  Technically, Forth is 0-operand, i.e.,
it has no parameters.  In reality, that just means it's parameters are on
a stack, not formally passed, and not setup and cleaned up by the language.


Rod Pemberton

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

#29059

Bernd Paysan <bernd.paysan@gmx.de> writes:
> He suggests using a nested function which accesses locals through a
> displacement pointer and which gets called through a trampoline, which
> is for sure more inefficient than having a normal local in the higher
> order function.

In Lisp there are other ways to handle this including:

1) "Lambda lifting": the inner function is syntactically converted to a
top-level function that takes some extra parameters to get the values of
the locals of outer functions that it references.  These parameters are
added to the calls the inner function's call sites.  A later
optimization pass can in some cases get rid of them for efficiency.

2) "Shallow binding" in old-fashioned dynamically scoped Lisps
(including Emacs Lisp til recently).  Basically each name has a static
dictionary entry with a cell containing its current value.  If you
re-bind the symbol at a nested level, the old value (and the address of
the value cell) get pushed on a control stack.  When the scope exits,
those stack entries are unwound so the old value is restored.

The latter is quite efficient and easy to implement, and was used in
lots of significant Lisp systems, though it gave way to lexical scope as
it was deemed to get confusing as programs got larger.  It might be ok
for Forth which is focused more on small programs anyway.

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

#29060

Paul Rubin <no.email@nospam.invalid> writes:
>1) "Lambda lifting": the inner function is syntactically converted to a
>top-level function that takes some extra parameters to get the values of
>the locals of outer functions that it references.  These parameters are
>added to the calls the inner function's call sites.  A later
>optimization pass can in some cases get rid of them for efficiency.

That's similar to what we are doing by keeping the stuff on the stack.
We do it manually, though.

>2) "Shallow binding" in old-fashioned dynamically scoped Lisps
>(including Emacs Lisp til recently).  Basically each name has a static
>dictionary entry with a cell containing its current value.  If you
>re-bind the symbol at a nested level, the old value (and the address of
>the value cell) get pushed on a control stack.  When the scope exits,
>those stack entries are unwound so the old value is restored.
>
>The latter is quite efficient and easy to implement, and was used in
>lots of significant Lisp systems, though it gave way to lexical scope as
>it was deemed to get confusing as programs got larger.  It might be ok
>for Forth which is focused more on small programs anyway.

That can be done manually in Forth easily.

As for being ok: We have already had cases where the 90% solution led
to problems, e.g., STATE-smartness.  If the programmer chooses to go
there, ok, but then we don't need something that looks like local
variables: A programmer can easily get that effect by using global
variables.

So IMO for non-local access to local variables, if we choose to
support that, the way to go is lexical scoping.  It even won out in
Lisp, even though dynamic scoping was firmly entrenched there.

- 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 2013: http://www.euroforth.org/ef13/

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

#29062

In article <2014Mar18.141309@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>>1) "Lambda lifting": the inner function is syntactically converted to a
>>top-level function that takes some extra parameters to get the values of
>>the locals of outer functions that it references.  These parameters are
>>added to the calls the inner function's call sites.  A later
>>optimization pass can in some cases get rid of them for efficiency.
>
>That's similar to what we are doing by keeping the stuff on the stack.
>We do it manually, though.
>
>>2) "Shallow binding" in old-fashioned dynamically scoped Lisps
>>(including Emacs Lisp til recently).  Basically each name has a static
>>dictionary entry with a cell containing its current value.  If you
>>re-bind the symbol at a nested level, the old value (and the address of
>>the value cell) get pushed on a control stack.  When the scope exits,
>>those stack entries are unwound so the old value is restored.
>>
>>The latter is quite efficient and easy to implement, and was used in
>>lots of significant Lisp systems, though it gave way to lexical scope as
>>it was deemed to get confusing as programs got larger.  It might be ok
>>for Forth which is focused more on small programs anyway.
>
>That can be done manually in Forth easily.
>
>As for being ok: We have already had cases where the 90% solution led
>to problems, e.g., STATE-smartness.  If the programmer chooses to go
>there, ok, but then we don't need something that looks like local
>variables: A programmer can easily get that effect by using global
>variables.
>
>So IMO for non-local access to local variables, if we choose to
>support that, the way to go is lexical scoping.  It even won out in
>Lisp, even though dynamic scoping was firmly entrenched there.

I wonder if you could relate those scoping issues to the following:

I had in a recent Euler problem the need for memoizing and came up
with this:

1000 CONSTANT CSIZE
CSIZE BAG keys          CSIZE BAG values
\ The memoizer works on a one input one output function.
: memoize DUP keys BAG-WHERE DUP IF NIP keys - values + @
  RDROP ELSE  DROP DUP   CO   SWAP keys BAG+!
  DUP values BAG+! THEN ;

Basically BAG is an array that knows how far it is filled.
keys and values have a parallel structure.
RDROP is used for a premature exit of the calling function.
CO is a coroutine call : CO R> R> SWAP >R >R ;
Usage:
: f(x) ( n-- n ) memoize ... ;

So far so good.

Now I need a second memoizer and what I do is copy/paste and
rename (actually I didn't rename, just endure "Isn't UNIQUE"
messages )
.... keys1 .... values1 ...
: memoize2  ... keys1 ..values1 .. ;
and
: g(x) ( n -- n ) memoize1 ... ;

So is there a way to avoid the code duplication?
(My own brand of objects fails here. Of course memoization is
in the context of recursive calls. After CO most probably
the current object has changed and all it just fails. )

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

#29064

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>1) "Lambda lifting": the inner function is syntactically converted
> That's similar to what we are doing by keeping the stuff on the stack.
> We do it manually, though.

I'm not sure what you mean by that--do you mean in handwritten Forth?
I was writing about ways a Forth compiler could conceivably handle
nested functions with locals.

> If the programmer chooses to go there, ok, but then we don't need
> something that looks like local variables: A programmer can easily get
> that effect by using global variables.

Globals don't work in the case of recursive functions, and even without
recursion you have to either use a small set of names or alias them
somehow, to not burn extra storage cells since not all of them will be
live at the same time.  And then you have to be careful when refactoring
code, since you could have two functions using the same cell.  You
really want locals on a stack of some sort.

> So IMO for non-local access to local variables, if we choose to
> support that, the way to go is lexical scoping.  It even won out in
> Lisp, even though dynamic scoping was firmly entrenched there.

I have the impression it wasn't too terribly bad in Lisp.  It had a nice
feature that you could shadow system variables on purpose if you wanted.
E.g. to print a number in hexadecimal you could do the equivalent of

   : print-hex ( n -- ) 16 { *number-base* } . ;

That would shadow the number base used by "." then print the number and
(on scope exit) restore the old base.  RMS felt for a long time (I don't
know about now) that it was important that Emacs used dynamic scope
because it allowed controlling different subsystems that way.  I wrote a
moderate amount of Emacs Lisp code and never had much trouble from it.
Scheme uses lexical scope by default but kept dynamic scope (fluid-let)
as an option.

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

#29133

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> So IMO for non-local access to local variables, if we choose to
> support that, the way to go is lexical scoping.

I do think it's worth supporting non-local access one way or another.
One of the usual objections to Forth locals is they get in the way of
refactoring bigger functions into tiny ones.  If some chunk of code in
the guts of a function refers to locals bound at the function's entry,
you can't easily lift the chunk to outside the function's guts because
there's not a way to give the lifted chunk a name.  You could do that
with nested functions (Algol, Scheme, Python) or with the WHERE clause
(SQL, Haskell), but not with what I see in Forth.  Or with dynamic scope
(I'm not advocating this, I just don't see why it's crazy) you can lift
it completely outside the function to a separate one.  Either of these
mitigates the objection.

I wrote a little bit of Forth code with Gforth locals and it ended up
looking like C code.  Refactoring it was problematic for the above reason.

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

#29141

On Tuesday, March 25, 2014 12:54:17 PM UTC-7, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > So IMO for non-local access to local variables, if we choose to
> > support that, the way to go is lexical scoping.
> 
> I do think it's worth supporting non-local access one way or another.
> One of the usual objections to Forth locals is they get in the way of
> refactoring bigger functions into tiny ones.  If some chunk of code in
> the guts of a function refers to locals bound at the function's entry,
> you can't easily lift the chunk to outside the function's guts because
> there's not a way to give the lifted chunk a name.  You could do that
> with nested functions (Algol, Scheme, Python) or with the WHERE clause
> (SQL, Haskell), but not with what I see in Forth.  Or with dynamic scope
> (I'm not advocating this, I just don't see why it's crazy) you can lift
> it completely outside the function to a separate one.  Either of these
> mitigates the objection.
> 
> I wrote a little bit of Forth code with Gforth locals and it ended up
> looking like C code.  Refactoring it was problematic for the above reason.

You can use MACRO: from my novice package. I did this in my HeapSort function. In either case, to interactively test the sub-function by itself, you would use global variables. After it is tested and you are writing the main-function that uses it, you discard the globals and give the main function locals with the same names.

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

#29145

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> So IMO for non-local access to local variables, if we choose to
>> support that, the way to go is lexical scoping.
>
>I do think it's worth supporting non-local access one way or another.
>One of the usual objections to Forth locals is they get in the way of
>refactoring bigger functions into tiny ones.  If some chunk of code in
>the guts of a function refers to locals bound at the function's entry,
>you can't easily lift the chunk to outside the function's guts because
>there's not a way to give the lifted chunk a name.  You could do that
>with nested functions (Algol, Scheme, Python) or with the WHERE clause
>(SQL, Haskell), but not with what I see in Forth.  Or with dynamic scope
>(I'm not advocating this, I just don't see why it's crazy) you can lift
>it completely outside the function to a separate one.  Either of these
>mitigates the objection.

There are a number of features that prevent the kind of factoring
where you take an arbitrary subsequence of the code and put it in a
separate definition: (incomplete) control structures, return stack
stuff, and locals.  Saying that this is a reason not to use locals is
just a pretext, especially if the same person recommends using the
return stack instead.

Anyway, back to your idea, which is actually two alternative ideas:

1) Nested definitions with lexical scoping: Then you cannot call such
an inner definition separately, and therefore cannot test it
separately.  Not what I consider good factoring.

2) Dynamic scoping: Again, testing is a problem.  Not really good
factoring, either.

Non-local access to locals would be useful when using higher-order
words that take xts and execute them, and where the expected stack
effects of the xts do not allow passing all the parameters to the xts
that we want to pass; in this case we could pass the additional stuff
through an outer local, and live with the mediocre factorability.
That kind of thing is the only use I see for non-local access to
locals.

>I wrote a little bit of Forth code with Gforth locals and it ended up
>looking like C code.  Refactoring it was problematic for the above reason.

That code would be interesting to see.

- 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 2013: http://www.euroforth.org/ef13/

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

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

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

csiph-web