The APL Orchard

« first day (1490 days earlier) ← previous day next day → last day (1461 days later) »

ngn

20:00

@Adám something like that but i wanted to avoid the global

Adám

So here ^^ we have a dfn seeing the local value of another dfn, even though it wasn't defined there.

@ngn The global doesn't do anything here.

ngn

@Adám ok, so let's try to reason about this part in isolation:

  InnerDfn←{a}
  a←'global'

if dfns use lexical scoping, it should be possible to tell where "a" belongs, just by looking at this fragment (and possibly its surrounding pairs of "{" and "}" but there aren't any)

yet, our assumption about where "a" lives would be wrong, poisoned by a tradfn somewhere in the middle of the call chain

=> even dfns don't use lexical scoping

Adám

@ngn Yes, if you call InnerDfn from a tradfn that has its own a, InnerDfn would see the caller's a instead.

dzaima

@ngn rm -rf /; shutdown could also poison the result of InnerDfn, but that doesn't change that dfns use lexical scoping

Adám

@ngn Correct. Dfn-calling-dfn uses lexical scoping. The scoping rule depends on the call, not on the type of the called (or calling) function in isolation.

ngn

20:07

@dzaima rm -rf / could make the world end, but it alone would not cause the dfn to look for "a" in the wrong scope!

dzaima

@ngn i'm sure i could craft a ⎕sh argument to change dfns to use lexical scope

ngn

ok, so my conclusion is that dfns can't be assumed to use lexical scoping

that is very very wrong. you can't reason about code in isolation.

Adám

@ngn True, however if you have a dfn calling a dfn, then you can safely assume lexical scoping.

dzaima

@ngn doing bad things (using tradfns) results in bad things (dfns not using lexical scope) :)

ngn

@Adám how do you know there isn't some shitty library in the middle

in a big codebase that would be a nightmare to debug

@dzaima well said!

Adám

20:11

@ngn What middle? Your dfn calls your dfn.

ngn

@Adám yep

dzaima

@ngn thanks, i tried to write specifically how you'd like it

ngn

@Adám it could be indirect

Adám

@ngn Then there's no issue.

@ngn I don't know what you mean by that.

ngn

@Adám one of my dfns calls a library function that ends up calling my other dfn

Adám

20:14

@ngn Library functions shouldn't use global names. They also shouldn't ⎕SH'rm -rf /'

ngn

{a←123 ⋄ ns←⎕ns⍬ ⋄ ns.callback←{⎕←a} ⋄ lib.doSomeAsyncIO ns ⋄ ...}

@Adám no globals involved^ but you're telling me this might not print 123?

dzaima

@ngn namespaces are dynamically scoped, and assigning fns into namespaces is already plenty broken (your example wouldn't work ever)

Adám

@ngn ns.callback can't see the a.

ngn

another can of worms

dzaima

@ngn right, but a separate one

ngn

20:17

doSomeAsyncIO could be an operator

dzaima

@ngn right, that's the more concerning case

ngn

"tradop"

dzaima

@ngn (unrelated and unimportant, but "async" is itself implying that there's absolutely no chance that a dfn callback could ever work because no closures :) )

ngn

too many cans of worms

dzaima

agreed

but if you stick with just dfns and don't assign functions in namespaces, you're fine

Adám

20:20

2 hours ago, by Adám

Now, to throw in operators in the mix… that's a whole other can of worms.

dzaima

@dzaima (oh, and apparently no & - {a←4 ⋄ {⍵+a}&0}0)

ngn

sometimes i wonder, is there something that prevents array languages from implementing proper lambdas with lexical scoping, and vice versa - is there something preventing lisps from adding a proper concise vocabulary of bulk operations

Adám

Don't J and BQN have full lexical scoping?

ngn

it seems there shouldn't be. it seems it's a matter of the culture around apl vs lisp.

@Adám J - no. BQN - idk.

dzaima

BQN has proper lexical scoping

ngn

20:29

J uses these weird combinators (adverbs and conjunctions like "self-reference") to avoid lambdas and lexical scoping, but IMO ends up more complex

Wezl

@ngn lisp - no, but that vocabulary just isn't built-in

Adám

@ngn Newest J has lambdas, iiuc.

ngn

@dzaima i'd be a fan if it wasn't for the strange choice of array model and symbols

dzaima

@ngn how is the array model strange?

oh right, you don't like rank

and unicode

ngn

@dzaima enclosed scalars

@dzaima of course, k's model is simpler (it still has "rank", it's just equivalent to "depth")

dzaima

20:35

@ngn I think it's far less strange than floating arrays. Not to say it's better, but definitely less strange

ngn

@dzaima even if we embrace unicode and put up with the endless stream of complaints about fonts and keyboards, the choice of symbols is still bad - some of them render poorly in default existing fonts, and some of them look too similar to common ascii chars

@dzaima i don't want to be thinking about enclosing and disclosing in bqn all the time. apl is tolerable. k relieves me completely of such distractions.

bqn and j are in the same pot, in that respect

dzaima

@ngn changing symbols to worse ones just for compatibility isn't good imo (⊸⟜ are perfect, even though they look ugly and inconsistent often)

@ngn APL not requiring disclosing sometimes is a recipe for disaster for when it does

rak1507

how can they be perfect if they sometimes look ugly and inconsistent? doesn't sound particularly perfect to me

ngn

@dzaima yeah, those are fine, but there were some like a horizontal S and Z and those looked twice as wide as they should in default fonts

dzaima

@rak1507 they're perfect idiomatically (and with a good font)

@ngn ⥊=⥊?

ngn

20:43

also: "w x" instead of "x y", come on..

@dzaima yeah, ⥊ was one of them

dzaima

oh right ∾=∾ is the other you mean

ngn

yes!

dzaima

@ngn ok sure. y{}x is ugly though (not saying more ugly than w x, but)

ngn

@dzaima why not the obvious: x{}y?

Adám

I still think a new APL should be LtR

dzaima

20:46

@ngn and {}y for monadic invocation?

Adám

@ngn Because y as the only arg is odd.

ngn

@Adám you're not allowed to think that, it's not backwards compatible :)

Adám

BQN isn't compatible with APL either. Call it LPA then.

ngn

@dzaima i would prefer {}x but {}y could be a compromise, like in dyalog's docs

Wezl

@Adám I'm working on designing something a bit inspired by APL that's LtR. Not very array-oriented though

ngn

20:47

@Adám NQB :)

dzaima

@ngn {}x and x{}y means you lose all ability to write ambivalent code

Wezl

there's no need to use letters though

ngn

@dzaima perfect, lambdas would know their valence :)

@Wezl good point

Adám

@ngn That's a great name. "Encubey".

dzaima

@ngn right. I don't want to touch ambivalent code, but the example runtime uses it quite a bit

Adám

20:49

@Wezl ⍇ and ⍈ would work for left (optional) and right args.

Wezl

@Wezl {+/1+⍳_}

Adám

@Wezl And the left arg?

Wezl

_ and ‗ ? No, those are too similar.

ngn

@Adám or N³ :)

Adám

I think Marshall wanted x in keeping with TMN.

I personally wouldn't mind so much if x and y etc. were "pre-populated" names.

But of course, you wouldn't be able to infer type from the presence or absence of operands. (Something I dislike anyway.)

Wezl

20:52

I would prefer z to w because double-struck w is a pain to draw

Adám

I'd rather require _{…} and _{…}_

2 hours later…

Bubbler

23:04

IMO user-defined functions should define monadic and dyadic usage separately, and form an ambivalent function using a "monad/dyad" built-in. Supplying a default arg for ⍺ is not bad in this way Dyad←{...} ⋄ Func←n∘Dyad:Dyad, while Dyalog's way for a more general case (checking ⎕NC'⍺') is plain ugly.

... except that you lose ambivalent operators

dzaima

23:54

@Bubbler BQN (and ngn/apl!) allow defining separate monadic and dyadic function versions with {monadic ; dyadic}