I was looking at an old proposal for using | in PRINT to mean "newline".
print [
"DESCRIPTION:" |
tab, any [description, "(undocumented)"] |
tab (uppercase word) {is} classification #"."
]
That was taken off the table due to | being used as an expression barrier. But COMMA! is doing a much better job of that, so it's back in the realm of possibility.
And I was also looking at some API code in ODBC like this:
rebValue(
"switch @", ARG(encoding), "[",
"'utf-8 [", rebI(CHAR_COL_UTF8), "]",
"'ucs-2 [", rebI(CHAR_COL_UTF16), "]",
"'utf-16 [", rebI(CHAR_COL_UTF16), "]",
"'latin-1 [", rebI(CHAR_COL_LATIN1), "]",
"] else [",
"fail {ENCODING must be UTF-8, UCS-2, UTF-16, or LATIN-1}"
"]"
);
It made me wonder what if SWITCH let you use something like, say, fat arrow:
rebValue(
"switch @", ARG(encoding), "[",
"'utf-8 =>", rebI(CHAR_COL_UTF8),
"'ucs-2 =>", rebI(CHAR_COL_UTF16),
"'utf-16 =>", rebI(CHAR_COL_UTF16),
"'latin-1 =>", rebI(CHAR_COL_LATIN1),
"] else [",
"fail {ENCODING must be UTF-8, UCS-2, UTF-16, or LATIN-1}"
"]"
);
Are Core Constructs Underplaying Their Hand?
I've felt for a long time that PRINT is not strong enough, because it hasn't taken things like TAG! away to signal format changes (colors?).
And when I look at the difference we get in SWITCH above, esp in the API, it makes me wonder if something like that is appropriate. Though maybe the @ symbol is better to be pushed further to this purpose as a legal branch type...
...anyway the details aren't important. I guess I'm asking more "could we make a better language if we were more willing to steal words".
Do we need distinctions...such as "core switch" and "rich switch", and then let people pick which they use? Where they're expected to hack up the switch to customize it to their tastes?
(Just wanted to put this out there, as I'm deleting a note about | as newline in PRINT on the Trello.)