As a further update, ...
I've decided not to offer two official variants at all, that differ just on
using $ sigils. Neither by having a pragma in PTMD_STD nor by splitting off a
new dialect from it.
I decided that doing this is just unnecessary complexity and risks causing
unnecessary fragmentation or greater difficulty in using Muldis D.
So instead, I'm just going to pick one option and standardize PTMD_STD on that;
either the current version that uses $ sigils or an update that excises them but
otherwise remains essentially the same.
I will also wait at least a few days before changing anything, so that any
changes aren't rash.
These are reasons I see in favor of keeping the $ sigils:
1. The $ effectively provides a distinct namespace, so that users can name
their named-data entities like parameters or variables or attributes etc
anything they want, and use them as barewords (except those containing
non-alphas-etc), and they would never be confused with any language keywords.
So they provide a degree of forwards-compatibility, where the language can
evolve and add keywords and no existing variables/etc will come into conflict.
On the other hand, all user-defined entities can be disambiguated from keywords
by enclosing their names in double-quotes, like with SQL identifiers, so at
worst this saves a minor inconvenience.
2. The $ helps to make code less monotonous, assisting every different kind of
thing actually look different. Variables/etc have a leading $, generic routine
calls have trailing (), type annotations have a leading :, character strings are
single-quoted, comments are #-quoted, named statements have a leading |,
keywords are barewords with none of those, curly braces means an unordered list,
square brackets means an ordered list, and so on.
3. The $ have been around for awhile and so other aspects of the language may
depend on them in a small way. While removing them should be fairly simple and
only involve maybe 2 changed lines in the PTMD_STD grammar, I would have to be
on the lookout for other tweaks that may need doing as a consequence of this.
The $ constitutes a whole mnemonic that says "data" after all. Some of the
consequences are in the 2 HDMD_Perl*_STD dialects, which I maintain some parity
with as applicable.
These are reasons I see in favor of dropping the $ sigils:
1. The $ aren't really necessary at all to disambiguate/parse/read code; maybe
in other languages like Perl they are necessary for understanding, but in Muldis
D they are mainly superfluous (due to other restrictions in its design), just to
make the code look "prettier". Especially if I retain all the other
distinguishing marks or syntax restrictions.
2. Dropping the $ raises internal consistency because some references to
attributes already lack the $ sigil, such as in many operator shorthands, or
references to parameters in their named-argument-invocations lack the $ sigil,
and usage of the $ in some contexts like unique/subset constraint definitions
looks kind of odd, though many other uses don't look odd.
3. SQL doesn't generally use sigils (some vendor extensions notwithstanding),
and Muldis D is primarily meant to replace SQL, so this helps with a slightly
smoother migration considering people's expectations for something loosely
resembling COBOL syntax.
4. Many general purpose languages don't use sigils, and while controversy
abounds in the programming world between people who like sigils and people who
don't, the number of people and communities that don't is large. Also, the
number of common general purpose languages that don't use sigils dominantly
exceed those that do. So not using sigils should help these people be more
comfortable with it while it shouldn't greatly inconvenience people who like
them sigils. Muldis D use is meant to cut across all general purpose languages,
same as SQL is.
5. Dropping the $ should make Muldis D a bit easier to type, as there's less
use of the shift-key, and it is slightly less verbose.
6. All things considered, I'm actually on the fence as to which style I prefer.
Constructs in Muldis D that have direct Perl equivalents such as routine defs
or type defs look the prettiest with them, but other constructs that Perl
doesn't have such as unique/subset constraint entities have no Perl analogies
and the $ look more odd there.
So my current thought is to change PTMD_STD to drop the $ sigil, but I'm going
to wait a little while before doing so, leaving things unchanged for now, while
I think it over.
Further feedback on the matter, specifically along the lines of which single
format to pick rather than how to support both in the STD dialects, is welcome.
Thank you. -- Darren Duncan
_______________________________________________
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
