bug-apl
[Top][All Lists]
Advanced

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

Re: [Bug-apl] Regex support


From: Peter Teeson
Subject: Re: [Bug-apl] Regex support
Date: Wed, 20 Sep 2017 22:19:22 -0400

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
>> 
> 




reply via email to

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