Jonathan Leffler wrote [on the TTM list]:
On Tue, Nov 16, 2010 at 12:34, Darren Duncan <dar...@darrenduncan.net> wrote:One of the oldest-defined features of Muldis D, intentionally supported from the beginning, is the idea of trying to be radix-independent; so you could write all of your numerics in any base you want, from 2 upwards but practically limited to 36, where column values 0..9 represent themselves and A..Z represent 10..35, the most common examples being bases 2, 8, 10, 16. My question is whether anyone would ever want to write numbers in bases other than the above 4 using a common shared syntax, or whether this feature would unnecessarily clutter the language and I should take it out.Take it out.Currently the only other language I know of that supports this is Perl 6, and Perl 6 even goes further in that you can express higher bases as comma-delimited lists of column value in a declared base. Do you know of any other language that currently supports, say, writing base-3 or base-4 or base-12 literals?IIRC, Ada does: 3#12011, 4#12301, etc...up to base 16 (using A..F for extra digits). (http://archive.adaic.com/standards/83lrm/html/lrm-02-04.html).Should I excise this feature from Muldis D to make it simpler or is there some benefit to retaining it? There's no practical benefit to the extra bases that I've ever seen.
Jonathan, Thanks for your input, and for the ADA reference, so I see another precedent. But that also makes me think of another option or three: 1. I could remove support just for using G..Z in the literals. In some ways, even when providing generic formats for multiple bases, going to exactly 36 because that happens to be what we have in our alphabet is rather arbitrary. Moreover, I'd think that in any likely cases where one would want to use other bases tersely, it would just be a small base, such as 4, or otherwise less than 16. So maybe an easy first move is to simply chop G..Z. The remaining A..F is well known by convention. 2. Drop this limited arbitrary-base format entirely and replace it with a version using a base-qualified comma/sepdelimlist of column values where each column is written in one of bases 2/8/10/16 with the plain or 0a format. 3. Keep just A..F in terse generic and add the commalist option. Regardless of the final decision, I think that the minimal good thing I can do is just drop G..Z / bases 17-36, which is part way to cutting it out and the result looks less arbitrary. -- Darren Duncan _______________________________________________ muldis-db-users mailing list muldis-db-users@mm.darrenduncan.net http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
