• Re: quotations

    From Paul Rubin@21:1/5 to dxf on Sat Feb 8 23:41:38 2025
    dxf <dxforth@gmail.com> writes:
    quotations ... strike me as being wrong in every way, not least
    because they are intended to feature prominently, stuffed in one's
    face. I don't understand the appeal at all.

    I never got the impression they were supposed to be so prominent, though
    I guess one could program in a style that uses them heavily. My first
    Forth program used a lot of XT's but in retrospect, it was rather
    unidiomatic.

    The following sort of follows an idiom for Python GUI programs. You
    have a function MAKE-BUTTON that puts a button on the screen. The
    button has a label, and it calls a function when you press it. This
    is using the notation from Anton's post but I haven't tested it.

    : make-button ( a u xt -- ) ... ;
    \ a u is the label, xt is the action

    Now you want to draw buttons for a numeric keypad:

    : make-action ( n -- xt ) [n:d ." You pressed " . ] ;
    : make-label ( n -- a u ) \ make a string like "5" in the dictionary
    here { a } 1 chars allot '0' + a c! a 1 ;

    : keypad ( -- ) 10 0 do
    i make-label i make-action make-button
    loop ;

    Now there will be buttons labelled "0", "1", ... "9", and and when you
    press one, it will print "you pressed 5" or whatever for that button.

    I think the idiomatic old-school Forth alternative to this would be an
    OOP-like approach, but the above is probably more concise, and to some
    of us more intuitive.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Rubin@21:1/5 to dxf on Sun Feb 9 02:36:04 2025
    dxf <dxforth@gmail.com> writes:
    IMO it does nothing for readability to see a definition interrupted by another. My reaction is one of WTF.

    Maybe it looks weird in Forth, but similar things were present in
    languages as old as Fortran, which had "statement functions" (idk when
    those were introduced though). Algol had them, and lambda calculus
    (invented in the 1920's, before computers existed) had them. It's not inherently bad, though it can make code confusing if over-used. node.js
    uses the style heavily in a deeply nested and painful way.

    : make-action ( n -- xt ) [n:d ." You pressed " . ] ;
    I don't understand make-action at all. What is it meant to be doing?

    Imagine this function:

    : action-5 ( -- ) ." you pressed 5" ;

    That does the obvious thing: prints a fixed message, nothing else.
    Similarly you want action-1, action-2, and so on.

    How to generalize that? How about just having something that takes
    a numeric argument, and gives you an xt that runs that action?

    : make-action-n ( n -- xt ) ( need some magic here! ) ... ;

    So, "5 make-action-n" gives an xt that is equivalent to ' action-5,
    but you can make independent xt's for other values of n.

    That's what I called make-action in the example I showed, and for the
    "magic" it used a quotation. Maybe there is some reasonably easy
    alternative way to do the same thing in traditional Forth. The only
    ones that occur to me right now are pretty messy though.

    Call me boring but I don't like inventing new syntax only to have to

    Well, it's a one-time addition of new syntax, not something re-learned
    in every new program. Like 'x' is new syntax for [char] x, but once
    you've used it a few times you remember it and it seems to me like an improvement.

    So are quotations worth it for Forth? I don't know. I see some uses
    for them but I'd tend to say that style is more common in GC'd
    languages.

    the antithesis of Forth - the opposite of being simple.

    Forth is simple in some ways, complicated (or at least non-intuitive) in
    others ;).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From minforth@21:1/5 to Paul Rubin on Sun Feb 9 14:35:23 2025
    On Sun, 9 Feb 2025 10:36:04 +0000, Paul Rubin wrote:

    So are quotations worth it for Forth? I don't know. I see some uses
    for them but I'd tend to say that style is more common in GC'd
    languages.

    Forth quotations are embedded anonymous functions. They
    produce a single execution token on the stack. No GC required.

    Forth closures are not standard. But generally spoken, closures
    are single-function aka one-shot objects. So gforth-specific
    closures offer several ways to free used memory after use.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to dxf on Sun Feb 9 15:45:00 2025
    dxf <dxforth@gmail.com> writes:
    What language do you know where
    nested definitions are nameless?

    Just to name a few: Lisp, Smalltalk, Postscript, Joy, Factor. A much
    longer list can be found at <https://en.wikipedia.org/wiki/Anonymous_function#List_of_languages>.

    - 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: https://forth-standard.org/
    EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
    EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From albert@spenarnc.xs4all.nl@21:1/5 to Anton Ertl on Sun Feb 9 20:13:12 2025
    In article <2025Feb9.164500@mips.complang.tuwien.ac.at>,
    Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
    dxf <dxforth@gmail.com> writes:
    What language do you know where
    nested definitions are nameless?

    Just to name a few: Lisp, Smalltalk, Postscript, Joy, Factor. A much
    longer list can be found at ><https://en.wikipedia.org/wiki/Anonymous_function#List_of_languages>.

    In algol 68 the function is

    proc add := (int x, int y) int : x+y; 1)

    You have a symbolic reference add where a function is filled in.
    Lateron you can reassign the function add with a "function denotation"
    (int a, int b) int : a-b;

    [But the "(int x, int y) int " signature sticks.
    Formally it is an abbreviation of
    proc add (int x, int y) int := (int x, int y) int : x+y; ]

    This is the insight that I wanted to convey that the
    function denotation is fundamental, and the name is incidental.

    - anton

    Groetjes Albert

    1) Normally you use = instead of :=. Then you cannot change assign
    to add.
    --
    Temu exploits Christians: (Disclaimer, only 10 apostles)
    Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
    Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
    And Gifts For Friends Family And Colleagues.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From albert@spenarnc.xs4all.nl@21:1/5 to dxforth@gmail.com on Mon Feb 10 14:50:55 2025
    In article <9f5d42ff6471fb5bd1c209e39527b7cdf715546c@i2pn2.org>,
    dxf <dxforth@gmail.com> wrote:
    On 10/02/2025 2:45 am, Anton Ertl wrote:
    dxf <dxforth@gmail.com> writes:
    What language do you know where
    nested definitions are nameless?

    Just to name a few: Lisp, Smalltalk, Postscript, Joy, Factor. A much
    longer list can be found at
    <https://en.wikipedia.org/wiki/Anonymous_function#List_of_languages>.

    "The use of anonymous functions is a matter of style. Using them is never
    the only way to solve a problem; each anonymous function could instead be defined as a named function and called by name."

    So it's a style - a fashion statement.

    This remembers me of FORTRAN code long ago.

    print( sin(t*x))

    was too hard to understand.

    It is recommended to do:

    a = t*x
    b= sin(a)
    print(b)

    See also my post about the dispatch table for lisp in this thread.

    Groetjes Albert
    --
    Temu exploits Christians: (Disclaimer, only 10 apostles)
    Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
    Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
    And Gifts For Friends Family And Colleagues.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)