On 6/6/2011 10:29 AM, K. K. Subramaniam wrote:
Alan,
Thanks for the correction. IAL was one of the proposed names for the ALGOL,
wasn't it?
The reason why this name popped up from my grad days was because something as
complicated as designing a new programming language was considered a fun thing
to do. It wasn't as much fun for those who had to maintain programs written in
them years down the line ;-). Gerald Weinberg's parody - Levine, the great
Tailor - should serve as a lesson even today.
agreed...
but, yeah, designing a language is generally a fun/interesting thing to
do, and so is working on the compiler/VM, fiddling with stuff, ... it
gives much more of a sense of "doing stuff" than some other activities,
and is not necessarily (entirely) busywork or mindless tedium either...
granted, yes, my designs tend to be fairly conservative (and not
generally "minimalist"), as I don't personally believe in unnecessary
novelty either.
but, one can simplify things when useful as well (say, when preexisting
options either don't exist or are not very good, are overly cumbersome,
or would be be a pain to implement, ...).
for example, I was recently (maybe 30 minutes ago) left considering the
issue of what should be the syntax for type-specialized arrays.
in C, array types are known by context, so are not normally given in the
syntax (although, IIRC, a cast can be used, say: "(char){ ... }");
Java does it like this: "new type[] { ... }";
my language declares normal arrays as "[ ... ]";
I couldn't determine if ActionScript had a similar feature.
for now, I opted with this: "[ ... ]suffix" and "[ ... ]:type".
where suffix is a generally 1-3 letter shorthand for certain common
types, usually used for things like literals and similar, whereas the
latter form would be the "general case".
so, for example, an array of bytes: "[16, 29, 32, 227, 113, 255]UB", as
well as allowing this, "[3, 4, 5, 19, 340, 0]:byte"
this was because this seemed like the least effort, and this also looks
less nasty than some other options. say, "[1, 2, 3, 4] as! byte[]",
which is also slightly semantically misleading as well, since normally a
cast like this would fail and raise an exception (note: "as" will return
null if the cast fails, but "as!" will either cast or blow up; the
traditional C-style cast syntax was removed as it created syntactic
ambiguity, hence "as!").
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
