NAME
Language::MuldisD::Hierarchical - Terse Muldis D dialect for daily work
VERSION
This document is Language::MuldisD::Hierarchical version 0.0.0.
PREFACE
This document is part of the Muldis D language specification, whose root document is Language::MuldisD; you should read that root document before you read this one, which provides subservient details.
DESCRIPTION
The fundamental way to write Muldis D code is to compose appropriately typed tuple and/or relation valued expressions which are then stored in the Muldis D system catalog relvars, whereupon it becomes invokable. If you had Muldis D code that was generating other Muldis D code at runtime, such as you do with string-eval in Perl or you do with "prepared statements" in SQL, then this process is what that first Muldis D code is actually doing.
If you were taking the bare-bones Muldis D syntax defined in either Language::MuldisD::Grammar or Language::MuldisD::PerlHosted, along with the system-built-in data types and routines defined in Language::MuldisD::Core, and using just those instructions to write your own Muldis D code, you would essentially be working to the metal, and your code would be very verbose by typical programming conventions. For now lets call this writing in the Relational Muldis D dialect, since the code is composed entirely of tuple|relation definitions.
This document specifies another Muldis D dialect, which for now we will call the Hierarchical Muldis D dialect. Moreover, although its principles could be generalized, for now the details of this document are specific to the dialect's use in Muldis D as hosted in either Perl 5 or Perl 6, such as PerlHosted describes. So the relational Perl-hosted dialect will be referred to herein as PHMD-R, and the hierarchical Perl-hosted dialect will be PHMD-H.
This document is very much an early draft, and for not just contains a bit of brainstorming in point form.
HIERARCHICAL MULDIS D DIALECT
PHMD-H code, like PHMD-R code, is fundamentally expressed as a tree of Perl Array that also comprises some Perl Hash; the tree root is a Perl Array.
Literals of system-defined core scalar types (such as numbers and strings) are expressed in the same way for both PHMD-H and PHMD-R, as simple Perl Seq|Array values of 2-4 elements; see PerlHosted for details. This then retains all the meta-data necessary to unambiguously interpret the scalar values where Perl may be more weakly typed itself.
A PHMD-H expression tree is generally expressed as an actual tree of node definitions, and those nodes don't need to be named; contrast with PHMD-R where the nodes are defined in a flat list and are all named. But PHMD-H still supports disassembly into multiple named sub-trees, such as when part of an expression is intended to be used multiple times, as per a generalization of a named item in a SQL "WITH" clause. Having actual N-depth expression trees makes the Muldis D code much more strongly resemble expression trees in most typical high-level languages, as well as how humans typically write their math and logic outside of computers.
A PHMD-H expression node does not include deadweight node attributes like in PHMD-R, because it isn't restricted to making every node of the same complete tuple data type. This leads to a drastic reduction in code size.
PHMD-H has a much larger grammar than PHMD-R does. Speaking in analogy, its alphabet has 100 characters rather than 10, so you can express all the possible ideas using a smaller number of characters. Speaking not in analogy, PHMD-H has orders of magnitude more PHMD node types than PHMD-R does; so for example, it has separate function|procedure node types for declaring a function|procedure, rather than a generic Tuple node type being used for that; or each kind of value expression (eg, a literal vs a parameter use vs a function call) each has a different short PHMD node for it, rather than 1 kind subsuming them all.
PHMD-H permits abbreviations of name-chains for invoking types or routines et al when said entities are system-defined; generally speaking, any sys.Core. prefix can be omitted where applicable; often so can the package name as well. This does not apply to user-defined entities; however it is less needed there since there are several levels of localizing top-level namespaces for user-defined entities already, such as pkg or inn. The reason for this selective applicability is because the entity names should all be resolvable at compile time, and moreover any routine et al should be compilable in isolation from any others.
PHMD-H provides a bunch of alternate spellings for various system-defined operators, as aliases; in particular, many symbolic-character aliases. So for example, '=' is provided as an alias for 'is_equal', and '<' an alias for 'is_ascending', and '*' as an alias for 'Int.product', and so-forth.
PHMD-H provides positional-argument syntax aliases for system-defined routines, so they can be invoked without argument names. This does not apply to user-defined routines. A routine must be compilable in isolation to named-argument syntax.
Other details to come, stay tuned!
SEE ALSO
Go to Language::MuldisD for the majority of distribution-internal references, and Language::MuldisD::SeeAlso for the majority of distribution-external references.
AUTHOR
Darren Duncan (perl@DarrenDuncan.net)
LICENSE AND COPYRIGHT
This file is part of the formal specification of the Muldis D language.
Muldis D is Copyright © 2002-2008, Darren Duncan.
See the LICENSE AND COPYRIGHT of Language::MuldisD for details.
ACKNOWLEDGEMENTS
The ACKNOWLEDGEMENTS in Language::MuldisD apply to this file too.