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.