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 6 of 6 — ← Prev page 1 2 3 4 5 [6]

#29150

Anton Ertl wrote:
> 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.

For this kind of stuff I have implemented "executable objects", or 
"callables" as I call them, i.e. you can create an object, where the object 
pointer is also a valid xt.  The higher order function would just EXECUTE 
that object, and the called method can access the member variables.  When 
you are done with the higher order function, you query the results by 
looking at that object.

callable.fs builds on mini-oof2, and is just 16 lines of code (empty lines 
included).

This easily solves the testability problem, because the object works in 
isolation, it carries its state with it, and can be called and examined.

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

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

#29105

On Monday, March 17, 2014 8:36:54 PM UTC-7, Paul Rubin wrote:
> 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.

In my novice package I have EACH that takes an xt to a function that touches every node in the list. I also have EACH[ and ]EACH that wrap the code that touches every node in the list.

The user can write either of these equivalently:

: foo   ...foo-code... ;

: bar  ['] foo each ;

or

: bar  each[ ...foo-code... ]each ;

I would feel more comfortable with giving the user the option to write his program one way or the other, rather than having the compiler internally convert the former into the latter.

There are a lot of problems that could crop up when having the compiler do this conversion automatically. For one thing, FOO may have multiple EXITs. That can be fixed by the compiler replacing the EXITs with a BRANCH to the end. Another problem is that FOO might be recursive. The compiler isn't going to fix this.

I want my language to generate code that is at least twice as fast as SwiftForth code. This is a pretty modest goal. I don't really need to write a complicated optimizer to achieve this --- a fairly simple peephole optimizer should be more than adequate.

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

#29174

On Friday, March 14, 2014 8:36:08 AM UTC-7, Bernd Paysan wrote:
> Alex McDonald wrote:
> >> 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. 
> 
> > And then you slide downhill into name calling and generally being an
> > asshole. Why?

Alex McDonald is the same guy who recently (https://groups.google.com/forum/#!topic/comp.lang.forth/gUJ_0U2LkLU%5B1-25-false%5D) said this:

> You and I have had a long discussion about the poor quality of the
> implementation of popular sorts you wrote in your novice package, where
> you have serious misunderstandings of how pointers work. You and others
> have had discussions about how you didn't invented a tree you called a
> "symtab", because it was well understood years before you dropped off the
> teat; and how you encouraged novices to use it inappropriately because
> its performane sucked.
> 
> I would advise caution before using your code.
...
> We had a long discussion about how your sorts moved records (fixed length
> areas of memory) rather than adjusted a list of pointers, and was going
> to be slow on anything other than a small number of short records due to
> the amount of data being moved.
> ...
> You did not invent anything but
> the name "symtab"; splay trees have been around a lot longer than that.

I don't recall there ever being a time when you didn't say things like this about me. When exactly did we slide downhill? It has always been like this.

I think that you are dragging down the entire Forth community with these mean-spirited attacks. A reader unfamiliar with Forth who comes to CLF to find out what the Forthers are doing, is going to get a bad impression about Forth from you and will likely leave. On one hand, he may believe you and think that I don't know what pointers are (I do), that my SORT can't work with arrays of pointers (it can), and that my symtab is a Splay Tree (it isn't). If he believes your lies, then that is more of an indictment of the Forth language than of me, because how could anybody so grossly incompetent at computer science have been a professional Forth programmer? The kind of problems that you are describing are more typical of QBasic programmers, and would not generally be found in any real programming language. If he sees through your lies (which is likely, because they are too over-the-top to be taken seriously), then this is an indictment of the Forth community (especially because Bernd Payson a member of the Forth-200x standards committee enthusiastically endorses your lies).

All in all, I think that you need to chill out. Stop calling me an "asshole," stop telling lies about me --- stop making the Forth community look bad.
 
> 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.

I never suggested the use of a trampoline. You are putting words in my mouth. I actually said that I didn't know what a trampoline was. I have since looked it up and discovered that what I am doing in my language is called a "fat pointer" --- I had already figured out the trampoline idea on my own (but didn't know the terminology) and dismissed it.

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

Gforth is about half the speed of SwiftForth (running my example programs in the novice package), and SwiftForth is too slow to be usable except as a scripting language (Factor is faster, and Factor has dynamic-OOP for convenience as is typical in scripting languages). I still think that the reason why Elizabeth Rather allows you to be a big chief on the Forth-200x standards committee is because you agreed to cripple Gforth so that it will never be competitive against SwiftForth. Or maybe you are just no good at compiler writing (Why is Gforth written in C? Don't you know x86 assembly language???). Anyway, Gforth will never be used for a commercial application program because it is too slow.

So who cares whether locals in Gforth are as fast or faster than DUP and OVER etc., when everything in Gforth is too slow? 

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

If you like locals so much, you should program in Pascal rather than Forth.

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

We did, did we? LOL

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

#29181

on 29/03/2014 05:18:14, hugh wrote:
[snip]
> 
> I don't recall there ever being a time when you didn't say things like
> this about me. When exactly did we slide downhill? It has always been
> like this .
> 

That reminds me of a joke about an old guy who greased up the soles of
his feet in the morning and died that very evening. His friends said he'd
gone downhill really fast.

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

#29037

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Julian Fondren wrote:
>> \ 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.

I guess that there are people who consider neither variant natural to
Forth.

The version that uses the stack for intermediate storage is in one
sense typical Forth: It saves implementation cost compared to full
closures, and it covers a lot of the cases that full closures cover,
but not all.  If there are several xts to pass, or the control flow of
the higher-order word is complicated, it's probably too complex to
keep the intermediate state on the stack.

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

#29010

In article <lfm7aq$9o5$1@dont-email.me>, WJ <w_a_x_man@yahoo.com> wrote:
>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.

Hoi WJ,
are you Hugh, under a pseudonym?

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

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

#29011

on 11/03/2014 12:51:15,  wrote:
> In article <lfm7aq$9o5$1@dont-email.me>, WJ <w_a_x_man@yahoo.com>
> > wrote:
>>hughaguilar96@yahoo.com wrote:
> > wrote:
>>
> > wrote:
>>> I said that, to be useful, the quotation needs to have access
> > wrote:
>>> to the creator function's local variables. The idea is that
> > wrote:
>>> you have a word (like EACH in my novice package) that
> > wrote:
>>> traverses a data-structure. It is given the xt of a quotation,
> > wrote:
>>> and it EXECUTEs this xt for every node in the data-structure,
> > wrote:
>>> giving the quotation that node's address as a parameter. The
> > wrote:
>>> quotation needs to have access to the creator function's local
> > wrote:
>>> variables so that it can communicate back information that it
> > wrote:
>>> obtains from the data-structure nodes.
> > wrote:
>>>
> > wrote:
>>> Bernd Payson kicked me off the Forth-200x mailing list for saying this.
> > wrote:
>>
> > wrote:
>>Tyranny.
> wrote:
> 
> Hoi WJ,
> are you Hugh, under a pseudonym?
> 
> Groetjes Albert

Willima James aka waxman is an entirely seperate whackaloon. Hugh is far
more verbose, and is obsessed with making sure everyone understands he
isn't a homosexual. WJ doesn't seem interested in people at all, failing
to interact in anything more than single words and snippets of code in OT
languages. Unless you post with long lines. Then he does you the service
of reformatting them and calling you an idiot in a long paragraph of
text.

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

#27370

On Thursday, December 19, 2013 7:58:03 PM UTC+4, Anton Ertl wrote: >
Alexander Skobelev writes:
> >Hello all,
> 
> >I'm just wondering, what is common opinion (if it exists) about using
> >code blocks (something like 'quotes' in Retro forth) among
> >experienced Forthers? Would it be a valuable addition to Forth?
> 
> Please limit lines to about 72 chars in length.

Sorry, I was thoughless posting through Google groups.
  
> 
> Yes, quotations are a valuable addition to Forth.

Excellent! Mmm, is there any chance to get them in dpANS then? :)

> 
> >Just for example here a very naive Gforth-specific implementation of
> >local code blocks (i.e not intended to be used anywhere but only
> >inside a word definition):
> 
> The current development version of Gforth supports quotations.  You
> find the source code in
> 
> http://git.savannah.gnu.org/cgit/gforth.git/tree/quotations.fs
> 
> But there are also changes in glocals.fs to properly support locals in
> quotations.  If you want to use it, better get the current git
> version.

Unfortunately, I have failed to compile it so far on my Mac with MacOSX
10.8.5. It seems that the problem is somehow connected to TLS and GForth
C interface. 

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

#27389

Alexander Skobelev <al.skobelev@gmail.com> writes:
>On Thursday, December 19, 2013 7:58:03 PM UTC+4, Anton Ertl wrote: >
>> Yes, quotations are a valuable addition to Forth.
>
>Excellent! Mmm, is there any chance to get them in dpANS then? :)

I expect that someone will make a proposal for that in the
not-too-distant future.  We will see how it fares then.

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

#27372

On Thursday, December 19, 2013 7:58:03 PM UTC+4, Anton Ertl wrote: >
Alexander Skobelev writes:
> >Hello all,
> 
> >I'm just wondering, what is common opinion (if it exists) about using
> >code blocks (something like 'quotes' in Retro forth) among
> >experienced Forthers? Would it be a valuable addition to Forth?
> 
[…]
> The current development version of Gforth supports quotations.  You
> find the source code in
> 
> http://git.savannah.gnu.org/cgit/gforth.git/tree/quotations.fs
> 
> But there are also changes in glocals.fs to properly support locals in
> quotations.  If you want to use it, better get the current git
> version.

Even if libcc compilation failed on my machine it looks like I still
able to run the gforth itself. So, I have tried gforth's implementation
of quotes. It look like they don't allow me to access local variables in
definition, do they? If it so, is there is any chance they will do? For
without access to local variables I don't see an easy way to implement
something like I did with my dirty implementation:

: test-hello { c-addr u -- }
    u 15 <
    [:
       [: c-addr u S" Hello"         cstring-prefix   ;] 
       [: c-addr u S" How do you do" cstring-contains ;] e-or
       [: c-addr u S" How are you"   cstring-contains ;] e-or
       [: c-addr u S" Good morning"  cstring-prefix   ;] e-or
    ;] e-and
 
    if ." Hello! " else ." Bye!" then cr ;

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

#27377

On Friday, December 20, 2013 8:24:40 AM UTC+1, Alexander Skobelev wrote:
[..]
> It look like they don't allow me to access local variables in
> definition, do they? If it so, is there is any chance they will do? For
> without access to local variables I don't see an easy way to implement
> something like I did with my dirty implementation:
> 
> : test-hello { c-addr u -- }
>     u 15 <
>     [:
>        [: c-addr u S" Hello"         cstring-prefix   ;] 
>        [: c-addr u S" How do you do" cstring-contains ;] e-or
>        [: c-addr u S" How are you"   cstring-contains ;] e-or
>        [: c-addr u S" Good morning"  cstring-prefix   ;] e-or
>     ;] e-and
> 
>     if ." Hello! " else ." Bye!" then cr ;

You didn't test the new e-or and e-and :-) Your code won't 
work in any Forth. See the additions marked with ( **).

Thank you for posting. After correcting the bugs it still
wouldn't work in iForth because of the nested codeblocks (iForth
was using a VALUE dict). After changing the VALUE to a circular 
stack I got the below results.

-marcel

-- -----------------------------------------
: (xt?) ( flag|xt -- flag )
    dup 
    0= if
        drop
        FALSE
    else 
        TRUE <>
    then ;

: e-or ( flag|xt xt - flag )
    swap dup (xt?) if execute then
    if
        drop ( **)  TRUE
    else
        dup (xt?) if execute then
    then ; 

: e-and ( flag|xt xt - flag )
    swap dup (xt?) if execute then
    if
        dup (xt?) if execute then
    else
        drop ( **) FALSE
    then ; 

: cstring-contains ( c-addr1 u1 c-addr2 u2 -- flag )
    search -rot 2drop ;

: cstring-prefix ( c-addr1 u1 c-addr2 u2 -- flag )
    LOCALS| u2 c-addr2 u1 c-addr1 |
    c-addr1 u1 c-addr2 u2 search if drop c-addr1 = else 2drop FALSE then ;

: test-hello ( c-addr u -- ) 
    LOCALS| u c-addr |
    u 15 <
    [:
       [: c-addr u S" Hello"         cstring-prefix   ;]
       [: c-addr u S" How do you do" cstring-contains ;] e-or
       [: c-addr u S" How are you"   cstring-contains ;] e-or
       [: c-addr u S" Good morning"  cstring-prefix   ;] e-or
    ;] e-and
    CR if ." Hello! " else ." Bye!" then ; 

3 test-ntimes
-1  0 test-e-or .
 0 -1 test-e-or .
-1  0 test-e-and .
-1 -1 test-e-and .
cr true test-foo
   false test-foo

s" Hi!" test-hello
s" Hello" test-hello
s" Hello my little fellow" test-hello

-- output:
FORTH> in /idfwforth/examples/internet/idata/codeblocks
Redefining e-or
Redefining e-and
0 time
1 time
2 time
1st is -1 -> -1 -1
1st is 0
2nd is -1 -> -1 -1
1st is 0 -> 0 0
1st is -1
2nd is -1 -> -1 -1
55 3628800
Bye!
Hello!
Bye! ok   \ the test string is longer than 15 chars :-)

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

#27382

Alexander Skobelev <al.skobelev@gmail.com> writes:
>Even if libcc compilation failed on my machine it looks like I still
>able to run the gforth itself. So, I have tried gforth's implementation
>of quotes. It look like they don't allow me to access local variables in
>definition, do they? If it so, is there is any chance they will do?

They don't, and it's not planned that they do.  Accessing outer locals
would in general mean full closures, and that's hard to implement.
Even if we restrict ourselves to Pascal-like nested functions, the
implementation would be relatively complex and/or slow and it's not
clear that that's something that many Forth programmers want.

> For
>without access to local variables I don't see an easy way to implement
>something like I did with my dirty implementation:
>
>: test-hello { c-addr u -- }
>    u 15 <
>    [:
>       [: c-addr u S" Hello"         cstring-prefix   ;]=20
>       [: c-addr u S" How do you do" cstring-contains ;] e-or
>       [: c-addr u S" How are you"   cstring-contains ;] e-or
>       [: c-addr u S" Good morning"  cstring-prefix   ;] e-or
>    ;] e-and
>=20
>    if ." Hello! " else ." Bye!" then cr ;

Just use the stack.  But in general I don't like short-circuit
conditionals in Forth, exactly because they make it harder to see
what's going on on the stack.

Here's a working version:

: e-or ( flag1 xt2 -- flag )
    swap if
        drop TRUE
    else
        execute
    then
; 

: e-and ( flag1 xt2 -- flag )
    swap if
        execute
    else
        drop FALSE
    then
;

: string-contains? ( c-addr1 u1 c-addr2 u2 -- f )
    search nip nip ;

: test-hello ( c-addr u -- )
    dup 15 <
    [:
       2dup S" Hello"         string-prefix?
       [: 2dup S" How do you do" string-contains? ;] e-or
       [: 2dup S" How are you"   string-contains? ;] e-or
       [: 2dup S" Good morning"  string-prefix?   ;] e-or
    ;] e-and
    nip nip
    if ." Hello! " else ." Bye!" then cr ;

Test input and output as follows:

s" Good morning" test-hello .s Hello! 
<0>  ok
s" How are you" test-hello Hello! 
 ok
s" xHow do you do" test-hello .s Hello! 
<0>  ok
s" Hello" test-hello .s Hello!                        
<0>  ok
s" Hi" test-hello .s Bye!
<0>  ok

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

#27390

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Alexander Skobelev <al.skobelev@gmail.com> writes:
>> For
>>without access to local variables I don't see an easy way to implement
>>something like I did with my dirty implementation:
>>
>>: test-hello { c-addr u -- }
>>    u 15 <
>>    [:
>>       [: c-addr u S" Hello"         cstring-prefix   ;]=20
>>       [: c-addr u S" How do you do" cstring-contains ;] e-or
>>       [: c-addr u S" How are you"   cstring-contains ;] e-or
>>       [: c-addr u S" Good morning"  cstring-prefix   ;] e-or
>>    ;] e-and
>>=20
>>    if ." Hello! " else ." Bye!" then cr ;
>
>Just use the stack.

Another alternative would be to define short-circuit words that do not
take quotations but just compile control-flow code directly.  I don't
see any advantage from the use of quotations for implementing
short-circuit conditionals.  And then you can use locals even inside
the short-circuited code, and the implementation will be more
efficient.

Wil Baden has done some work on short-circuiting words, but I don't
remember what names he used, so I will just make up my own:

: or< ( f -- )
    postpone 0= postpone if ; immediate

: >or ( -- )
    postpone else postpone true postpone then ; immediate

: and< ( f -- )
    postpone if ; immediate

: >and ( -- )
    postpone else postpone false postpone then ; immediate


: string-contains? ( c-addr1 u1 c-addr2 u2 -- f )
    search nip nip ;

: test-hello { c-addr u -- }
    u 15 < and<
       c-addr u S" Hello"         string-prefix? or<
         c-addr u S" How do you do" string-contains? or<
           c-addr u S" How are you"   string-contains? or<
             c-addr u S" Good morning"  string-prefix? >or >or >or >and
    if ." Hello! " else ." Bye!" then cr ;

I guess one can get rid of the "else <lit-flag> then" parts in some
way, and Wil Baden probably did, but that's good enough for
demonstration purposes.  The test worked fine:

s" How are you" test-hello .s Hello! 
<0>  ok
s" Good morning" test-hello .s Hello! 
<0>  ok
s" How are you" test-hello .s Hello! 
<0>  ok
s" xHow do you do" test-hello .s Hello! 
<0>  ok
s" Hello" test-hello .s Hello! 
<0>  ok
s" Hi" test-hello .s Bye!
<0>  ok

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

#27393

On Friday, December 20, 2013 9:46:31 PM UTC+4, Anton Ertl wrote:
> (Anton Ertl) writes:
> >Alexander Skobelev writes:
> >> For
> >>without access to local variables I don't see an easy way to implement
> >>something like I did with my dirty implementation:
> >>
> >>: test-hello { c-addr u -- }
> >>    u 15 <
> >>    [:
> >>       [: c-addr u S" Hello"         cstring-prefix   ;]=20
> >>       [: c-addr u S" How do you do" cstring-contains ;] e-or
> >>       [: c-addr u S" How are you"   cstring-contains ;] e-or
> >>       [: c-addr u S" Good morning"  cstring-prefix   ;] e-or
> >>    ;] e-and
> >>=20
> >>    if ." Hello! " else ." Bye!" then cr ;
> >
> >Just use the stack.
> 
> Another alternative would be to define short-circuit words that do not
> take quotations but just compile control-flow code directly.  I don't
> see any advantage from the use of quotations for implementing
> short-circuit conditionals.  And then you can use locals even inside
> the short-circuited code, and the implementation will be more
> efficient.
> 
> Wil Baden has done some work on short-circuiting words, but I don't
> remember what names he used, so I will just make up my own:
> 
> : or< ( f -- )
>     postpone 0= postpone if ; immediate
> 
> : >or ( -- )
>     postpone else postpone true postpone then ; immediate
> 
> : and< ( f -- )
>     postpone if ; immediate
> 
> : >and ( -- )
>     postpone else postpone false postpone then ; immediate
> 
> : string-contains? ( c-addr1 u1 c-addr2 u2 -- f )
>     search nip nip ;
> 
> : test-hello { c-addr u -- }
>     u 15 < and<
>        c-addr u S" Hello"         string-prefix? or<
>          c-addr u S" How do you do" string-contains? or<
>            c-addr u S" How are you"   string-contains? or<
>              c-addr u S" Good morning"  string-prefix? >or >or >or >and
>     if ." Hello! " else ." Bye!" then cr ;
> 
> I guess one can get rid of the "else <lit-flag> then" parts in some
> way, and Wil Baden probably did, but that's good enough for
> demonstration purposes.  The test worked fine:
> 

Yes that is a good alternative. Or, to be more precise, I'd say that is
a good alternative in the case when we don't have a quotations. For all
that it is a special way of solving a particular task – to implement
short-circuit operators. The quotations is a more general tool.

I'm voting not for the full fledged quotations, that are almost like the
usual Forth words just without a name.  I'd prefer to have a local
quotations – that are not the words but rather syllables. They are parts
of a word definition that are happy to get their own XT. So they can not
have their own local variables and are not valid outside the scope of
the definition body. But being a part of definition they can access the
its locals.

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

#27402

Alexander Skobelev <al.skobelev@gmail.com> writes:
>I'm voting not for the full fledged quotations, that are almost like the
>usual Forth words just without a name.  I'd prefer to have a local
>quotations =96 that are not the words but rather syllables. They are parts
>of a word definition that are happy to get their own XT. So they can not
>have their own local variables and are not valid outside the scope of
>the definition body. But being a part of definition they can access the
>its locals.

Having their own locals costs nothing at run-time and is not too
expensive to implement (true, it does not buy much, either).

Accessing outer locals does cost extra, even if the quotation cannot
be passed out.  Consider:

: foo {: xt :} xt execute ;

: bar {: a b :} [: a b + ;] foo ;

: flip {: xt :} xt foo ;

: flop {: c :} [: c ;] flip ;

We need frame pointers and static links (or a display) for this to
work in general, which locals up to now don't need.

Maybe we will find that feature useful enough that we want to require
it eventually, but I don't see that yet.  For a first proposal, the
chances of succes are probably best if it does not propose
standardizing locals in quotations at all.

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

#27406

Anton Ertl wrote:

> Alexander Skobelev <al.skobelev@gmail.com> writes:
>>I'm voting not for the full fledged quotations, that are almost like the
>>usual Forth words just without a name.  I'd prefer to have a local
>>quotations =96 that are not the words but rather syllables. They are parts
>>of a word definition that are happy to get their own XT. So they can not
>>have their own local variables and are not valid outside the scope of
>>the definition body. But being a part of definition they can access the
>>its locals.
> 
> Having their own locals costs nothing at run-time and is not too
> expensive to implement (true, it does not buy much, either).
> 
> Accessing outer locals does cost extra, even if the quotation cannot
> be passed out.  Consider:
> 
> : foo {: xt :} xt execute ;
> 
> : bar {: a b :} [: a b + ;] foo ;
> 
> : flip {: xt :} xt foo ;
> 
> : flop {: c :} [: c ;] flip ;
> 
> We need frame pointers and static links (or a display) for this to
> work in general, which locals up to now don't need.

Actually no, there's an impelentation method through a trampoline, which is 
relatively easy to do:

For each quotation that works as nested function (accesses outer locals), 
you create a local buffer which contains the CFA of a wrapper function and 
the pointer to the outer local scope and the static part of the quotation.  
The wrapper function's DOES> part is just

DOES> 2@ execute ;

and the quotation xt itself is equal to

:noname {: display :} ... ;

whereas all references to the outer locals use "display" as base.

IIRC, GCC uses such a "trampoline" technique for nested functions:

http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html

> Maybe we will find that feature useful enough that we want to require
> it eventually, but I don't see that yet.  For a first proposal, the
> chances of succes are probably best if it does not propose
> standardizing locals in quotations at all.

Yes.

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

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

#27460

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Accessing outer locals does cost extra, even if the quotation cannot
>> be passed out.  Consider:
>> 
>> : foo {: xt :} xt execute ;
>> 
>> : bar {: a b :} [: a b + ;] foo ;
>> 
>> : flip {: xt :} xt foo ;
>> 
>> : flop {: c :} [: c ;] flip ;
>> 
>> We need frame pointers and static links (or a display) for this to
>> work in general, which locals up to now don't need.
>
>Actually no, there's an impelentation method through a trampoline, which is 
>relatively easy to do:
>
>For each quotation that works as nested function (accesses outer locals), 
>you create a local buffer which contains the CFA of a wrapper function and 
>the pointer to the outer local scope and the static part of the quotation.  

Yes, trampolines are a way to implement static links (what you call
"pointer to the outer local scope"), and their advantage is that we
can still pass the xt as one cell (instead of as a tuple of code
pointer and static link), with the disadvantage that we need to
construct a trampoline every time a quotation occurs in the execution.

At least this does not make local locals more expensive, so the main
impediment to implementation is the needed implementation effort (and
the small expected benefit accruing from it).

My thinking about implementing non-local "locals" through trampolines
in Gforth is that we would have a doer (code routine for a kind of
word, like docol and dovar) for such trampolines, say, dotrampoline,
and this doer is followed by a threaded-code pointer and the static
link.  But currently I have no plans to actually do that.

- 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] | [standalone]

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

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

csiph-web