FYI,
As an update, I've had more brainstorming, and my current plan is to start
active implementation work next week.
I will also be switching into a somewhat implementation-driven mode, as at this
point it would seem to be easier to start actually implementing the ideas and
then have spec changes trail that to help explain what I did.
To be specific, I'll be starting by writing the Muldis D system libraries, the
declarations and implementations of the system-defined types and routines, these
being written in Muldis D themselves. So the language itself will be the first
major codebase written in the language. And I'd update the grammar in parallel.
Doing that will help me to quickly hash out and consolidate ideas for what
syntax the language has and what built-in types and operators there are. And
sometimes working code is the most concrete description of the intended
semantics of the types or operators etc.
I should also say that the way I'm going, Muldis D will start out more
resembling a general purpose language, in that all the implemented features will
be in-memory, and there won't be a persisting database to start with. We'll
have all the relation and tuple types and relational operators etc, but the
tuples and relations will be in-memory values in the same way as integers and
strings and arrays in typical languages. The persistence is largely orthogonal
to this anyway, and I'll be adding that in the following few months.
-- Darren Duncan
_______________________________________________
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
