proj-oot-ootSyntaxNotes11

~ h3rald 20 hours ago (unread)

Ohhh! Another concatenative programming language! I am fascinated by the concatenative paradigm and I ended up created my own little language, too (min).

One thing I noticed is that I thought I wanted to be minimalist (hence the name) I ended up adding a lot of stuff to it, like regular expressions, dictionaries, cryptography, network and HTTP support… and that gets complicated real quick. But I was able to use it to build more complex application with it, and use it as a backend for some web apps, too.

For the record, I also forked my own language and created mn, which is very similar to dt, as it has a more limited feature set focused on shell programming.

What are you planning for dt? Any plan to implement more concatenative combinators? I checked the standard library and I noticed that apart form the common things like swap, dup, etc. you didn’t implement the more exotic ones that Joy provides like linrec or similar.

The problem with concatenative languages is that they tend to get pretty much unreadable and difficult to debug really quick. I tried to address this in min in different ways, from encouraging the usage of variables to more elaborate constructs for defining new symbols in a more standard way, added some type checking… but that bloated the language.

My advice: keep it small and focused! Oh, and get it added on concatenative.org ;)

    ~
    WilhelmVonWeiner 17 hours ago (unread) | link | flag | 

In my experience this is where Forth and concatenative languages in general diverge. If your Forth is getting unreadable you’re writing words that are too long or doing too much, and using more than one or maybe two variables is a sign that you’re trying to do too much because you could be taking better advantage of the stack. But with concatenative languages, coming from a more theoretical background, love scoping, using functional data structures etc. and these layers of complexity remove the simplicity and accessibility of Forth, necessitating these longer word definitions, necessitating complexity.

    ~
    booniepepper 5 hours ago (unread) | link | flag | 

I agree in general that too-long definitions are a code smell in concatenative languages, and I think Forth folks are correct to insist on many short definitions in this paradigm.

I think with concatenative languages, (also array languages like APL) you have to measure complexity in terms of “words” instead of like other paradigms. Also you have to think about things like “phrasing” or “chording” and grouping words together in a way that’s hard to explain except by “feel.” In other languages you’d make similar measurements but in terms “lines” or “cyclomatic complexity” (layers of nesting) and vertically break up lines into chunks in a similar way that Forth devs will break up words horizontally. But… maybe we just have not yet seen the right IDE experience yet that makes it all more clear what’s going on!

(Side note: dt needs an idea of hiding information in modules… and also needs modules! But maybe this is just a documentation problem - it’s possible even in current restraints with just getting scoping figured out)

~ booniepepper 5 hours ago (unread)

Hey min and mn were inspirations! Thanks for chiming in

    What are you planning for dt?

The goals are to be easy-to-grok, useful, and performant, primarily in the context of Unix-style pipes. For me that means if there’s some obvious other thing for network calls (curl, wget) then my philosophy should be … just pipe into those! It’s very much intended to be duct tape for patching small holes, not exactly a batteries-included do-anything machine. I think at this point that does mean small and focused.

If people like the experience of concatenative languages then I’d be happy if dt is just the gateway to other languages like Forth, Factor, min, Kitten, PostScript? or GhostScript?, and many others, which are all capable of building general purpose software. I’m exploring the idea of a bigger general purpose concatenative language or VM, but it would not be dt.

    Any plan to implement more concatenative combinators?

I don’t think as part of the core language. The easy-to-grok idea is part of why I have variable binding fairly prominent. I have played with some more exotic combinators (See: joy-combinators.dt) but I don’t think these are very accessible – I might get them into dt anyway, but make them opt-in and require some kind of “include” or something that I haven’t implemented yet.

---

https://eighty-twenty.org/2019/07/21/indentation-syntax-for-racket

---

shunting yard vs pratt parsing

[1] https://www.google.com/search?q=shunting%20yard%20vs%20pratt%20parsing%20benchmark https://www.oilshell.org/blog/2017/03/30.html

---

demondemidi 1 hour ago

There was a brief period of schools teaching Java compiling down to CLI programs in Unix (beans?). Perl was popular on the semiconductor world replacing tcl for gluing together complex manufacturing flows. Ruby was heading to be a replacement for Perl with bidirectional file handles and similar syntax. Shell scrips and Perl are still on use there. Python never made inroads because it brought nothing new and was less suited to file munging than Perl. Perl still has superior text manipulation semantics compared to python.

reply

jandrewrogers 1 hour ago

Text manipulation was Perl’s raison d’être, it was exceptional at it. The real legacy of Perl is how pervasive its text manipulation concepts have become in other software. That was what made it work so well in the early days of the Web: everything Web was text-based.

Perl would probably still have a place at the table if Perl 6 hadn’t turned into a debacle over an astonishing number of years.

reply

---

most of the blog post is about how flat function calls with literal arguments is better for interactive commandlines (not necessarily program code), but it also mentions how it's inefficient that () are used instead of [] for the common case, and how [1,2,3] is harder to type than [1 2 3] for literals "And don't get me started about further wrapping the vector literal for Numeric Python."

https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html

---

" Perl has strong support for that: https://perldoc.perl.org/perlop#Quote-Like-Operators

You can basically use any character as a delimiter except whitespace.

All of these lines are equivalent:

    $str = 'Hello, world.';
    $str = q{Hello, world.};
    $str = q[Hello, world.];
    $str = q(Hello, world.);
    $str = q<Hello, world.>;
    $str = q|Hello, world.|;
    $str = q!Hello, world.!;
    $str = q#Hello, world.#;
    $str = q%Hello, world.%;
    $str = q=Hello, world.=;" -- https://news.ycombinator.com/item?id=35829911

---

hoosieree 4 months ago

The fact that I learned Tcl because of Vivado is probably why I don't like it. I'll probably never like it, but I can at least admit it has some nice features that make sense for an embedded scripting language.

But I've never seen anything more vile[0] than Cadence's "Ocean" scripting language[1]. It has such contempt for the user. For example, when learning you might notice

    command(

is ok but

    command (

is a syntax error. You then might conclude that the language is trying to be strict and help you write correct programs. But then you realize that

    "]

is magic syntax which closes all previous strings, and it just gets worse from there.

[0]: except satirical/joke languages

[1]: https://www.eecis.udel.edu/~vsaxena/courses/ece697A/docs/OCE...

dfox 4 months ago

That is because SKILL is really an scheme under the hood. And somebody had the bright idea of making the syntax more "user friendly" (read: more like C) by inventing a rule that "foo(bar)" parses as "(foo bar)" while "foo (bar)" parses as "foo (bar)". IIRC there also is another similar rule for when expression is parsed as infix.

Right bracket with the meaning of close all was used in some lisps because somebody did not like the long runs of closing parens at the end of definitions.

hoosieree 4 months ago

Yup. Ease at the cost of simplicity comes at the cost of ease.

---

some syntax for constraints: https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/Weiher_2020_CanProgrammersEscapeTheGentleTyrannyOfCallReturn_AcmDL.pdf

:= for one-way propagation of constraints and =:= for symmetric propagation of constraints

---

https://j3s.sh/thought/shell-tip-print-json-with-printf.html

---

" In the discussion on his own post, Graydon had commented, “Just don’t get me started on angle brackets for type parameters and the single apostrophe for lifetimes!”

One Reddit user insisted on following up. Hoare clarified that “they were just syntax arguments I was on the losing side of.” And he even supplied a link to his “Rust prehistory” GitHub? repository, showing 13-year-old Rust code where square brackets had actually been implemented for type parameters, adding that “I personally think square brackets are the obvious choice for type parameters.” "

---

some good conventions here, we should do similar stuff in Oot:

https://nullprogram.com/blog/2023/10/08/

---