Re: [Bug-apl] Make infinity and pi symbols into constants?

[Juergen Sauermann]

Hi,

 well, I see a number of problems.

First thing is ⎕AV. Even though ⎕AV is a bit outdated and ⎕UCS  is a less proprietary
way to generate charactersm it may still be in use. And is often tied to APL fonts in
some way. Usually the lower half are exactly ASCII and the upper half is some mapping
of relevant APL characters.

⎕AV shall be 256 characters in size for backward compatibility. ⎕AV is already rather crowded,
so for every new character (single ones, not entire Unicode pages) we have to kill another one
(convention has it that all relevant APL characters are in ⎕AV). New function symbols are possible
but would undermine compatibility of GNU APL with IBM APL2.

2. Fonts
I have emails from GNU APL users that do not use X, for example on Raspberry but also on
others OSs. Paul Hardy from the GNU Unifont project has developed a console font that includes
all characters currently used in GNU APL, those for Lambdas (⍺, ⍵ etc.) and so on. There is
a limitation on the number of characters in such fonts and according to the latest email I got
from Paul there is only 1 character free. If we now introduce additional characters for APL then
this would result in some systems not being able to display them

3. Keyboards (already mentioned)

4. APL look and feel
Right now we have Letters, Digits, ∆ and ⍙ as characters fur user defined names and the greekish
and mathematically looking characters for primitive APL functions. This is a clear border between
the user-defined and the system-defined domain.

If we would allow unused greek symbols in user defined functions or variables, then what would

Z←ABCσ123 mean?

To me (and admittedly old-fashioned APL-er) this would look like a monadic function ABC calling σ with argument 123
or maybe dyadic σ with arguments ABC and 123.

Taking all this together I believe the problems that may occur are bigger than the benefits.
And it would be a move away from a "common APL" that is useful for everybody.

----------------------------------------------------------------------

Having all that said I have two more notes:

1. You can use Unicode freely in GNU APL strings including the greek ones. Only
   APL program text (outside strings) is limited to the existing symbols.

2. The symbol table of GNU APL allows for those symbols already. Only the tokenizer
    insists on the standard symbols. So if you desperately  want π for ○1 then you can try this:

∇Z←Pi
  Z←○1
∇

and write a native function that roughly does this::

1. lookup Pi (returns a Symbol *sym)
2. create new_symbol from UCS_string(UTF8_string("π"));
3. new_symbol->push_function(sym-Get_function());

/// Jürgen



On 01/16/2014 02:34 PM, Elias Mårtenson wrote:

Point taken, and believe it or not, I actually mostly agree. :-)

That said, what is your opinion on making more characters legal as part of a symbol? This includes √ and ∞, but also the mathematical symbols things like 𝜓 (U+1D713) and ℝ (U+211D), just to name a couple.

Essentially, it'd be nice if the entire mathematical symbols pages was available.

Regards,

Elias

On 16 January 2014 21:19, Juergen Sauermann <address@hidden> wrote:

Hi Elias,

I believe we should weight the advantages of such extensions against their disadvantages.

Obviously π is shorter than ○1 and √ is shorter than ⋆.5

But:

- These symbols are on no APL keyboard,
- They are not in some APL fonts,
- They are rarely used.

Regarding ∞ right now GNU APL prints +∞ or -∞ if a number is larger than 1E307 or so. But you cannot enter
+∞ or -∞. They are output-only. It may make sense to use ¯∞ instead of -, but then  +∞ should become ∞
(otherwise +∞ and -∞ would use different formats. Not sure what looks better.


In the past, commercial APL vendors have used their extensions of APL in order to compete with other
commercial vendors. Which is fair enough. But it has also locked in the users of a particular interpreter
and then the "benefit" of a non-standard APL extension fires back. And, more importantly, the already
small community of APL users was divided into even smaller fractions that cannot easily exchange
their APL code.

Now, GNU APL is not commercial, so there is no need to compete by means of non-standard improvements of APL.

GNU APL also has its own extensions like ⎕INP and ⎕SI, but I would like to keep them at a minimum and stick to
the ISO standard as much as possible.

I have also seen things that have been implemented, which I consider simply awful and un-APL-ish.


Having all that said, I would like to hear more opinions about this topic. If there is a strong demand for the proposals
below, then I can implement them despite my concerns. My current plan with GNU APL is this:

GNU APL 1.3: Lambdas (aka. direct functions) and an open workspace interchange format
GNU APL 1.4: Parallel / multicore implementation of primitive functions and operators


/// Jürgen

Hi,

I know some APL implementations (NARS2000 for example, if I remember correctly) allows you to use the symbol π as an alternative to ○1. Would it make sense to do the same for GNU APL?

Likewise, being able to type ∞ instead of ⌊/⍳0 would also be neat, mainly because it makes sense. Also, wouldn't it make sense to use ¯∞ as negative infinity, rather than -∞?

Oh, and one more extension would be to implement a function √ whose monadic form would return the square root, and dyadically returns the L root of R (this is something NARS does, I think).

If you don't think this makes sense, an alternative would be to simply allow these symbols as characters in names, and a program can define these functions and constants itself.

Regards,

Elias

---