Welcome to Boba Discussions!

[robertkleffner]

👋 Welcome!

We’re using Discussions as a place to gather early feedback about the design of Boba. Please use this area to:

• Ask questions about Boba itself, the development timeline, or other things related to Boba and concatenative programming.
• Share language feature ideas. The roadmap for the first release of Boba is fairly fleshed out, but many smaller design decisions can (and will) be changed.
• Provide feedback on early usage, both wins and problems.

To get started, comment below with an introduction of yourself and tell us about your interest in concatenative programming, or Boba in particular!

[SIMPalaxy]

Hey, I'm implementing a type checker for a stack calculus and I found the implementation of Boba to be very readable (gotta love F#) and really helpful. So I just wanted to say thanks for that :)

How long have you been working on this? I know about and have read your HOPL presentation notes and dissertation, and checked out Wort in Racket, but I had no idea you were still working on concatenatives (doesn't appear pinned on your github profile so I had no idea.)

[SIMPalaxy]

It's a fairly long story, but the short version is I was interested in interactive programming environments and an idea that I later discovered is a kind of intersection of dependent typing, single-arity functional programming (and unary predicate logic), and tacit programming (I knew of neither at the time I first started thinking about it.) One thing lead to another and I discovered Forth and later Joy while exploring both tacit programming and single-arity programming.

Essentially my conjecture is that the main reason "visual" programming languages/more directly interactive, non-textual programming environments generally aren't very good is trying to adapt variables from conventional languages, ending up with global variable spaghetti, which turns into node spaghetti. Also if the means of combination in a programming system is dependent on name binding, the iconographic nature of live visual interaction, like the kind you have playing a videogame or sim isn't really used to it's fullest potential. So naturally I was interested in the homoiconicity of both Lisps and Forths.

Concatenatives using juxtaposition as a representation of combination is actually something that was present in my original idea for the visual environment, although mine did pairs all the way down the pairs were juxtaposed and could be abstracted from to allow for higher-level representation of the tacit ast structure. But once I realized it was possible to have an associative language, it was immediately clear that would serve the design goals even better, even if I will use a kind of CPS-heavy style for the environment like Forman's Thun.

The last great property that made me interested in concatenatives, beyond their own inherent merits/intrigue, is the typing synthesis, which opens up a lot of potential for making the programming environment both powerful and extensible (intellisense on steroids, you can imagine autocomplete for a type-directed version of Factor's parsing words, but obviously not word-based, instead using types.)

[robertkleffner]

Essentially my conjecture is that the main reason "visual" programming languages/more directly interactive, non-textual programming environments generally aren't very good is trying to adapt variables from conventional languages, ending up with global variable spaghetti, which turns into node spaghetti.

This is one of my key complaints with visual languages as well. Oddly enough one of my complaints with point-free concatenative style is the inverse: having lots of stack shuffle combinators obfuscates what the function is trying to do. And perhaps a visual concatenative language could cut down on shuffle combinators thanks to an extra dimension?

The last great property that made me interested in concatenatives, beyond their own inherent merits/intrigue, is the typing synthesis

Hopefully Boba will have something to contribute in this regard. Currently the type inference is not hooked up to the rest of the compiler, but much of it is behind a test suite and thus more ready to go than other parts of the implementation. Adding expressive types to concatenative languages and using them to advance clarity, trust, and readability of programs is something that excites me.

It sounds like you might be more familiar with the existing concatenative space than I am; my history is mostly from the functional side, so I know what I love about those languages and also what I wish they had. So the current design of Boba resembles a bridge from functional to concatenative, that is, I haven't eschewed variables the way many concatenaters would probably prefer. But I do remain committed to avoiding any infix operators for the moment.

I hope you'll continue to follow the development of Boba! And if you publicize a concatenative/visual language combination I'll be happy to take a look.

[SIMPalaxy]

Yeah, I guess the thing with variables is that they're the means of abstraction, (as opposed to means of combination, which is one of the proposed "ingredients" for an expressive language laid out in SICP, with Lisp being the example) but when the medium changes, the most suitable candidate for those means may change.

I really like ML-s which oftentimes have lots of essentially point-free features which work seamlessly with the non point-free basis (both composition and threading/piping) and being able to choose between them. It's what's really great about F#, even introducing state if that's the thing that simplifies code, including as a stateful computation expression returning some array literal, for instance. In a lot of ways, essentially I see ML-with-stacks as ideal, which seems to be what Boba is going for, and Mirth is something close to what I want as a systems programmer, which is ATS' extensions to ML with dependent types and linear types for resource management.

What concatenatives have that is unique from MLs is the factorability/associativity, (in some sense, what makes a language a language specific to a domain is where you decide to not repeat yourself, which words you define. Generally that will be influenced directly by the recurring patterns in that domain.) It has a way of bringing both the functional and imperatives styles together in a really fantastic way. As the Forman guy (who's working on Thun) said, Joy is probably the simplest useful language.

Even if you can construct non-associative things at a higher level, like implementing local variables and other scoping mechanisms, or something like a BNF grammar parser in Factor (a functional language) the fundamental basis being associative is a really important property. Notably, Factor can manipulate symbols/tokens just fine with those parsing words, but they're not variables which is a more specific concept. But you can build in variables by binding those symbols, as you would in Lisp. But if you don't they're just data.

Oddly enough one of my complaints with point-free concatenative style is the inverse: having lots of stack shuffle combinators obfuscates what the function is trying to do. And perhaps a visual concatenative language could cut down on shuffle combinators thanks to an extra dimension?

I'm not actually opposed to variables existing at all, but them being integral to the abstract model is something I don't think plays very nicely with visualizations, however when you're working in a non-text medium, you can just as easily imagine something like programmable representation which actually does look like nodes between two stacks that shows how something like dup as two nodes from one item on the first stack to two items on the other stack. The idea is more that the visual system uses stack types as a intermediate language and "backend" to the visual component's "frontend." So if you view ML-with-stacks (and thus with variable bindings) as a domain specific language one can create within a stack language using an abstraction algorithm, one among many other languages you could encode within the system, that would be ideal.

I don't know exactly how Boba does it, but ostensibly you use an abstraction algorithm to convert to regular stack combinators behind the scenes.

Although, the utility of doing that when you're doing regular visual nesting with CPS as I am is unclear. You can imagine boxes within other boxes and boxes moving into other boxes, so dup isn't (necessarily) represented by a lambda term, but it isn't represented by the word dup either. Something like how a let binding/lambda uses occurrences of the variable would be reflected in the representation, however the model doesn't include some name environment to express computation, just the combinators (in this sense, I am more interested in combinatory logic over lambda calculus as a basis for computation because alpha substitution is effectively superfluous, and needlessly complicates the logic that the computer should be doing, but lambdas, railroad diagrams, etc are all perfectly reasonable domain-specific representations, suited to different problems)

Further the need for "definitions" as something reified into the program is unclear if you're not bound to text at all, you just save chunks of code, like a Factorio or Minecraft hotbar of composed functions/words, and the computer can even solve for slight changes to the code to do things like stack shuffling for you (if your function takes and int and float off the stack, it can reorder them for you while keeping the logic factored separately, like essentially automatically filling in a "typed hole" like you might see in Hazel.)

If this tone is coming off as at all critical of Boba, I want to be clear I mean the opposite, that Boba is something very close to "ML-with-stacks" which I really like and find ideal given what one is developing is, indeed, a textual programming language. The ML-style function definition etc where "definitions" and "functions" look the same is definitely superior. And instead of piping and composition being separate concepts that are similar, here, composition is expressed through normal concatenative-style juxtaposition instead of needing >> or |> or a myriad of other symbols, made possible by using a stack type instead of normal HM inference.

But the baking in of variables into the computational model if you're doing a flexible visual environment/structure editor that acts as more of a engine for doing design and exploration is definitely the wrong choice, even if they're totally native to the text format. (You'll note I generally avoid the term "language" to describe the environment for that reason.)

[SIMPalaxy]

I hope you'll continue to follow the development of Boba! And if you publicize a concatenative/visual language combination I'll be happy to take a look.

I would love that! Seriously, your work, both articles and code, has been very helpful and your interest in the project means a lot.

[robertkleffner]

What concatenatives have that is unique from MLs is the factorability/associativity, (in some sense, what makes a language a language specific to a domain is where you decide to not repeat yourself, which words you define. Generally that will be influenced directly by the recurring patterns in that domain.) It has a way of bringing both the functional and imperatives styles together in a really fantastic way. As the Forman guy (who's working on Thun) said, Joy is probably the simplest useful language.

Totally agreed, which is why my fascination with the concatenative style continues to motivate my work to this day. It really feels like there's something there which is worthy of a broader audience's attention.

I'm not actually opposed to variables existing at all, but them being integral to the abstract model is something I don't think plays very nicely with visualizations

Definitely in agreement here as well! I think there's a great deal of promise in visual concatenative languages to eliminate a lot of the normal textual 'noise' you find in reading programs.

I don't know exactly how Boba does it, but ostensibly you use an abstraction algorithm to convert to regular stack combinators behind the scenes.

Hmm, not yet, but I definitely think that's possible with an advanced compiler setup. Because some higher-order Boba functions can be polymorphic with regard to the stack, it was easiest for me to separate the value stack from the call-frame/variable stack. I also needed a way to separate effect handlers (which are implemented in Boba right now as delimited continuations), so those also reside in a call-frame stack. And each call-frame stores an array of variables, and behaves similarly to how call-frames in C or other procedural languages do. There's probably lots of optimizations that could be made here, I just threw that together because it was the simplest way I could get effect handlers to do what I wanted.

But the baking in of variables into the computational model if you're doing a flexible visual environment/structure editor that acts as more of a engine for doing design and exploration is definitely the wrong choice, even if they're totally native to the text format.

Yeah, that makes sense. I wonder if the lack of variables in a visual language makes advanced types any easier. For instance, with uniqueness types, the type inference is first driven by a 'sharing analysis' which can be a bit subtle. But with no variables that entire step could be skipped. Maybe that extends into other areas of type checking/inference for visual languages as well.

I would love that! Seriously, your work, both articles and code, has been very helpful and your interest in the project means a lot.

Thank you again! I am always surprised that it gets read every now and then, I'm glad it's been of service!

[Garklein]

Hi, I first encountered Forth about 8 months ago. I liked how simple it was, but I never got around to properly learning it or making anything.
A while later, I found some stack-based languages in the r/PL server. Remembering Forth, I checked them out, and discovered Joy. These languages, and simp above, brought me here.
I would like to invite you to join the Mlatu Discord server, where Mlatu, Gerku, and concatenative languages in general are discussed: https://discord.gg/nty7EFG2

[robertkleffner]

Thanks for the invite! Mlatu community looks like a lot of fun.