Re: Perl 6 in non-English languages
On Wed, Jun 23, 2010 at 1:34 AM, SundaraRaman R sundaryourfri...@gmail.com wrote: Hi, This is an idea that originated in #perl6 during a discussion with slavik ( http://irclog.perlgeek.de/perl6/2010-01-17#i_1907093). The goal is to allow Perl 6 source code to be written in natural languages other than English. The motivation would be to make programming accessible to a lot of people who don't know English well (or at all), to make it easier to teach programming to kids in non-English speaking countries, and just plain fun. Currently, since Perl 6 (afaik) supports Unicode identifiers, the only place a modification is required would be in the keywords. 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. Is it possible to do this at a module level? If so, how much English usage would that require before someone could start programming in their own language - say, two, for a shebang line and a use Lang::Language line? or zero, by using perl6 -MLang::Language in the command line? Are there any ongoing works in this vein? It is a bit hard for me to imagine how that would look like in RTL languages such as Hebrew or Arabic. Would the sigils be still at the beginning of the word? Would the assignments go from left to right? ;שלי $משתנה = 42 and I could not manage to type in a for loop via the Gmail interface as it was turning around all the time. What I'd like to see is a Scratch-like tool for a subset of Perl 6 that can actually generate Perl 6 code. http://scratch.mit.edu/ I know, I talked about it already a year ago. Gabor
Re: Perl 6 in non-English languages
Am 23.06.2010 22:51, schrieb Aaron Sherman: Moving on to more general theories on the matter, I believe that localized dialects of programming languages are always a bad idea. I totally agree. However there are things that can be translated to other languages, and that is documentation, error messages and warnings. The latter two require that we standardize exception types and messages, and provide some means to load different localizations. If somebody could take on that project, that would be really great for non-English speakers (and would also help the standard, English implementation, because standardize exceptions make testing of meaningful errors much easier). That would be a real benefit for the Perl 6 landscape at large, and probably not all too difficult (I'm sure that implementors of compilers and STD.pm will help with technical details where necessary, I for one would do my best to integrate such an effort into Rakudo). Cheers, Moritz
Re: Perl 6 in non-English languages
Moritz Lenz wrote: However there are things that can be translated to other languages, and that is documentation, error messages and warnings. And the next step is non-error messages intended to be seen by users. The latter two require that we standardize exception types and messages, and provide some means to load different localizations. If somebody could take on that project, that would be really great for non-English speakers (and would also help the standard, English implementation, because standardize exceptions make testing of meaningful errors much easier). That would be a real benefit for the Perl 6 landscape at large, and probably not all too difficult (I'm sure that implementors of compilers and STD.pm will help with technical details where necessary, I for one would do my best to integrate such an effort into Rakudo). I highly recommend a key-based approach, such that not even the English versions of these error messages and warnings etc are in the program code, but rather are in separate files, in the same format as versions of any other languages, and that the only thing actually in the code is a non-human-language lookup key, though that can be meaningful to programmers such as a variable name is. See my simple Locale::KeyedText module for a working proof of concept of what I speak of. Its the first module of mine that has matching Perl 5 and Perl 6 versions, and I had produced the Perl 6 version in 2005 as part of the early Pugs development effort. This said, I haven't updated it in years and I don't expect it to still run under Rakudo, but it did run under Pugs in the day. The concept I describe and demonstrated is inspired by how Mac OS X works, where all user text is in separate language resource files. I also recommend against the older gettext (name?) design that involved having one language's text inside the program code and using that as a key for others. I prefer the more self-consistent design that I proposed. -- Darren Duncan
Re: Perl 6 in non-English languages
Reminds me of an article of yore from The Perl Journal Localizing Your Perl Programs http://interglacial.com/tpj/13/ which discusses the reasoning behind Locale::Maketext the point of which is that the values you're looking up should be able to be functions, to handle some edge cases where nothing else will do. That module isn't exactly what Darren is looking for since the keys are English strings with a little meta-language mixed in, but the rest of it is worth referencing.
Re: Perl 6 in non-English languages
yary wrote: Reminds me of an article of yore from The Perl Journal Localizing Your Perl Programs http://interglacial.com/tpj/13/ which discusses the reasoning behind Locale::Maketext the point of which is that the values you're looking up should be able to be functions, to handle some edge cases where nothing else will do. That module isn't exactly what Darren is looking for since the keys are English strings with a little meta-language mixed in, but the rest of it is worth referencing. Functions are fine. My main point is that all languages are treated in exactly the same way as far as where their user text is stored and what format it has. The common format could in fact be a Perl module for each language containing the user text, and these all do a common role representing all the messages that could be used. You should not be treating the user text for one language differently from others, by using the text of one language to look up the text of another, or by embedding one user language in the main program code. Now, this isn't to say that the common key can't resemble English, but you should still have the separate copies of all the messages that are the actual user text, and the common English-like key can be a simplified version. A main point here is that if any translator or human-interfaces person wants to tweak user text, say to capitalize a word or fix a misspelling, they shouldn't have to go into the main program code to do it, and the process is the same for every language, and you only have to update not more than one copy or location per language. Something I want to avoid is the actual English user text being used to look up the others, because then if you want to tweak a misspelling or something in English, you'd then have to find an change all the other copies of the text in order for the mapping to be maintained. Its a similar problem actually to a bad relational database design, where you use something descriptive and likely to mutate (such as the English name of a product for sale) as the column that a foreign key copies and points to, in contrast to say a less descriptive product code. What I am proposing is to use the analogy of the product code in your main code rather than the English product name. But the code can still be quite English like. Such as a role's function name can be English like. -- Darren Duncan
Re: Perl 6 in non-English languages
If Perl 5 can support
Lingua::Romana::Perligatahttp://www.csse.monash.edu.au/%7Edamian/papers/HTML/Perligata.htmland
let you type
benedictum factori sic mori cis classum.
instead of
bless sub{die}, $class;
then Perl 6 should be able to do it even better. I think it would be
implemented through a set of macros. Unfortunately at the moment, the Perl 6
implementation that is the most advanced at the moment, Rakudo, does not
support macros. (I'm not sure about Sprixel, Mildew, etc). So while the
language specification would make it possible to use a different natural
language as a base, it can't be implemented by the most natural method.
Re: Perl 6 in non-English languages
On Jun 23, 2010, at 12:34 AM, SundaraRaman R wrote: This is an idea that originated in #perl6 during a discussion with slavik ( http://irclog.perlgeek.de/perl6/2010-01-17#i_1907093). The goal is to allow Perl 6 source code to be written in natural languages other than English. The motivation would be to make programming accessible to a lot of people who don't know English well (or at all), to make it easier to teach programming to kids in non-English speaking countries, and just plain fun. Currently, since Perl 6 (afaik) supports Unicode identifiers, the only place a modification is required would be in the keywords. 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. Is it possible to do this at a module level? If so, how much English usage would that require before someone could start programming in their own language - say, two, for a shebang line and a use Lang::Language line? or zero, by using perl6 -MLang::Language in the command line? Are there any ongoing works in this vein? Having been that road down at least once in my life already (using the TUTOR language), I would be very much against adding this as a standard feature. Unless you have people that can provide support (aka a user base) for that language, you are going to introduce a babylonian knot of misunderstanding in mailinglist, chats and what not. If this would be added as a feature, then there should be an easy way to take any source file in a different natural language, and have it rendered into English (or any other of the languages supported that way). My old 2cents worth... Going back to lurking mode again. Liz
Re: Perl 6 in non-English languages
On Tue, Jun 22, 2010 at 6:34 PM, SundaraRaman R
sundaryourfri...@gmail.comwrote:
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::%?LANGentries 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 8-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
Re: Perl 6 in non-English languages
I should point out that I've had a great deal of coffee. The technical details of what I've said are reasonable, but read the rest as off-the-cuff opinion. It's also true that seeing how Perl 6 would look/work when re-cast in the grammatical conventions of another human language would be very cool, even if I might take exception to its proposed use.
Re: Perl 6 in non-English languages
Another thing to consider is that Perl 6 is symbol-heavy: that is, keywords are often symbols (such as , =, or $_) rather than words. AFAIK, those symbols are not English, and I would not expect them to change under a natural language transformation of the setting. And to elaborate on Aaron's point, I'd expect such things as function call syntax, operator syntax, method call syntax, and the like to remain the same, as these things aren't English either. As for seeing a natural language variant of Perl, my own thought is that the first such variant might be most useful if it mines a decidedly artificial natural language for its keywords, such as Esperanto or Interlingua. Given that Perl is not English, and merely uses English loan words whenever it needs alphanumeric keywords, I suspect that an Interlingua-based variant might be close enough to, say, a Spanish- or French-based variant that the latter two might possibly end up not being worth the trouble of writing. Not being a linguist, I could be wrong about any or all of the above. As for Aaron's concerns about the use of alternate natural languages complicating the use of modules: note that this really isn't any different from any case where you change the underlying grammar. Perl has a robust module system that assumes that each module is written in the Perl dialect that the module specifies rather than in the dialect that the script is written in, and vice versa; so aside from the optional hassle of translating English-based modules into the preferred natural language setting when you import them (or vice versa, in the case of modules that are written in other natural language variants), there is unlikely to be much of a problem from Perl's perspective. In terms of the Perl community, I suspect that we're best off assuming that most Perl modules and scripts should be written using the default English-based setting for the foreseeable future; the use of natural language variants should be considered to be a niche market. When and if English gets supplanted by some other language as the technical language of choice, this notion can be revisited. Assuming that Perl is still in reasonably wide use when that happens, it will have the flexibility to make the transition. -- Jonathan Dataweaver Lang
