factor-talk — Discussion about the Factor programming language

Re: [Factor-talk] command-line.parser but with commands?

[toastal <to...@po...>]

> Argument parsing is a deep topic and few libraries fit all use cases.

I understand that. The my goal here is wanting to ‘bundle’ a collection
of tiny, related applications (like the aforementioned ``git`` &
``pijul`` examples) but avoiding the startup times / executable size of
dispatching to separate executables.

An alternative approach would be understanding how to best share code /
an image if needed to accomplish said task instead of shipping multiple
copies of very similar images.

> Argument parsing is a deep topic and few libraries fit all use cases.

Alternative 2 might be exposing more of the ``PRIVATE`` bits to
consumers since many of the pieces are there to assemble your own
system, but the exposed vocab kinda forces the consumer into
using the vocab in a singular way. Unsure.

> http://docopt.org

I did see this mentioned in the origin argument parsing weblog post. But
it does seem the project `would need to be resurrected if used
<https://github.com/docopt/docopt/issues/519>`_.

------------------------------------------------------------------------

I think I should just let these ideas marinate in my mind me a while as
there might a simpler solution — even if were some hack like throwing
$INSERT_LANGUAGE’s argument parser to do the dispatch. 

But speaking of the `Re: Factor <https://re.factorcode.org>`_ blog… it
is a great corpus of a decade of code examples & thought process — which
is often quite humorous / entertaining. It’s a good read & valuable
regardless of programming language background.

Re: [Factor-talk] command-line.parser but with commands?

[John B. <mr...@gm...>]

> Regardless of whether going ``foo add`` or ``foo substract`` there is
> still value is top-level flags beyond ``--help`` — namely ``--version``.
> I wouldn’t expect to need to add ``--version`` flags to both ``add`` &
> ``subtract``, & while I could, downstream users would be confused that
> they need to use ``foo add --version`` or ``foo substract --version``,
> but not ``foo --version``. As a developer, I need to choose to opt into
> ``with-commands`` or ``with-options`` as either will fail if parsing
> came up blank. I can assume there is a try-catch mechanism that could be
> used to run ``with-options`` first for top-level, then try
> ``with-commands``, but that doesn’t seem like the intended UX but a
> hack.

Some good points.  I guess I would say:

It likely does needs to be extended to support top-level options.

The developer would typically know if they want sub-commands and opt-into the specific parser they want.

Argument parsing is a deep topic and few libraries fit all use cases.

I had hesitated to promote command-line.parser to basis/ as it feels a little clunky, which is partly due to inheriting the clunky-ness that python's ArgumentParser contained.

I've wanted a docopt style parser for Factor, for awhile.  See http://docopt.org/ for more info.   Contributions welcome!

If you come up with improvements, please let us know.

Thanks,
John.

Re: [Factor-talk] command-line.parser but with commands?

[toastal <to...@po...>]

> I think the command-line.parser vocab works as-is, but it's a little
> unwieldy and maybe more fragile than it should be.  Improvements and
> PRs welcome. 
>
> Let me know how that works (or not) for you.
>
> Thanks,
> John.

On second thought, while the help text is working as expected &
CONSTANT: COMMANDS *looks* about what I expected, the actual usage /
ergonomics are not what I expected. Maybe I am using it wrong… I did
hdo catch the post via Atom in my feed reader:
https://re.factorcode.org/2025/07/command-arguments.html

For one:

> There are other features we might want to add to this including
> per-command metadata with a brief description of the command, support
> for additional top-level options besides just the command, and perhaps
> a different way of handling the no command case rather than empty
> output.

Regardless of whether going ``foo add`` or ``foo substract`` there is
still value is top-level flags beyond ``--help`` — namely ``--version``.
I wouldn’t expect to need to add ``--version`` flags to both ``add`` &
``subtract``, & while I could, downstream users would be confused that
they need to use ``foo add --version`` or ``foo substract --version``,
but not ``foo --version``. As a developer, I need to choose to opt into
``with-commands`` or ``with-options`` as either will fail if parsing
came up blank. I can assume there is a try-catch mechanism that could be
used to run ``with-options`` first for top-level, then try
``with-commands``, but that doesn’t seem like the intended UX but a
hack.

The options type is ``{ T{ } }``,   but commands is ``H{ "" { T{ }
} }`` so they can’t intermingle (which is why I had mentioned
``commands`` as a possible option type in the original email rather than
a separate parsing style one must choose between).

Secondly:

I can’t just have a bare command like ``version`` that prints the
version (in lieu of no ``--version``). An option would be like

.. code:: factor

	SYMBOL: version
	
	MAIN: [
	   H{
	      {
	         "version"
	         {
	            T{ option
	               { name "--version" }
	               { type boolean }
	               { default t }
	               { variable version }
	            }
	         }
	      }
	      {
	   } [ version get . ] with-commands
	]

With like a phantom default boolean that could be checked, but it this
definitely feels like another hack. Leading to…

Thirdly:

Maybe the UX is off entirely as I would assume subcommands would lead to
their own branches like

.. code:: factor

	H{
	    {
	       "add"
	       [ ! call this quotation for “add” options
	       ]
	    }
	    {
	       "subtract"
	       [ ! call this quotation for ”substract” options
	       ]
	    }
	} TOP-LEVEL-OPTIONS with-commands-&-options

where the inner quotations might behave like ``with-options`` on their
respective options a bit like ``cond`` traversing/dispatching on the
hashmap rather than a flattening of say ``SYMBOL``s at the global level
& tons of if null checks to try to guess the user’s intent. 

With a UX more along these lines, I think the ``foo version`` (or
whatever bare command one could want) would have been covered since its
options could have been left empty rather than the phantom
``--version``. It also could avoid series of global checks as once in
the ``add`` branch, all other branches are definitely irrelevant &
shouldn’t be checked.

— toastal

Re: [Factor-talk] command-line.parser but with commands?

[toastal <to...@po...>]

> Perhaps this latest change helps you.
>
> https://github.com/factor/factor/commit/666a44bfc2b24b811bfde3a971e09a56ae7ad581

Oh, this looks like what I would expect from command-line.parser
library. Excellent, excellent work!

Re: [Factor-talk] command-line.parser but with commands?

[John B. <mr...@gm...>]

Perhaps this latest change helps you.

https://github.com/factor/factor/commit/666a44bfc2b24b811bfde3a971e09a56ae7ad581

If you define your commands list ("add", "subtract"):

https://paste.factorcode.org/paste?id=4743

You can see that it works more-or-less as you expect:

$ ./factor foo.factor

$ ./factor foo.factor --help
Usage:
    factor foo.factor [--help] [command]

Arguments:
    command    {add,subtract}

Options:
    --help    show this help and exit

$ ./factor foo.factor add --help
Usage:
    factor foo.factor add [--help] [a]

Arguments:
    a

Options:
    --help    show this help and exit

$ ./factor foo.factor multiply
ERROR: Invalid value 'multiply' for option 'command'

I think the command-line.parser vocab works as-is, but it's a little unwieldy and maybe more fragile than it should be.  Improvements and PRs welcome. 

Let me know how that works (or not) for you.

Thanks,
John.


> On Jul 7, 2025, at 12:08 PM, toastal <to...@po...> wrote:
> 
> It is pretty close, but the thing with command-line.parser, is that you
> can get --help (& in the future, command line completions, manpages,
> etc.) for free if following its API. That was the part that the big
> appeal over just coding my own over a switch statement.
> 
> 
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] command-line.parser but with commands?

[toastal <to...@po...>]

It is pretty close, but the thing with command-line.parser, is that you
can get --help (& in the future, command line completions, manpages,
etc.) for free if following its API. That was the part that the big
appeal over just coding my own over a switch statement.

Re: [Factor-talk] command-line.parser but with commands?

[Zoltán K. <zo...@pr...>]

On second thought, I think I misunderstood your intentions. Disregard my previous messages.

On Sunday, July 6th, 2025 at 5:13 PM, Zoltán Kéri via Factor-talk <fac...@li...> wrote:

> I made a mistake in the previous code, it does not print the unknown command. Both
> 
> > [ swap drop "Unknown command: " swap append print nl flush help flush 1 exit ]
> 
> 
> and
> 
> > [ "Unknown command: " prepend print nl flush help flush 1 exit ]
> 
> 
> prints it[1], although I am pretty sure there is a better way to achieve this. In fact, you could use "unclip" in other parts of the code, but this was just supposed to be a simple demonstration.
> 
> Additionally, you could create a helper word for "unknown command" if it looks not-so-desirable.
> 
> [1] Example output:
> 
> zolk3ri@void foo $ ./foo.out
> Usage: foo [command]
> Available commands:
> greet - Print a greeting
> help - Show this message
> zolk3ri@void foo $ ./foo.out greet
> Hello from Factor!
> zolk3ri@void foo $ ./foo.out foo
> Unknown command: foo
> 
> Usage: foo [command]
> Available commands:
> greet - Print a greeting
> help - Show this message
> 
> Is this close to what you are trying to achieve?
> 
> On Sunday, July 6th, 2025 at 4:08 PM, Zoltán Kéri zo...@pr... wrote:
> 
> > I believe you are looking for something like this unless I am mistaken:
> > 
> > USING: combinators command-line io kernel namespaces sequences ;
> > IN: foo
> > 
> > ! Help text
> > : help ( -- )
> > "Usage: foo [command]" print
> > "Available commands:" print
> > " greet - Print a greeting" print
> > " help - Show this message" print ;
> > 
> > ! Command: greet
> > : greet ( -- )
> > "Hello from Factor!" print ;
> > 
> > ! Dispatch function: handles command and its arguments
> > : dispatch ( cmd rest -- )
> > {
> > { "greet" [ drop greet ] }
> > { "help" [ drop help ] }
> > [ drop "Unknown command: " swap append print help ]
> > } case ;
> > 
> > ! Entry point
> > : run ( -- )
> > command-line get dup empty? [
> > drop help
> > ] [
> > dup rest swap first dispatch
> > ] if ;
> > 
> > MAIN: run
> > 
> > You can extend it to your liking.
> > 
> > On Saturday, July 5th, 2025 at 9:34 PM, toastal to...@po... wrote:
> > 
> > > > Are you trying to use something like a “sub command” feature?
> > > 
> > > Yep. Like Cmdliner.
> > > 
> > > https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html
> > > 
> > > The ability to call ./my-factor-script cmd sub-cmd --help.
> > > 
> > > _______________________________________________
> > > Factor-talk mailing list
> > > Fac...@li...
> > > https://lists.sourceforge.net/lists/listinfo/factor-talk
> 
> 
> 
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] command-line.parser but with commands?

[Zoltán K. <zo...@pr...>]

I made a mistake in the previous code, it does not print the unknown command. Both

> [ swap drop "Unknown command: " swap append print nl flush help flush 1 exit ]

and

> [ "Unknown command: " prepend print nl flush help flush 1 exit ]

prints it[1], although I am pretty sure there is a better way to achieve this. In fact, you could use "unclip" in other parts of the code, but this was just supposed to be a simple demonstration.

Additionally, you could create a helper word for "unknown command" if it looks not-so-desirable.

[1] Example output:

zolk3ri@void foo $ ./foo.out
Usage: foo [command]
Available commands:
  greet   - Print a greeting
  help    - Show this message
zolk3ri@void foo $ ./foo.out greet
Hello from Factor!
zolk3ri@void foo $ ./foo.out foo
Unknown command: foo

Usage: foo [command]
Available commands:
  greet   - Print a greeting
  help    - Show this message

Is this close to what you are trying to achieve?

On Sunday, July 6th, 2025 at 4:08 PM, Zoltán Kéri <zo...@pr...> wrote:

> I believe you are looking for something like this unless I am mistaken:
>
> USING: combinators command-line io kernel namespaces sequences ;
> IN: foo
>
> ! Help text
> : help ( -- )
> "Usage: foo [command]" print
> "Available commands:" print
> " greet - Print a greeting" print
> " help - Show this message" print ;
>
> ! Command: greet
> : greet ( -- )
> "Hello from Factor!" print ;
>
> ! Dispatch function: handles command and its arguments
> : dispatch ( cmd rest -- )
> {
> { "greet" [ drop greet ] }
> { "help" [ drop help ] }
> [ drop "Unknown command: " swap append print help ]
> } case ;
>
> ! Entry point
> : run ( -- )
> command-line get dup empty? [
> drop help
> ] [
> dup rest swap first dispatch
> ] if ;
>
> MAIN: run
>
> You can extend it to your liking.
>
> On Saturday, July 5th, 2025 at 9:34 PM, toastal to...@po... wrote:
>
> > > Are you trying to use something like a “sub command” feature?
> >
> > Yep. Like Cmdliner.
> >
> > https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html
> >
> > The ability to call ./my-factor-script cmd sub-cmd --help.
> >
> > _______________________________________________
> > Factor-talk mailing list
> > Fac...@li...
> > https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] command-line.parser but with commands?

[Zoltán K. <zo...@pr...>]

I believe you are looking for something like this unless I am mistaken:

USING: combinators command-line io kernel namespaces sequences ;
IN: foo

! Help text
: help ( -- )
    "Usage: foo [command]" print
    "Available commands:" print
    "  greet   - Print a greeting" print
    "  help    - Show this message" print ;

! Command: greet
: greet ( -- )
    "Hello from Factor!" print ;

! Dispatch function: handles command and its arguments
: dispatch ( cmd rest -- )
    {
        { "greet" [ drop greet ] }
        { "help"  [ drop help ] }
        [ drop "Unknown command: " swap append print help ]
    } case ;

! Entry point
: run ( -- )
    command-line get dup empty? [
        drop help
    ] [
        dup rest swap first dispatch
    ] if ;

MAIN: run

You can extend it to your liking.

On Saturday, July 5th, 2025 at 9:34 PM, toastal <to...@po...> wrote:

> > Are you trying to use something like a “sub command” feature?
> 
> 
> Yep. Like Cmdliner.
> 
> https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html
> 
> The ability to call ./my-factor-script cmd sub-cmd --help.
> 
> 
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] command-line.parser but with commands?

[toastal <to...@po...>]

> Are you trying to use something like a “sub command” feature?

Yep. Like Cmdliner.

https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html

The ability to call ./my-factor-script cmd sub-cmd --help.

Re: [Factor-talk] command-line.parser but with commands?

[John B. <mr...@gm...>]

Are you trying to use something like a “sub command” feature?

> On Jul 3, 2025, at 10:44 PM, toastal <to...@po...> wrote:
> 
> I have been trying to hack on command-line.parser to add the ability to
> call it with commands. I am too far out of my depth in both
> understanding how to debug the situation, but also it’s difficult to
> work with since all of the vocabs are used for the listener already it
> seems?
> 
> Ideally the API goal would be like OCaml’s Cmdliner Cmd
> <https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html>
> which is for CLIs that aren’t prompt-based, command-driven such as with
> Git, Pijul, & so on. Currently there is no ordering of arguments as you
> are either an option or positional, but command styles have recursive
> units that can nest other options / commands which could have their own
> help texts — where once a cmd type is found on in the set of commands
> from the argument sequence, the rest of the arg sequence should run
> (parse-arguments) on a new options for the command.
> 
> Some tools like Git & Pijul can dispatch out from a primary program to
> subprograms based on the name, but if start times are slow or executable
> sizes are big, this isn’t as preferred by users, which is probably the
> case for Factor — especially if using the interpreter as factor -run=foo
> bar baz --qux "quux" (would this then call factor -run=foo.bar baz --qux
> "quux" which then calls factor -run=foo.bar.baz --qux "quux"?).
> 
> What I intially tried was using -- to get the rest of the arguments, but
> aesthetically this isn’t ideal, but more importantly you would lose the
> ability to get help text for the subcommands. --help currently can
> *only* show the top-level help & it can’t be surpressed while all much
> of the API is hidden behind <PRIVATE> to try to assemble the pieces
> yourself. -- could also be assed to a prompt-based setup as input, like
> fdisk.
> 
> Is this a feature request, a call for help? I’m not entirely sure… 😅
> but it does seem the like a missing feature that could be tackled for
> UX as prompt-style CLIs have gone out of fashion & folks — my Fish
> session included — want shell completions without wrangling the state of
> a prompt (I have failed to set up a disk with fdisk on more than one
> occassion).
> 
> … Or should I just be doing my own argument parsing & avoid
> command-line.parser (recently moved from /extra to /basis) if it can’t
> fit my needs?
> 
> ---
> 
> I had written a single test as a goal:
> 
> CONSTANT: COMMANDS H{
>   { "add" H{
>      T{ option
>         { name "a" }
>         { #args 1 }
>         { type integer }
>      }
>   } }
>   { "subtract" H{
>      T{ option
>         { name "s" }
>         { #args 1 }
>         { type integer }
>      }
>   } }
> }
> 
> {
>    {
>        H{ { "cmd" { "add" H{ { "a" 1 } } } } }
>        H{ { "cmd" { "subtract" H{ { "s" 1 } } } }
>    }
> } [
>    {
>        T{ option { name "cmd" } { cmd COMMANDS } }
>    } {
>        { "add" "1" }
>        { "subtract" "2" }
>    } [ (parse-options) ] with map
> ] unit-test
> 
> As well the type I would assume…
> 
> TUPLE: option name type help variable cmd default convert
>    validate const required? meta #args ;
> 
> TUPLE: command name help options ;
> 
> But got stuck trying to figure out where / how get this in
> parse-arguments.
> 
> 
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] command-line.parser but with commands?

[toastal <to...@po...>]

I have been trying to hack on command-line.parser to add the ability to
call it with commands. I am too far out of my depth in both
understanding how to debug the situation, but also it’s difficult to
work with since all of the vocabs are used for the listener already it
seems?

Ideally the API goal would be like OCaml’s Cmdliner Cmd
<https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html>
which is for CLIs that aren’t prompt-based, command-driven such as with
Git, Pijul, & so on. Currently there is no ordering of arguments as you
are either an option or positional, but command styles have recursive
units that can nest other options / commands which could have their own
help texts — where once a cmd type is found on in the set of commands
from the argument sequence, the rest of the arg sequence should run
(parse-arguments) on a new options for the command.

Some tools like Git & Pijul can dispatch out from a primary program to
subprograms based on the name, but if start times are slow or executable
sizes are big, this isn’t as preferred by users, which is probably the
case for Factor — especially if using the interpreter as factor -run=foo
bar baz --qux "quux" (would this then call factor -run=foo.bar baz --qux
"quux" which then calls factor -run=foo.bar.baz --qux "quux"?).

What I intially tried was using -- to get the rest of the arguments, but
aesthetically this isn’t ideal, but more importantly you would lose the
ability to get help text for the subcommands. --help currently can
*only* show the top-level help & it can’t be surpressed while all much
of the API is hidden behind <PRIVATE> to try to assemble the pieces
yourself. -- could also be assed to a prompt-based setup as input, like
fdisk.

Is this a feature request, a call for help? I’m not entirely sure… 😅
but it does seem the like a missing feature that could be tackled for
UX as prompt-style CLIs have gone out of fashion & folks — my Fish
session included — want shell completions without wrangling the state of
a prompt (I have failed to set up a disk with fdisk on more than one
occassion).

… Or should I just be doing my own argument parsing & avoid
command-line.parser (recently moved from /extra to /basis) if it can’t
fit my needs?

---

I had written a single test as a goal:

CONSTANT: COMMANDS H{
   { "add" H{
      T{ option
         { name "a" }
         { #args 1 }
         { type integer }
      }
   } }
   { "subtract" H{
      T{ option
         { name "s" }
         { #args 1 }
         { type integer }
      }
   } }
}

{
    {
        H{ { "cmd" { "add" H{ { "a" 1 } } } } }
        H{ { "cmd" { "subtract" H{ { "s" 1 } } } }
    }
} [
    {
        T{ option { name "cmd" } { cmd COMMANDS } }
    } {
        { "add" "1" }
        { "subtract" "2" }
    } [ (parse-options) ] with map
] unit-test

As well the type I would assume…

TUPLE: option name type help variable cmd default convert
    validate const required? meta #args ;

TUPLE: command name help options ;

But got stuck trying to figure out where / how get this in
parse-arguments.

Re: [Factor-talk] Simulating linear types or resource tracking?

[toastal <to...@po...>]

> https://docs.factorcode.org/content/article-destructors.html
>
> …is more akin to the C++ use of destructors to free resources when a
> scope is exited.

Ah, ha! I believe this was the idea I was looking for & was assuming it
was gonna take an entirely different, non-type-level, approach which is
why I wasn’t even sure what I was needing to ask to look for this (no
C++ experience). :)

It’s a bit of a shame that “Factor” has such bad SEO-ability making it
difficult to ‘just’ search for the answer.

> I've used both Factor and ATS (both 1 and 2) … in my blog

Oh, I know. Those ATS blogs helped a lot in getting my head around
the basics. I rememeber the username distictly since there are almost no
resources outside official documentation & code examples. I got an itch
to try out concatenative programming — & was both surprised as well as
not surprised that BluishCoder was a featured writer on the Factor docs.
XD

Re: [Factor-talk] Simulating linear types or resource tracking?

[Chris D. <chr...@do...>]

For freeing resources automatically in Factor, take a look at destructors:

https://docs.factorcode.org/content/article-destructors.html

The approach is quite different to ATS and other typed systems and is more akin to the C++ use of destructors to free resources when a scope is exited.

I've used both Factor and ATS (both 1 and 2) quite a bit if you have any other questions. I've written about both in my blog:

https://bluishcoder.co.nz/tags/factor/
https://bluishcoder.co.nz/tags/ats/index.html

-- 
https://bluishcoder.co.nz

On Fri, Jun 13, 2025, at 9:23 PM, toastal wrote:
> Wanting to understand how safety is handled in Factor being an absolute
> concenative novice… Last year I went out to learn ATS2
> <https://www.cs.bu.edu/~hwxi/atslangweb/> in the ML family (those
> familar with OCaml or SML would be familar with the syntax). One of the
> standout features was linear types for safe resource tracking (closing
> file handles, always calling free, disallowing double free—where affine
> types only assert can be used at most once vs. linear types *must* be
> used exactly once). While the ATS2 language is a bit obtuse &
> unconventional, it felt very safe to use it due to explicit typing. For
> a ‘trivial’ example:
>
> ------------------------------------------------------------------------
>
> #include "share/atspre_define.hats"
> #include "share/atspre_staload.hats"
>
> implement main0 (): void = {
> 	(* allocate for an integer, returning a tuple with proofs for values
> 	& token for garbage collection | the pointer address *)
> 	val (pfval, pfgc | ptr) = ptr_alloc<int>()
>
> 	(* set pointer value to 42 (! is sugar to dereference @ address) *)
> 	val () = !ptr := 42
>
> 	(* get pointer value assiging to x *)
> 	val x = !ptr
>
> 	(* prints “x = 42” to console *)
> 	val () = println!("x = ", x)
>
> 	(* frees pointer using consuming both linear types *)
> 	val () = ptr_free(pfgc, pfval | ptr)
> }
>
> ------------------------------------------------------------------------
>
> If I skip the ``ptr_free(…)`` I will get a compiler error:
>
>> the linear dynamic variable [pfval$8389(-1)] needs to be consumed but
>> it is preserved with the type [S2Eat(S2Eapp(S2Ecst(g1int_int_t0ype);
>> S2Eextkind(atstype_int), S2Eintinf(42)),
>> S2Evar(l$14498$14499$14500(23073)))] instead.
>
> If duplicate the ``ptr_free(…)`` line, I will get this compiler error:
>
>> the linear dynamic variable [pfgc$8390(-1)] is no longer available.
>
> It’s a lot of manual code, but these linear types prevent leaks & enforce
> cleanup at the compiler level. These types are not limited to
> hardware-level resource tracking in the sense that you could use this to
> model in the type system of a game that you can’t unlock already
> unlocked door & unlocking a door consumes a key.
>
> I understand Factor does not have these sorts of types (almost no
> languages do) & is dynamically typed (ignoring ``TYPED:``), but I am
> curious, especially from the C FFI side of things where freeing is
> normally a manual/error-prone task, how would the Factor language, or
> concatenative languages in general, model resource tracking. Is there
> some sort of stack mechanism to sort of enforce cleanup or other
> contracts?
>
> — toastal
>
>
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Simulating linear types or resource tracking?

[George C. <geo...@gm...>]

I can't say about linear types, but I've dealt with types for concatenative
languages. There is an exceptionally good dissertation by Kleffner
https://repository.library.northeastern.edu/files/neu:4f186p17k/fulltext.pdf
It is useful to read Diggins' sketch before it
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=17e9322160dc1e26cc85bb26f8ef7b8a560cb07c
Factor has a rudimentary type check (stack effect check), it is done by the
'stack-checker' dictionary. The algorithm itself is taken from the Java
stack machine,
 so it does not always work (there are no quotations in Java). I thought
about rewriting it according to Kleffner, but it is built into the compiler
as the first stage,
 and part of the compiler needs to be rewritten along with it (I'm not
ready yet).

пт, 13 июн. 2025 г. в 12:24, toastal <to...@po...>:

> Wanting to understand how safety is handled in Factor being an absolute
> concenative novice… Last year I went out to learn ATS2
> <https://www.cs.bu.edu/~hwxi/atslangweb/> in the ML family (those
> familar with OCaml or SML would be familar with the syntax). One of the
> standout features was linear types for safe resource tracking (closing
> file handles, always calling free, disallowing double free—where affine
> types only assert can be used at most once vs. linear types *must* be
> used exactly once). While the ATS2 language is a bit obtuse &
> unconventional, it felt very safe to use it due to explicit typing. For
> a ‘trivial’ example:
>
> ------------------------------------------------------------------------
>
> #include "share/atspre_define.hats"
> #include "share/atspre_staload.hats"
>
> implement main0 (): void = {
>         (* allocate for an integer, returning a tuple with proofs for
> values
>         & token for garbage collection | the pointer address *)
>         val (pfval, pfgc | ptr) = ptr_alloc<int>()
>
>         (* set pointer value to 42 (! is sugar to dereference @ address) *)
>         val () = !ptr := 42
>
>         (* get pointer value assiging to x *)
>         val x = !ptr
>
>         (* prints “x = 42” to console *)
>         val () = println!("x = ", x)
>
>         (* frees pointer using consuming both linear types *)
>         val () = ptr_free(pfgc, pfval | ptr)
> }
>
> ------------------------------------------------------------------------
>
> If I skip the ``ptr_free(…)`` I will get a compiler error:
>
> > the linear dynamic variable [pfval$8389(-1)] needs to be consumed but
> > it is preserved with the type [S2Eat(S2Eapp(S2Ecst(g1int_int_t0ype);
> > S2Eextkind(atstype_int), S2Eintinf(42)),
> > S2Evar(l$14498$14499$14500(23073)))] instead.
>
> If duplicate the ``ptr_free(…)`` line, I will get this compiler error:
>
> > the linear dynamic variable [pfgc$8390(-1)] is no longer available.
>
> It’s a lot of manual code, but these linear types prevent leaks & enforce
> cleanup at the compiler level. These types are not limited to
> hardware-level resource tracking in the sense that you could use this to
> model in the type system of a game that you can’t unlock already
> unlocked door & unlocking a door consumes a key.
>
> I understand Factor does not have these sorts of types (almost no
> languages do) & is dynamically typed (ignoring ``TYPED:``), but I am
> curious, especially from the C FFI side of things where freeing is
> normally a manual/error-prone task, how would the Factor language, or
> concatenative languages in general, model resource tracking. Is there
> some sort of stack mechanism to sort of enforce cleanup or other
> contracts?
>
> — toastal
>
>
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>

[Factor-talk] Simulating linear types or resource tracking?

[toastal <to...@po...>]

Wanting to understand how safety is handled in Factor being an absolute
concenative novice… Last year I went out to learn ATS2
<https://www.cs.bu.edu/~hwxi/atslangweb/> in the ML family (those
familar with OCaml or SML would be familar with the syntax). One of the
standout features was linear types for safe resource tracking (closing
file handles, always calling free, disallowing double free—where affine
types only assert can be used at most once vs. linear types *must* be
used exactly once). While the ATS2 language is a bit obtuse &
unconventional, it felt very safe to use it due to explicit typing. For
a ‘trivial’ example:

------------------------------------------------------------------------

#include "share/atspre_define.hats"
#include "share/atspre_staload.hats"

implement main0 (): void = {
	(* allocate for an integer, returning a tuple with proofs for values
	& token for garbage collection | the pointer address *)
	val (pfval, pfgc | ptr) = ptr_alloc<int>()

	(* set pointer value to 42 (! is sugar to dereference @ address) *)
	val () = !ptr := 42

	(* get pointer value assiging to x *)
	val x = !ptr

	(* prints “x = 42” to console *)
	val () = println!("x = ", x)

	(* frees pointer using consuming both linear types *)
	val () = ptr_free(pfgc, pfval | ptr)
}

------------------------------------------------------------------------

If I skip the ``ptr_free(…)`` I will get a compiler error:

> the linear dynamic variable [pfval$8389(-1)] needs to be consumed but
> it is preserved with the type [S2Eat(S2Eapp(S2Ecst(g1int_int_t0ype);
> S2Eextkind(atstype_int), S2Eintinf(42)),
> S2Evar(l$14498$14499$14500(23073)))] instead.

If duplicate the ``ptr_free(…)`` line, I will get this compiler error:

> the linear dynamic variable [pfgc$8390(-1)] is no longer available.

It’s a lot of manual code, but these linear types prevent leaks & enforce
cleanup at the compiler level. These types are not limited to
hardware-level resource tracking in the sense that you could use this to
model in the type system of a game that you can’t unlock already
unlocked door & unlocking a door consumes a key.

I understand Factor does not have these sorts of types (almost no
languages do) & is dynamically typed (ignoring ``TYPED:``), but I am
curious, especially from the C FFI side of things where freeing is
normally a manual/error-prone task, how would the Factor language, or
concatenative languages in general, model resource tracking. Is there
some sort of stack mechanism to sort of enforce cleanup or other
contracts?

— toastal

Re: [Factor-talk] USB and NCurses

[toastal <to...@po...>]

> ncurses 

Not helpful from the Factor side, but it could be worthwhile to check
out notcurses <https://nick-black.com/dankwiki/index.php/Notcurses> in
2025 if you don’t already have ncurses bindings.

Re: [Factor-talk] USB and NCurses

[Chris D. <chr...@do...>]

I wrote some Factor code a long time ago to interface with a Z80 based MP3 played using USB, generator code and sending it to the device. That code would be woefully out of date now but it's certainly possible. I wrapped libusb using the Factor FFI to do the USB side of things. Here's a couple of posts I did on it:

https://bluishcoder.co.nz/2006/09/16/writing-your-own-mp3-player-firmware.html

https://bluishcoder.co.nz/2006/09/17/factor-code-to-upload-to-s1-mp3-player.html

I might have the code archived somewhere if you're interested.

On Mon, Apr 21, 2025, at 3:00 PM, Hugh Aguilar wrote:
> I did some programming in Factor a long time ago, but nothing 
> significant.
> What I want to do now is write a terminal program. I need access to USB 
> and also NCurses or some similar console-mode code-library (I don't 
> want to get involved with GUI). I have a Python program that was not 
> written by me, but it doesn't do what I want and it has no 
> documentation, and I don't want to learn Python (ugh!). I was going to 
> write my terminal program in GCC because I programmed in Turbo C back 
> in MS-DOS days, but I might go with Factor instead if I can get USB and 
> console-mode support.
>
> The purpose of all this is that I'm writing a Forth system for an 8-bit 
> microcontroller. The terminal program is supposed to be a front-end for 
> that. Back in the early 1990s I wrote a Forth cross-compiler for the 
> Laser-128 and my program running on MS-DOS had source-level 
> single-stepping and breakpoints, roughly comparable to Turbo Debugger 
> that I was familiar with for the 8086. The terminal program I want to 
> write now will have all of that, plus it will be the front-end for the 
> outer-interpreter of the Forth system on the microcontroller. 
>
> I'm running Windows-11. It would be good though, if I could get my 
> terminal program to run on Linux too.
>
> thanks for any help --- Hugh
>
>
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] USB and NCurses

[Hugh A. <hug...@gm...>]

I did some programming in Factor a long time ago, but nothing significant.
What I want to do now is write a terminal program. I need access to USB and
also NCurses or some similar console-mode code-library (I don't want to get
involved with GUI). I have a Python program that was not written by me, but
it doesn't do what I want and it has no documentation, and I don't want to
learn Python (ugh!). I was going to write my terminal program in GCC
because I programmed in Turbo C back in MS-DOS days, but I might go with
Factor instead if I can get USB and console-mode support.

The purpose of all this is that I'm writing a Forth system for an 8-bit
microcontroller. The terminal program is supposed to be a front-end for
that. Back in the early 1990s I wrote a Forth cross-compiler for the
Laser-128 and my program running on MS-DOS had source-level single-stepping
and breakpoints, roughly comparable to Turbo Debugger that I was familiar
with for the 8086. The terminal program I want to write now will have all
of that, plus it will be the front-end for the outer-interpreter of the
Forth system on the microcontroller.

I'm running Windows-11. It would be good though, if I could get my terminal
program to run on Linux too.

thanks for any help --- Hugh

Re: [Factor-talk] ARM compiler status

[toastal <to...@po...>]

> There is an ARM branch that gets a reasonable way towards
> bootstrapping that one of the Factor contributors is working on.

Is there a way to follow this progress more closely? The Gitweb / cgit
forge links at present return 404s, but the other forge has an
``arm-bootstrap`` branch with the last commit on 2021-03-29.

Re: [Factor-talk] ARM compiler status

[John B. <mr...@gm...>]

There is an ARM branch that gets a reasonable way towards bootstrapping that one of the Factor contributors is working on.

It isn't quite ready to compile programs fully, but hopefully will be part of our next release! I'm excited if it can be finished.

Thanks,
John.



> On Apr 4, 2025, at 4:22 AM, toastal <to...@po...> wrote:
> 
> I ran across this link online about an ARM compiler by a university.
> 
> https://www.hmc.edu/clinic/2024/an-arm-compiler-for-the-factor-programming-language/
> 
> It seems it was a course, but I don’t see anything about a follow-up on
> how it went. Does anyone know the status or goal of this project? I am
> assuming an ARM compiler goal doesn’t need the whole REPL coding
> environment — that it is just to be able to compile Factor programs to
> native ARM (which is what I would be interested in).
> 
> I can’t find any other relevant-to-the-last-decade information about ARM
> support for this language.
> 
> 
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] ARM compiler status

[toastal <to...@po...>]

I ran across this link online about an ARM compiler by a university.

https://www.hmc.edu/clinic/2024/an-arm-compiler-for-the-factor-programming-language/

It seems it was a course, but I don’t see anything about a follow-up on
how it went. Does anyone know the status or goal of this project? I am
assuming an ARM compiler goal doesn’t need the whole REPL coding
environment — that it is just to be able to compile Factor programs to
native ARM (which is what I would be interested in).

I can’t find any other relevant-to-the-last-decade information about ARM
support for this language.

Re: [Factor-talk] Make Factor great again

[George C. <geo...@gm...>]

Please check
https://github.com/George66/Factor

сб, 1 мар. 2025 г. в 23:22, John Benediktsson <mr...@gm...>:

> Probably nothing material, but typically when upgrading Factor for the
> deploy tool you need to delete your old staging images. They are not
> currently versioned.
>
> Run:
>
> delete-staging-images
>
>
> On Sat, Mar 1, 2025 at 12:20 PM George Cherevichenko <
> geo...@gm...> wrote:
>
>> John,  I checked all the UI examples, they work, but "deploy-tool" gives
>> an error message "Process exited with error code 1".
>> Did you change anything in "deploy-tool"?
>>
>> сб, 1 мар. 2025 г. в 22:15, John Benediktsson <mr...@gm...>:
>>
>>> This one?
>>>
>>
>>>
>>> https://docs.factorcode.org/content/word-rotation-matrix4,math.matrices.simd.html
>>>
>>>
>>> On Sat, Mar 1, 2025 at 11:12 AM George Cherevichenko <
>>> geo...@gm...> wrote:
>>>
>>>> Bad surprise. Try to run OpenGL examples with 0.100. "No word named
>>>> 'rotation-matrix4' found". I will temporarily close the repository. Where
>>>> did you put   'rotation-matrix4?
>>>>
>>>> сб, 1 мар. 2025 г. в 21:13, John Benediktsson <mr...@gm...>:
>>>>
>>>>> That should not be the case, we removed colors.constants in 0.100.
>>>>>
>>>>
>>>>>
>>>>>
>>>>> On Mar 1, 2025, at 10:08 AM, George Cherevichenko <
>>>>> geo...@gm...> wrote:
>>>>>
>>>>> To write "COLOR: blue" you need "USE: colors.constants" for Windows
>>>>> and "USE: colors" for Ubuntu. Surprise!
>>>>>
>>>>> сб, 1 мар. 2025 г. в 20:45, John Benediktsson <mr...@gm...>:
>>>>>
>>>>>> Hi George,
>>>>>>
>>>>>> I made that documentation fix.
>>>>>>
>>>>>> Separately, I'm curious about your examples are for "Ubuntu" and
>>>>>> "Windows".  What part of it makes it specific and not cross-platform?
>>>>>>
>>>>>> Thanks,
>>>>>> John.
>>>>>>
>>>>>>
>>>>>> On Mar 1, 2025, at 8:34 AM, John Benediktsson <mr...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>> Awesome!
>>>>>>
>>>>>> I will make that fix.
>>>>>>
>>>>>>
>>>>>> On Sat, Mar 1, 2025 at 8:33 AM George Cherevichenko <
>>>>>> geo...@gm...> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>> I wrote a set of examples.
>>>>>>> https://github.com/George66/Factor
>>>>>>> John, please correct  factor/basis/ui/gestures/gestures-docs.factor
>>>>>>> ARTICLE: "mouse-gestures" "Mouse gestures"
>>>>>>> As far as I understand
>>>>>>> "T{ button-down f 1 }"  and "T{ button-down f f }" are not suitable,
>>>>>>> .it must be
>>>>>>> "T{ button-down f f 1 }"  and "T{ button-down f f f }" ; see
>>>>>>> "button-down"
>>>>>>>
>>>>>>> George
>>>>>>> _______________________________________________
>>>>>>> Factor-talk mailing list
>>>>>>> Fac...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Factor-talk mailing list
>>>>>> Fac...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>>>
>>>>> _______________________________________________
>>>>> Factor-talk mailing list
>>>>> Fac...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Factor-talk mailing list
>>>>> Fac...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>>
>>>> _______________________________________________
>>>> Factor-talk mailing list
>>>> Fac...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>
>>> _______________________________________________
>>> Factor-talk mailing list
>>> Fac...@li...
>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>
>> _______________________________________________
>> Factor-talk mailing list
>> Fac...@li...
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>

Re: [Factor-talk] Make Factor great again

[John B. <mr...@gm...>]

Probably nothing material, but typically when upgrading Factor for the
deploy tool you need to delete your old staging images. They are not
currently versioned.

Run:

delete-staging-images


On Sat, Mar 1, 2025 at 12:20 PM George Cherevichenko <
geo...@gm...> wrote:

> John,  I checked all the UI examples, they work, but "deploy-tool" gives
> an error message "Process exited with error code 1".
> Did you change anything in "deploy-tool"?
>
> сб, 1 мар. 2025 г. в 22:15, John Benediktsson <mr...@gm...>:
>
>> This one?
>>
>
>>
>> https://docs.factorcode.org/content/word-rotation-matrix4,math.matrices.simd.html
>>
>>
>> On Sat, Mar 1, 2025 at 11:12 AM George Cherevichenko <
>> geo...@gm...> wrote:
>>
>>> Bad surprise. Try to run OpenGL examples with 0.100. "No word named
>>> 'rotation-matrix4' found". I will temporarily close the repository. Where
>>> did you put   'rotation-matrix4?
>>>
>>> сб, 1 мар. 2025 г. в 21:13, John Benediktsson <mr...@gm...>:
>>>
>>>> That should not be the case, we removed colors.constants in 0.100.
>>>>
>>>
>>>>
>>>>
>>>> On Mar 1, 2025, at 10:08 AM, George Cherevichenko <
>>>> geo...@gm...> wrote:
>>>>
>>>> To write "COLOR: blue" you need "USE: colors.constants" for Windows and
>>>> "USE: colors" for Ubuntu. Surprise!
>>>>
>>>> сб, 1 мар. 2025 г. в 20:45, John Benediktsson <mr...@gm...>:
>>>>
>>>>> Hi George,
>>>>>
>>>>> I made that documentation fix.
>>>>>
>>>>> Separately, I'm curious about your examples are for "Ubuntu" and
>>>>> "Windows".  What part of it makes it specific and not cross-platform?
>>>>>
>>>>> Thanks,
>>>>> John.
>>>>>
>>>>>
>>>>> On Mar 1, 2025, at 8:34 AM, John Benediktsson <mr...@gm...>
>>>>> wrote:
>>>>>
>>>>> Awesome!
>>>>>
>>>>> I will make that fix.
>>>>>
>>>>>
>>>>> On Sat, Mar 1, 2025 at 8:33 AM George Cherevichenko <
>>>>> geo...@gm...> wrote:
>>>>>
>>>>>> Hi
>>>>>> I wrote a set of examples.
>>>>>> https://github.com/George66/Factor
>>>>>> John, please correct  factor/basis/ui/gestures/gestures-docs.factor
>>>>>> ARTICLE: "mouse-gestures" "Mouse gestures"
>>>>>> As far as I understand
>>>>>> "T{ button-down f 1 }"  and "T{ button-down f f }" are not suitable,
>>>>>> .it must be
>>>>>> "T{ button-down f f 1 }"  and "T{ button-down f f f }" ; see
>>>>>> "button-down"
>>>>>>
>>>>>> George
>>>>>> _______________________________________________
>>>>>> Factor-talk mailing list
>>>>>> Fac...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Factor-talk mailing list
>>>>> Fac...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>>
>>>> _______________________________________________
>>>> Factor-talk mailing list
>>>> Fac...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>
>>>>
>>>> _______________________________________________
>>>> Factor-talk mailing list
>>>> Fac...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>
>>> _______________________________________________
>>> Factor-talk mailing list
>>> Fac...@li...
>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>
>> _______________________________________________
>> Factor-talk mailing list
>> Fac...@li...
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>

Re: [Factor-talk] Make Factor great again

[George C. <geo...@gm...>]

John,  I checked all the UI examples, they work, but "deploy-tool" gives an
error message "Process exited with error code 1".
Did you change anything in "deploy-tool"?

сб, 1 мар. 2025 г. в 22:15, John Benediktsson <mr...@gm...>:

> This one?
>
>
> https://docs.factorcode.org/content/word-rotation-matrix4,math.matrices.simd.html
>
>
> On Sat, Mar 1, 2025 at 11:12 AM George Cherevichenko <
> geo...@gm...> wrote:
>
>> Bad surprise. Try to run OpenGL examples with 0.100. "No word named
>> 'rotation-matrix4' found". I will temporarily close the repository. Where
>> did you put   'rotation-matrix4?
>>
>> сб, 1 мар. 2025 г. в 21:13, John Benediktsson <mr...@gm...>:
>>
>>> That should not be the case, we removed colors.constants in 0.100.
>>>
>>
>>>
>>>
>>> On Mar 1, 2025, at 10:08 AM, George Cherevichenko <
>>> geo...@gm...> wrote:
>>>
>>> To write "COLOR: blue" you need "USE: colors.constants" for Windows and
>>> "USE: colors" for Ubuntu. Surprise!
>>>
>>> сб, 1 мар. 2025 г. в 20:45, John Benediktsson <mr...@gm...>:
>>>
>>>> Hi George,
>>>>
>>>> I made that documentation fix.
>>>>
>>>> Separately, I'm curious about your examples are for "Ubuntu" and
>>>> "Windows".  What part of it makes it specific and not cross-platform?
>>>>
>>>> Thanks,
>>>> John.
>>>>
>>>>
>>>> On Mar 1, 2025, at 8:34 AM, John Benediktsson <mr...@gm...> wrote:
>>>>
>>>> Awesome!
>>>>
>>>> I will make that fix.
>>>>
>>>>
>>>> On Sat, Mar 1, 2025 at 8:33 AM George Cherevichenko <
>>>> geo...@gm...> wrote:
>>>>
>>>>> Hi
>>>>> I wrote a set of examples.
>>>>> https://github.com/George66/Factor
>>>>> John, please correct  factor/basis/ui/gestures/gestures-docs.factor
>>>>> ARTICLE: "mouse-gestures" "Mouse gestures"
>>>>> As far as I understand
>>>>> "T{ button-down f 1 }"  and "T{ button-down f f }" are not suitable,
>>>>> .it must be
>>>>> "T{ button-down f f 1 }"  and "T{ button-down f f f }" ; see
>>>>> "button-down"
>>>>>
>>>>> George
>>>>> _______________________________________________
>>>>> Factor-talk mailing list
>>>>> Fac...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>>
>>>>
>>>> _______________________________________________
>>>> Factor-talk mailing list
>>>> Fac...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>>
>>> _______________________________________________
>>> Factor-talk mailing list
>>> Fac...@li...
>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>
>>>
>>> _______________________________________________
>>> Factor-talk mailing list
>>> Fac...@li...
>>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>>
>> _______________________________________________
>> Factor-talk mailing list
>> Fac...@li...
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
> _______________________________________________
> Factor-talk mailing list
> Fac...@li...
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>