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

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

defer this not

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

Contents

  defer this not Enoch <ixew@hotmail.com> - 2016-07-06 14:21 -0700
    Re: defer this not lawrencedo99@gmail.com - 2016-07-06 18:31 -0700
      Re: defer this not hughaguilar96@gmail.com - 2016-07-06 18:45 -0700
        Re: defer this not lawrencedo99@gmail.com - 2016-07-06 19:54 -0700
          Re: defer this not hughaguilar96@gmail.com - 2016-07-06 22:53 -0700
            Re: defer this not Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-06 23:13 -0700
              Re: defer this not Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-07 08:24 +0200
                Re: defer this not hughaguilar96@gmail.com - 2016-07-06 23:43 -0700
                Re: defer this not "Elizabeth D. Rather" <erather@forth.com> - 2016-07-06 20:52 -1000
                  Re: defer this not JennyB <jennybrien@googlemail.com> - 2016-07-07 00:12 -0700
                    Re: defer this not Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-07 03:52 -0700
                  Re: defer this not hughaguilar96@gmail.com - 2016-07-07 00:53 -0700
                    Re: defer this not Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-07 10:01 +0100
                    Re: defer this not Coos Haak <chforth@hccnet.nl> - 2016-07-07 12:46 +0200
                      Re: defer this not hughaguilar96@gmail.com - 2016-07-07 16:19 -0700
                        Re: defer this not Coos Haak <chforth@hccnet.nl> - 2016-07-08 01:39 +0200
                          Re: defer this not "Elizabeth D. Rather" <erather@forth.com> - 2016-07-07 14:31 -1000
                            Re: defer this not hughaguilar96@gmail.com - 2016-07-07 17:46 -0700
                            Re: defer this not Brad Eckert <hwfwguy@gmail.com> - 2016-07-12 19:48 -0700
                              Re: defer this not "Elizabeth D. Rather" <erather@forth.com> - 2016-07-12 20:58 -1000
                          Re: defer this not hughaguilar96@gmail.com - 2016-07-07 17:41 -0700
                Re: defer this not Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-07 00:11 -0700
                  Re: defer this not Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-07 09:33 +0200
                    Re: defer this not Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-07 03:42 -0700
                      Re: defer this not Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-07 20:31 +0200
                  Re: defer this not "Elizabeth D. Rather" <erather@forth.com> - 2016-07-06 22:22 -1000
    defer this not JennyB <jennybrien@googlemail.com> - 2016-07-06 23:42 -0700
      Re: defer this not hughaguilar96@gmail.com - 2016-07-06 23:49 -0700
    Re: defer this not Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-07-07 13:59 +0200
      Re: defer this not Enoch <ixew@hotmail.com> - 2016-07-07 11:37 -0700
        Re: defer this not Julian Fondren <julian.fondren@gmail.com> - 2016-07-07 12:09 -0700
        Re: defer this not Alex Dowad <alexinbeijing@gmail.com> - 2016-07-07 13:01 -0700
          Re: defer this not Paul Rubin <no.email@nospam.invalid> - 2016-07-07 13:32 -0700
            Re: defer this not Julian Fondren <julian.fondren@gmail.com> - 2016-07-07 14:54 -0700
          Re: defer this not lawrencedo99@gmail.com - 2016-07-12 15:32 -0700

Page 2 of 2 — ← Prev page 1 [2]

#48932

On Thursday, July 7, 2016 at 4:40:03 PM UTC-7, Coos Haak wrote:
> Op Thu, 7 Jul 2016 16:19:28 -0700 (PDT) schreef hughaguilar96@gmail.com:
> 
> > On Thursday, July 7, 2016 at 3:47:17 AM UTC-7, Coos Haak wrote:
> >> Op Thu, 7 Jul 2016 00:53:01 -0700 (PDT) schreef hughaguilar96@gmail.com:
> >> 
> >> <snip>
> >>> As I said, DEFER doesn't work for vectored-execution because IS only
> >>> works at compile-time --- with vectored-execution you typically want
> >>> to choose the vector at run-time depending upon the user's input.
> >> 
> >> IS works in compilation as well as during interpretation.
> >> 
> >> RTFM stupid!
> > 
> > DEFER isn't in the ANS-Forth document, so I can't RTFM. If IS is STATE-smart (it is in the novice-package) then it will work during compilation --- with most implementations it only works during interpretation --- because it is not standardized in ANS-Forth, the ANS-Forth programmer can't expect any particular behavior (if he assumes interpretation only, then his code should be portable to most systems).
> >
> 
> Right, OK. But then you can't say anything about it (and IS) if it works
> during compilation or during interpretation.
> You meant 'in my implementation DEFER doesn't work...'
> 
> groet Coos

In my implementation DEFER works in the usual way --- also, IS works during compilation or during interpretation.

As I also said, VECTOR generates more efficient code than DEFER does.

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

#48877

joi, 7 iulie 2016, 09:24:54 UTC+3, Lars Brinkhoff a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> > DEFER should be used only to resolve mutual-recursions.
> > For vectored execution there is always VARIABLE and then @ EXECUTE.
> 
> Why not use DEFER for vectored execution?

Because it is implementation dependent. I compile in flash (for example). 

Also, I forgot about IS. 

IS should work with VECTOR, not with DEFER. There's no need for IS in the
mutual-recursion-only DEFER. There's only one definition that will
implement the deferred word and that can be just a plain colon definition.

For example:

DEFER DeferredFoo

: bar  DeferredFoo ;

: DeferredFoo   ... ;

Using DEFER for both vectored execution and mutual-rescursion is just
not portable (if you care about portability) but worse, it mix two
very different things. Mutual-recursion is just a compiling issue,
vectored execution is an application technique.

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

#48881

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> There's no need for IS in the mutual-recursion-only DEFER. There's
> only one definition that will implement the deferred word and that can
> be just a plain colon definition.
>
> For example:
>
> DEFER DeferredFoo
>
> : bar  DeferredFoo ;
>
> : DeferredFoo   ... ;

I don't understand.  In this code, bar calls the first DeferredFoo.  The
second DeferredFoo doesn't affect the first DeferredFoo or bar.

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

#48895

joi, 7 iulie 2016, 10:33:34 UTC+3, Lars Brinkhoff a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> > There's no need for IS in the mutual-recursion-only DEFER. There's
> > only one definition that will implement the deferred word and that can
> > be just a plain colon definition.
> >
> > For example:
> >
> > DEFER DeferredFoo
> >
> > : bar  DeferredFoo ;
> >
> > : DeferredFoo   ... ;
> 
> I don't understand.  In this code, bar calls the first DeferredFoo.  The
> second DeferredFoo doesn't affect the first DeferredFoo or bar.

There is only one DeferredFoo. I'm sure you canthink of an implementation 
technique that makes this possible. My LFTForth works this way.

This is in fact an example for Enoch, to show that a simple DEFER declaration
before using the deferred word doesn't hurt and in fact can simplify
the compiler. Enoch wants that the example work without DEFER at all:

: bar  DeferredFoo ;
: DeferredFoo  bar ;

This should silently compile ok. However, having this will "defer" all
undefined word errors till the end of the compilation. The simplest
thing is to declare the deferred word first:

DEFER DeferredFoo
: bar  DeferredFoo ;
: DeferredFoo  bar ;

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

#48918

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> There is only one DeferredFoo. I'm sure you canthink of an implementation 
> technique that makes this possible. My LFTForth works this way.

Sure, but then your're not talking about the DEFER defined in the 2012
standard.  Which is fine, but it confused me.

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

#48891

On 7/6/16 9:11 PM, Raimond Dragomir wrote:
> joi, 7 iulie 2016, 09:24:54 UTC+3, Lars Brinkhoff a scris:
>> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>> DEFER should be used only to resolve mutual-recursions.
>>> For vectored execution there is always VARIABLE and then @ EXECUTE.
>>
>> Why not use DEFER for vectored execution?
>
> Because it is implementation dependent. I compile in flash (for example).
>
> Also, I forgot about IS.
>
> IS should work with VECTOR, not with DEFER. There's no need for IS in the
> mutual-recursion-only DEFER. There's only one definition that will
> implement the deferred word and that can be just a plain colon definition.
>
> For example:
>
> DEFER DeferredFoo
>
> : bar  DeferredFoo ;
>
> : DeferredFoo   ... ;
>
> Using DEFER for both vectored execution and mutual-rescursion is just
> not portable (if you care about portability) but worse, it mix two
> very different things. Mutual-recursion is just a compiling issue,
> vectored execution is an application technique.
>

DEFER/IS is *primarily* for vectored execution. If you want a word 
dedicated to mutual recursion, it should be something else.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#48870

What happens when the name chosen for a forward reference accidentally clashes with that of an existing or future definition?  I would prefer code to self-documents ford references.

Defer A  
: B .... A ... ;
:NONAME ... B ... ; is A

is clear, and works. If the inefficiency bothers you then perhaps your compiler could optimise the pattern, or you preferably you could have a pair of words (say FORWARD and RESOLVE) to declare and handle invariant forward references. 

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

#48873

On Wednesday, July 6, 2016 at 11:42:12 PM UTC-7, JennyB wrote:
> What happens when the name chosen for a forward reference accidentally clashes with that of an existing or future definition?  I would prefer code to self-documents ford references.
> 
> Defer A  
> : B .... A ... ;
> :NONAME ... B ... ; is A
> 
> is clear, and works. If the inefficiency bothers you then perhaps your compiler could optimise the pattern, or you preferably you could have a pair of words (say FORWARD and RESOLVE) to declare and handle invariant forward references.

My naming convention is to put pointy brackets around the function name:

vector A

: B  ... A ... ;

: <A>  ... B ... ;

' <A>  is-A

Your code is fine though --- it doesn't really matter --- whatever people feel comfortable with.

This could be done instead:

vector A

: B  ... A ... ;

:noname  ... B ... ;
is-A

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

#48899

Dear Enoch,

when performance matters, I would suggest using

: first ( ... )
[ here 1 cells allot ]
;

( a-addr )

and later patching back the call when the second definition is known.

: second ( ... )
  first
;

' second make-this-a-call-opcode !

Of course, this is not standard, it works in RAM only and
you have to build a proper opcode yourself.

I found this necessary when I wrote a bit-bang VGA video signal
generator interrupt handler for Mecrisp-Ice, which will be
released with the next mainstream package.

: vga-irq-active ( -- )
  ...
  \ Address of the second handler will be inserted here
  \ as soon as the address is known.
  [ here ] 0 $1FFE !
  ...
;

: vga-irq-sync ( -- )
  ...
  ['] vga-irq-active 2/ $1FFE !
  ...
;

\ Insert the address of the second handler into the first
' vga-irq-sync 2/ swap +!

Technically, this boils down to an optimized variant
of Jennys idea of FORWARD and RESOLVE.

Best wishes,
Matthias

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

#48919

On Thursday, July 7, 2016 at 7:57:32 AM UTC-4, Matthias Koch wrote:
> Dear Enoch,
> 
> when performance matters, I would suggest using
> 
> : first ( ... )
> [ here 1 cells allot ]
> ;
> 
> ( a-addr )
> 
> and later patching back the call when the second definition is known.
> 
> : second ( ... )
>   first
> ;
> 
> ' second make-this-a-call-opcode !
> 
> Of course, this is not standard, it works in RAM only and
> you have to build a proper opcode yourself.
> 
> I found this necessary when I wrote a bit-bang VGA video signal
> generator interrupt handler for Mecrisp-Ice, which will be
> released with the next mainstream package.
> 
> : vga-irq-active ( -- )
>   ...
>   \ Address of the second handler will be inserted here
>   \ as soon as the address is known.
>   [ here ] 0 $1FFE !
>   ...
> ;
> 
> : vga-irq-sync ( -- )
>   ...
>   ['] vga-irq-active 2/ $1FFE !
>   ...
> ;
> 
> \ Insert the address of the second handler into the first
> ' vga-irq-sync 2/ swap +!
> 
> Technically, this boils down to an optimized variant
> of Jennys idea of FORWARD and RESOLVE.
> 
> Best wishes,
> Matthias

Dear Matthias,

I do back patching now, see my Cookbook section in <https://github.com/wexi/amforth-shadow/blob/master/amforth-shadow.org>. I am not happy with it though.

DEFER/IS or even Leo Brodie old MAKE/DOER idea to resolve forward reference add complexity where none is really needed.

A programmer should have the freedom to arrange his word definitions in whatever order he/she wishes (within one compilation unit) without being concerned about creating unresolved forward references, and if this causes the compiler a little effort, so be it.

Shouldn't READABILITY (*) be number one concern of any programming language?

Regards, Enoch.

(*) "Readability refers to the ease with which a human reader can comprehend the purpose, control flow, and operation of source code". Wikipedia on Computer Programming.

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

#48920

On Thursday, July 7, 2016 at 1:37:58 PM UTC-5, Enoch wrote:
> 
> A programmer should have the freedom to arrange his word definitions in whatever order he/she wishes (within one compilation unit) without being concerned about creating unresolved forward references, and if this causes the compiler a little effort, so be it.
> 
> Shouldn't READABILITY {) be number one concern of any programming language?

Suppose I have this code:

  variable file
  : open ( -- )  z" links.list" [ O_WRONLY O_APPEND or ] literal open dup ?ERRUR  file ! ;
  : append ( 'line' -- )  file @ write-file throw ;
  : close ( -- )  file @ close-file throw  -1 file ! ;
  
  : go ( -- )
    open
      get-things append
      get-more-things append
      yet-more? if get-them append then
    close ;

  -- program ends here --

Is there a collision between FILE OPEN APPEND CLOSE GO and anything
else in the program?  I don't have to go looking to figure it out.
I don't have to open every library I might have included to confirm.
The anaswer is "no".  When I see "variable X", or ": X", I know that I
only need to consider the *following* code to know anything relevant
to X.

It is both safe and irrelvant to the above code if somewhere else in
my program, earlier and in the same vocabulary, I had written

  variable file
  : m:logline ( 'log' -- )  -matching
    skipping s" LOG" match m:spaces* m:number m:spaces*
    file into  m:hexnumber m:newline ;

That FILE would be obscured by the later one, but so what?  The short
name is its own hint that I don't care much about its lifetime.  If I
need to access it, what is obscured can still be dug up.

Forth's linearity is a readability aid.  Forth does not have the
lexical scope or the tradition of abusing wordlists that it might have
as readabiliy aids alternate to this one.  Forth's encouagements of
factoring and of having lots and lots of words mean that these
alternate aids would suit the language less, anyway.  Abuse of
wordlists in particular just tends to work out to longer words, the
same as if you'd given them long names in the first place, just more
annoying to use.


Your proposal would make Forth significantly harder to read.


-- Julian

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

#48922

On Thursday, 7 July 2016 20:37:58 UTC+2, Enoch  wrote:
> A programmer should have the freedom to arrange his word definitions in whatever order he/she wishes (within one compilation unit) without being concerned about creating unresolved forward references, and if this causes the compiler a little effort, so be it.

With some programming languages, your code is executed as it is read. With others, your code is parsed in its entirety and put through multiple stages of (often complex) preprocessing, before execution. Forth and Lisp are firmly in the first category, as are all the "scripting languages". You are probably accustomed to languages in the second category, like C or Haskell.

The first type allow for a much simpler implementation. Additionally, they are amenable to interactive use, where you type a line of code and immediately see the results, then type another line, and so on. This is a powerful feature.

Of course, the second type also has its place. But trying to force Forth into the latter paradigm is a poor fit. You would do better to create your own (new) language, and borrow whatever features you like from Forth.

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

#48924

Alex Dowad <alexinbeijing@gmail.com> writes:
>> A programmer should have the freedom to arrange his word definitions
>> in whatever order he/she wishes (within one compilation unit)...
> With some programming languages, your code is executed as it is
> read. With others.... Forth and Lisp are firmly in the first category,
> as are all the "scripting languages".  Of course, the second type also
> has its place. But trying to force Forth into the latter paradigm is a
> poor fit.

The difference isn't whether the whole file is read before execution
starts.  Rather, it's that Forth traditionally uses early binding while
Lisp and scripting languages typically use late binding.  So

  (defun cube (x) (* x (square x)))
  (defun square (x) (* x x))
  (print (cube 3))

prints 27, because when cube is compiled, it allocates a cell for the
previously unseen symbol "square", then when square is compiled it puts
code into that cell, and then when cube is called, it runs the code that
is now in the "square" cell.  The Forth approach would throw an error
in the definition of cube, because square was not already defined.

I believe late-binding Forths have also been implemented.

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

#48926

On Thursday, July 7, 2016 at 3:32:17 PM UTC-5, Paul Rubin wrote:
> I believe late-binding Forths have also been implemented.

Wil Baden's ThisForth made extensive use of macros.  As in:

  s" blah" EVALUATE

The result was that it words were sort of randomly bound.

Redefining + would change some prior uses of it, and not others.
Redefining another word might have the normal result.
This might depend on the current search order.  And BASE

I wasn't around to see how ThisForth was received...


--  Julian

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

#49090

On Friday, July 8, 2016 at 8:01:31 AM UTC+12, Alex Dowad wrote:
> With some programming languages, your code is executed as it is read. With
> others, your code is parsed in its entirety and put through multiple stages
> of (often complex) preprocessing, before execution. Forth and Lisp are
> firmly in the first category, as are all the "scripting languages". You are
> probably accustomed to languages in the second category, like C or Haskell.

What about ones which compile to some intermediate code, which is then interpreted? E.g. Perl, Java, Python. Or even good old UCSD Pascal...

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web