New DCI programing language (POC)

[Matthew Browne]

Hi all,
I have created a prototype of a new language for DCI programming, forked from Kotlin (it's still a work-in-progress). I'm sure there are many different opinions in this group about where and how much to rely on AI, but I think we could all agree that it's very useful for prototyping, which is what I did here (I haven't even reviewed the code yet). Having said that, obviously I would not recommend using this language in production, but my hope is that one day it could be built more robustly and become suitable for production.

I'm calling the language "Menta", short for mental models:

https://github.com/mbrowne/menta

See some examples:

https://github.com/mbrowne/menta/tree/main/docs/examples

And try it out here:
https://codesandbox.io/p/devbox/menta-demo-54hjfz

(It seems that you have to fork the sandbox before you can run your own commands in the terminal...if anyone knows otherwise, please let me know.)

For documentation, see the main readme, differences from Kotlin, and FAQ.

The main reason I chose Kotlin was for the compiler infrastructure, libraries, and all the targets it already supports. I haven't tried building a GUI with it yet, but thanks to Kotlin Multiplatform, in theory it should be possible to write a GUI app that works on desktop, web (both JS and web assembly), Android, and iOS (via Kotlin native). Working with native libraries via Kotlin native is also possible.

Here are some highlights:

1. The language basically implements the "everything is a Context" idea that Rune and others have discussed on this list, except that I chose the keyword define rather than context, and I only consider an object to be a Context if it has roles. But there's no separation between "classes" and "contexts"—I completely removed the "class" keyword.
   
   
2. I think this is a good language for research and experimenting with the intersection of DCI and functional programming. I was able to create a version of the frontloading example that avoids mutating any objects for the front-loading algorithm.
   
   
3. It borrows from Kotlin's existing syntax for mehtod/property-acccess forwarding to make it easy to implement generalization/specialization without inheritance, as explained here, and this works for Contexts too.

Some to-do items and open areas of investigation:

1. It currently lacks an equivalent of the "stage props" in trygve. I'm interested in learning more about exactly how stage props work behind the scenes to see what can be done in Menta.
   
   
2. There's no IDE support yet, but given the good IDE support that already exists for Kotlin, I don't think it will be too difficult to add (and I plan on adding it).
   
   
3. Kotlin's type system is based on nominal typing, and it doesn't natively support duck typing. So I stuck with nominal typing for now, which means you have to define an interface and your role-playing objects must implement that interface in their definitions. It occurred to me that this might actually be more secure, since duck typing doesn't provide as strong guarantees, but it could also be overkill and inconvenient in a lot of cases, and potentially encourage the use of interfaces with more methods than are really needed to play the roles. So I'm thinking that maybe there should be a compiler option to either allow or forbid duck typing for role-object contracts.
   
   
4. There are still classes behind the scenes in the intermediate representation (IR) and of course in the JVM bytecode. I'm not sure if there's really a good reason to eliminate these behind-the-scenes classes, but in theory if some alternative object template mechanism were preferred, the IR could be changed, and the native backend could be changed to support anything that LLVM supports. I think the compatibility with Kotlin's IR is a nice feature though.
   
   
5. I'd like to add a feature for transitive immutability.

The only thing I feel strongly about maintaining from Kotlin is support for JVM as a target, but I was focused mainly on OO and DCI and I didn't feel much need to touch the rest of the language, which has some pretty nice functional programming features for example. But if anyone has suggestions on something inherited from Kotlin that should really be changed, let me know.

Let me know what you think!

Thanks,
Matt

[Lund Soltoft]

Nice to see Matt, made me think of me also having something to share but I will start another thread for that. 

I (of course) love that you've taken the "everything as a context" approach

- Rune

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/object-composition/7348306f-ff4d-4d42-980b-9b40bc0d7ef3%40gmail.com.

[Matthew Browne]

A small specific question for the group: any opinions on whether or not I should rename 'public' to 'pub'?

It's commonly pointed out that code is read more than it's written, and with IDEs these days and especially AI coding agents, the length of keywords seems to be less relevant. But at least currently, it's usually necessary for programmers do in-depth code reviews, and since I changed Kotlin's policy of public-by-default, this means there will be a lot of 'public's sprinkled everywhere, and I'm wondering if that would be distracting or if avoiding abbreviation is actually helpful.

Another thing I was wondering about in terms of syntax is the order of modifiers for 'define'. Kotlin has 'class', 'data class', 'enum class', etc., which in Menta are currently 'data define' and 'enum define'. Would these read more naturally as 'define data' and 'define enum'? Dynamic objects are a new feature, so I used 'define dynamic' for that...whichever option I go with, I assume it would be best to be consistent.

Thanks,

Matt

To view this discussion visit https://groups.google.com/d/msgid/object-composition/CAGLi4Wg82vYpGW%3DkYP0HsuiLBHJg76zKvkN00wg7NxSqJd6ruA%40mail.gmail.com.

[James Coplien]

On 25 May 2026, at 12.52, Matthew Browne <mbro...@gmail.com> wrote:

A small specific question for the group: any opinions on whether or not I should rename 'public' to 'pub’?

 

no

[Matthew Browne]

Lol

--

You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/C1ED86F0-1303-4840-8CE1-287DB010767E%40yahoo.com.

[Benjamin Scherrey]

Agree the correct answer is no. public sounds like a reserved keyword. pub could be a lot of things.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/CAJA9FQ98FSqtq-BOHe3jrPzVPKgbrk7c3eMm%2Bga45B4Bzin%2B%2Bw%40mail.gmail.com.

[Matthew Browne]

Thanks, that's a good point. (It's 'pub' in Rust, which is what got me thinking about it.)

I was laughing because I thought Cope was just saying, "no opinion" :-)

To view this discussion visit https://groups.google.com/d/msgid/object-composition/CABP0uib1TdjynT7%2BQA8yyV2pKyVLa5HMqswiEZUafDE6B28R4g%40mail.gmail.com.