Re: [Bug-apl] Regex support

[Juergen Sauermann]

Hi Peter,

I mostly agree with your concerns. As you may have noticed, I already regretted some of the things that I implemented earlier
in GNU APL. On the other hand, you also see on the GNU APL mailing list the proposals of other GNU APL users to implement
certain things. I haven't really found a way out of this dilemma.

My current thinking is this:

1. If a feature affects the APL language itself then it is probably a bad thing to do. Examples for this are, IMHO, changing the scoping
    of variables, lexical binding and stuff like that. As useful as these may be in other languages, my feeling is that they would turn GNU
   APL into something else which is no longer APL. For example, I am a big fan of the powerful matching capabilities in Erlang but I
   believe as useful as they may be, they simply do not belong into GNU APL (or any APL for that matter). Those who really need that (as
   opposed to only believing it would improve GNU APL) might be better off with one of the successors of APL.

2. Some areas, most notably FILE I/O have traditionally not been part of the APL language itself, but are unfortunately needed in the
    real world. I am equally concerned about a proliferation of quad functions (and most other APLs are more keen than GNU APL to
   move in that direction). However, regular expressions are a more fundamental concept than other "nice to have but never used"
   features, so that adding them as a ⎕-function should not do too much harm. Nobody is forced to use a ⎕-function that he or she
   does not know or like. And the only thing that gets more complicated when a ⎕ function is added is the implementation and not
   the language.

Rational number, BTW, have to be explicitly ./configured and are not present in the default GNU APL. Same for parallel APL. I have
seen that some users are experimenting with these features and I believe we should allow that because chances are that these
experiments result in something valuable some day. Who knows?

Best Regards,
/// Jürgen

On 09/21/2017 04:19 AM, Peter Teeson wrote:

It so happens that 2 of my former colleagues from I.P.Sharp came visiting today and we were chatting about this.
Ken was not in favour of making APL complicated. When I worked at IPSA my office was next to Ken’s 
and when someone suggested some form of addition to the language he would usually ask 
why we could not do it with an APL function. (These days performance can hardly be a compelling argument
with multiple many-core CPU chips.)

Right now we already have a proliferation of Quad functions not to mention lambdas and native functions.
We also have divergent APLs such as Dyalog (good as it is) and so on.

Complex numbers, rationals and file systems are good additions.  
But IMHO we should have one simple mechanism - i.e. the libapl APL API
and all the rest go through that as native functions.

Jurgen’s guiding light is to make GNUAPL an implementation that met the ISO and APL2 definitions.
We have already wondered away from that. Pity.  When will it stop?

Just my 02¢

respect

Peter

On Sep 20, 2017, at 4:30 PM, address@hidden wrote:

<mumble> anyone who loves grep and hates perl (and i hope java too) can't be all bad </mumble>

using apl like syntax is good    aaa' ⎕REX['s'] 'bbb'      what would monadic   ⎕REX['s'] 'bbb'      return?

On Wed, 20 Sep 2017 21:47:29 +0200
Juergen Sauermann <address@hidden> wrote:

Hi Elias,

I am generally in favour of supporting regular expressions in GNU APL.

We should do that in a way that is compatible with the way in which the most commonly used libraries
do that (even if they are lacking some features that more exotic libraries may have. Unfortunately I do not
have a full overview of all (or even any) existing libraries. I personally love grep and hate perl (the latter not
only because of their regexes).

I would like to avoid constructs like s/aaa/bbb/ where operations are kind of text-encoded into strings.
That is, IMHO, a  hack-ish programming style and should be replaced by a more APL-alike syntax such as
'aaa' ⎕REX['s'] 'bbb' or maybe 's' ⎕REX 'aaa' 'bbb'.

Or, if the number of operations is small (perl seems to have only 2, not counting the translate which is already
covered by other APL functions), then we could also have different ⎕-functions for them and thus avoiding a
third argument.

Everybody else, please feel invited to join the discussion.

Best Regards,
Jürgen Sauermann


On 09/20/2017 05:59 AM, Elias Mårtenson wrote:
On several occasions, I have felt that built-in regex support in GNU APL would be very helpful.

Implementing it should be rather simple, but I'd like to discuss how such an API should look in order for it to be as useful as possible.

I was thinking of the following form:

      regex ⎕Regex string

The way I envision this to work, is to have the function return ⍬ if there is no match, or a string containing the match, if there is one:

      'f..' ⎕Regex 'xzooy'
┏⊖┓
┃0┃
┗━┛
      'f..' ⎕Regex 'xfooy'
'foo'

If the regex has subexpressions, those matches should be returned as individual strings:

      '([0-9]+)-([0-9]+)-([0-9]+) '⎕Regex '2017-01-02'
┏→━━━━━━━━━━━━━━━┓
┃"2017" "01" "02"┃
┗∊━━━━━━━━━━━━━━━┛

This would be a very useful API, and reasonably easy to implement by simply calling into the standard regcomp() call: http://pubs.opengroup.org/onlinepubs/009695399/functions/regcomp.html

What do you think? Is this a reasonable way to implement it? Any suggestions about alternative API's?

Regards,
Elias