bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Feature suggestion: multiple function arguments


From: Juergen Sauermann
Subject: Re: [Bug-apl] Feature suggestion: multiple function arguments
Date: Thu, 17 Mar 2016 16:58:42 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Hi,

if I look at C++ then the standard is equally restrictive when it comes to the source code:

"The basic source character set consists of 96 characters: the space character, the control characters repre-
senting horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters: 14
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ∼ ! = , \ "

They, like GNU APL, allow Unicode in strings (and probably comments) but not in source code.

Have I missed Unicode variable names in C++ in the last 20 years? Never.
Not even the German ä ö ü and friends.

I cannot really see why arbitrary Unicode characters would be an improvement.

The ISO standard is also quite clear what name shall be (page 41). By allowing Unicode
in names we would introduce a completely unnecessary incompatibility between GNU APL
and APL2 or the ISO standard.

Of cource we cannot prevent people from using unreadable names. But we should
not encourage that either.

/// Jürgen



On 03/17/2016 04:15 PM, Elias Mårtenson wrote:
On 17 March 2016 at 22:46, Juergen Sauermann <address@hidden> wrote:
Hi Elias,

this is quite feasible technically. What I don't like, though is the incompatibility
that it creates for the source code.

Suppose I write a function Z←AؠB. Who else except myself can decipher
what it is supposed to mean? I strongly believe that restriction names
to almost only ASCII letters (and writing the names in English) is a very
good convention that we should not easily give up.

Well, you used an arabic letter in your example, which of course is quite indecipherable to me. If you had named the function KASHMIRI_YEH, it would be equally indecipherable.

However, allowing arbitrary Unicode would allow you to name a function ≈, for example. Another useful example would be a physics application using the symbol ℏ.

As you can see, only allowing english letters doesn't guarantee readability. And allowing Unicode doesn't imply hard-to-understand.

Anyone who cares about incompatibility simply wouldn't use these characters. You could even add a flag --disable-extensions to ensure this.

Regards,
Elias


reply via email to

[Prev in Thread] Current Thread [Next in Thread]