On Tue, Jun 22, 2010 at 6:34 PM, SundaraRaman R
<sundaryourfri...@gmail.com>wrote:
>
> Currently, since Perl 6 (afaik) supports Unicode identifiers, the only
> place
> a modification is required would be in the keywords.
Here's the relevant bits from S02:
The currently compiling Perl parser is switched by modifying one of the
braided languages in COMPILING::<%?LANG>. Lexically scoped parser changes
should temporize the modification. Changes from here to end-of-compilation
unit can just assign or bind it. In general, most parser changes involve
deriving a new grammar and then pointing one of the
COMPILING::<%?LANG>entries at that new grammar. Alternately, the
tables driving the current
parser can be modified without derivation, but at least one level of
anonymous derivation must intervene from the preceding Perl grammar, or you
might be messing up someone else's grammar. Basically, the current set of
grammars in %?LANG has to belong only to the current compiling scope. It may
not be shared, at least not without explicit consent of all parties. No
magical syntax at a distance. Consent of the governed, and all that.
So you could, for example, derive your grammar from the Perl compiler's
grammar and define your own rule for logical and, using the keyword
"florgle" instead of "and". There's more complexity to it than that, when
I'll touch on, below, however.
However, it is not a
> simple matter of substituting s/keyword/local_language_keyword/ since the
> resultant phrasing might be awkward or meaningless and unreadable (examples
> in the linked discussion). It requires reordering the syntax of each
> construct.
>
I can't think of any case where that would be reasonable. Perl may have
taken some inspiration from English in terms of features like postfix
conditionals, but the structure of the language has nothing to do with what
the keywords mean in any given language. "and" could just as easily be
"florgle" (pardon my language), the construct would still be:
if $a florgle $b florgle $c { die "Mega florgle" }
If your language doesn't do infix conjunctions, and instead lists the
relationships between items at the end of a sentence, re-iterating the items
whose relationships are being established, that's not a reason for Perl to
then be re-structured as:
if $a, $b, $c florgle $a, $b, $c { die "Mega florgle" }
Worse, what would that mean for hyperoperators and other meta operations?
More importantly localized dialects of Perl 6 face some substantial
challenges even without re-structuring. Operators (remember, Perl 6 doesn't
have keywords in the traditional sense) have a meta-meaning in Perl 6, and
if I write:
multi sub infix:<and>(MyType $a, MyType $b) { $a.truth and $b.truth }
then I expect that to affect what happens when you try to perform a logical
union on two values of type MyType. There are two options when localizing:
1) You can change the grammar, but leave the operator's definition alone
(e.g. the action for that operator calls infix:<and> regardless of what the
name in the grammar is), or
2) You can change both the grammar and the operator.
If you do the former, then my "and" still works, but you can't define a
"multi sub infix:<florgle>" and have it do what you expect.
If you do the latter then your "multi sub infix:<florgle>" would work, but
mine won't (and if it's library code, then you have a problem where bugs are
now localization-specific. Ugh.
Moving on to more general theories on the matter, I believe that localized
dialects of programming languages are always a bad idea. Choosing a
spoken/written language to base a programming language on is always tricky
(I would have voted for Japanese for Perl 6, even being an English speaker),
but once that choice is made, the resulting programming language gives
speakers of any arbitrary language an opportunity to interact with the
developers from every culture in the world, simply by learning the
structured conventions of the programming language (and quite possibly NOT
the language from which it takes its cues).
If you choose, instead to program in "Swahili Perl 6" then only people who
read Swahili will be able to tell what it was you were talking about,
whereas speakers of every language on Earth will know what you meant when
you write vanilla Perl 6.
Of course, education is often brought up in these discussions. I consider
this a red herring. The United States is particularly prone to using
localized versions of international symbols (e.g. meter), and this proves
confusing when interacting with the rest of the world. Take this to an
extreme, and we'd be taught to write "907 thousandsmallweights to the short
ton" rather than "907 kilograms" and that's just not going to help anyone
(yes, I'm aware that Brits try to spell that grammes, and I refer my right
honorable limeys to ISO 80000-1:2009).
Sure, Perl 6 allows you to localize names. In theory, but I'd be very
concerned about anyone who actually wanted to promote the use of such a
thing.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
