FYI,

Circumstances had it that I stopped doing much of anything related to Muldis D back around 2010 November. However, within a week or so I expect to resume the evolution of that language, and subsequently its implementation.

This next round of updates will focus on streamlining the language so that unnecessary complexity is refactored and the language spec can become smaller, without actually losing any useful features. That is, I now consider the language feature-complete, more or less (since the Summer of 2010), and I'm now focusing on making it easier to use or implement, getting rid of unnecessary restrictions, and making the syntax less verbose.

The first step will involve consolidating 3 of the 4 main routine types into 1, so that then there will just be "function" and "procedure"; the current "updater" and "recipe" will be consolidated into the latter (but the concepts will still exist as special cases of "procedure"); "function" will remain essentially unchanged in this step. After the change, "function" will be a pure deterministic routine that is always invoked as part of a value expression, while "procedure" will be a routine that is always invoked as an imperative statement. The largest difference from the old "procedure" is that arbitrary value expressions can exist directly in procedures, rather than having to be factored out into separate routines. After this change, writing code will be an experience more like in other languages which don't have the seemingly-arbitrary restrictions that I have prior to the consolidation.

I won't declare further evolution plans now, but bring them up as they happen or become imminent.

-- Darren Duncan
_______________________________________________
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users

Reply via email to