On 16 March 2016 at 09:23, David B. Lamkins wrote:
> On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote:
>
> The lexical rewriter could be a plugin, but it could also be an APL
> function. Imagine being able to assign an APL function to
> quad-SOMETHINGOROTHER to define your own l
Maybe David is thinking along similar lines to my proposal in this thread?
What would be wrong with implementing in quadAV a single overstrike
(e.g. i-beam <=> overstrike of encode decode) which when used in an apl
expression takes you off to your
implementation of e.g. a faster inner or outer
On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote:
>I was thinking of something similar, but the problem is that creating a
>plugin API that lets you implement trains is incredibly difficult,
>since you need to hook deep into the parser.
>
>As for more simple extensio
Hi
> make distclean works on my box (did you forget the examples ?).
is this what you meant by examples?
--
from make distclean after configure ; make on a fresh svn 705 download
make[2]: Entering directory `/usr/src/apl/apl/src'
Makefile:837: .deps/apl-Archive.Po: No such file or director
Hi,
make distclean works on my box (did you forget the examples ?).
building the binary in the same directory as the library should work.
/// Jürgen
On 03/15/2016 06:17 PM, enz...@gmx.com wrote:
Hi
I put the LC_ALL=C back and rebooted and the make on 705 worked - so whatever
you did in 705
Hi Peter,
I would say that we have such a mechanism already in GNU APL,
namely native functions.
With the current SVN you can even override built-in functions and
maybe (never tried, though)
introduce new APL characters/symbols.
One can i
Logarithm of negative real number fails to coerce it to complex and
results in a malformed value:
2⍟¯1
0.0
2⍟¯1J0
0J4.532360142
-k
Hi
I put the LC_ALL=C back and rebooted and the make on 705 worked - so whatever
you did in 705 fixed it and it isn't the LC_ALL (but no apl chars!!)
Do you get themake distclean errrors? (see below)
To make the libapl.sois there any coding issue with runing a configure
--libapl
Hi Elias,
not quite.
Both APL2 and GNU APL can bind an operator to its left argument
with ().
Neither APL2 nor GNU APL can bind a function
to its left argument with ().
The difference comes because APL2 binds operator / to its left
Hi,
the only thing I changed was to fix the compiler warning. Nothing
related to UTF8 or locales (and the build
process should be locale-independent as well, but who knows?).
I could imaging that setting locales or incorrectly can cause some
te
On 15 Mar 2016 23:56, "Juergen Sauermann"
wrote:
>
> And the syntax error is a mere consequence of / being a function in the
example (you
> cannot bind a function to its left argument with ().
I know GNU APL can't do that, but apparently APL2 can? Is that true?
Regards,
Elias
Hi,
maybe, maybe not.
it seems like in APL2,
/ and friends (⌿ \ and ⍀) are always operators.
In GNU APL / and
friends are operators if their left argument is a function, and
functions if their left argument is a value.
On 15 March 2016 at 22:47, Jay Foad wrote:
> On 15 March 2016 at 13:24, Elias Mårtenson wrote:
> > On 15 March 2016 at 21:14, Jay Foad wrote:
> >>
> >> 1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4
> >> 3 3 3 4 4 4
> >
> > Are you saying that (1 2 /)¨ 3 4 is syntactically correct in
On 15 March 2016 at 13:24, Elias Mårtenson wrote:
> On 15 March 2016 at 21:14, Jay Foad wrote:
>>
>> 1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4
>> 3 3 3 4 4 4
>
> Are you saying that (1 2 /)¨ 3 4 is syntactically correct in APL2?
Yes. / is an operator, so 1 2/ is a derived function
On Mon, Mar 14, 2016 at 2:03 PM, Juergen Sauermann wrote:
> Consider this:
>
> 1 (+//) 1 2 3 4
> 1 2 3 4
FWIW, Dyalog returns the same, but it certainly does something weird
I don't understand here. It treats it as an operator even when it
says it is a function:
f←/
⎕NC'f'
3
On 15 March 2016 at 21:14, Jay Foad wrote:
> 1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4
> 3 3 3 4 4 4
>
Are you saying that (1 2 /)¨ 3 4 is syntactically correct in APL2? If so,
there is an incompatibility here since GNU APL gives SYNTAX ERROR on that.
In APL2 this is not a problem, because / et al are always operators:
1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4
3 3 3 4 4 4
1 2 /¨ 3 4 ⍝ in GNU APL this parses as 1 2 (/¨) 3 4
3 4 4
Jay.
On 14 March 2016 at 13:03, Juergen Sauermann
wrote:
> Hi Kacper,
>
> yes. The tricky
17 matches
Mail list logo
