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