@Adám some header separation of the cases would be best imo. Much better than what APL currently has anyways

@ngn aren't they similar though?

@rak1507 Not really. Honestly the language FP has had very little impact on other languages including APL and is hardly relevant here.

On the wiki page for FP, it says it was influenced by APL, weird. And the citation is a link to a paper that a quick ctrl F does not find a single mention of APL in, and only one of FP

seems a little bit dubious

@rak1507 maybe. apl&j are perfect examples for this distinction - they do support function-level programming but they aren't really functional languages as they don't treat functions as first-class objects

web.archive.org/web/20160311204021/http://haskell.cs.yale.edu/…

@Marshall true

oh, there is a mention of APL, ctrl f just sucks

‍

@ngn First-class functions have been on my to-do list, since I get them free in CL

@Wezl I think it was an issue of the pdf rendering

Not sure why APLs never tried adding them

because then is (f g) passing g as an argument to f or an atop

@phantomics why waste time on apl? go straight to k. it's parsable and supports first-class functions.

@phantomics you either need to box/unbox them, which is ugly, or ditching the dynamic parsing, which is a pretty big change

@dzaima red/rebol uses space to apply and has infix, but you can represent the literal function by prepending colon so it's no big deal -- just a syntax change

ok maybe a syntax change can be a big deal

so, yes, just go straight to k

@dzaima Since I have a compiler I'm already partway there, and I should be able to change how function parsing is handled with a plugin to the original April since it's modular

<moon-child> @ngn k functions are ugly

@phantomics how would you differentiate - 2 between a monadic application and an array of 2 items?

<moon-child> e.g. user-defined functions are second-class

@ngn And k only supports vectors, I like being able to work with any rank array

@dzaima I thought of a couple solutions

One is to use the : character, which I don't use in control statements because I won't be implementing them

For example, a←{⍵+3} ⋄ a:5

That would result in 8

a 5 would be a vector of a and 5

@phantomics so any non-builtin-function call would require a :?

@DyalogAPL user-defined functions look the same as dfns. there are no user-defined verbs.

<moon-child> @phantomics so stranding as a separate syntactical element, like in bqn?

@dzaima Correct, the other solution is to do like BQN and capitalize function names for calls

@phantomics or the other way around, a 5 is application while :a 5 is an array

add5←{⍵+5} ⋄ Add5 3

@phantomics k unifies rank and depth. you can have any-rank arrays. including ragged.

<moon-child> if so, I think it makes sense to make stranding need a separate character, as it's less common than application

it's also needed for function arguments. e.g. applying a function to itself, and differentiating a b 1 between a dyadic call and 2 monadic calls

@Wezl That could work too, but even if stranding is more common it's troublesome to have a convention like :a 5 since the norm is to have the elements of a vector entered with just spaces between them and no need to "quote" functions with a :

*if stranding is less common I mean

strands aren't special at all here

<moon-child> @ngn yes, but user-defined functions are second-class. 0x0.st/-i9M.txt

@ngn Having the two separate concepts, rank and depth, allows you to box away the units you want to work on. In K you always have to specify the depth (like you do with rank in APL when you want fast code).

You don't see a : between elements in a vector in normal circumstances so when you see they you know a function's being called

Also, using : to call functions makes it straightforward to call an array of functions on an array of values

{stuff}:⍤1⊢5 5⍴⍳9

Let me clarify that

@DyalogAPL <moon-child> i don't understand. what is this code meant to demonstrate?

(5⍴{stuff}):⍤1⊢5 5⍴⍳9

<moon-child> @ngn the user-defined function 'c' has a different syntactic class from the builtin function ','

This is an example of a 5-element vector of functions, each one being called on a row of a 5x5 matrix

@phantomics ok, I'd still prefer using a separate stranding separator than making function calls harder. I proposed :fn because it's less likely to break backwards compatibility

@DyalogAPL <moon-child> so you're objecting to the syntax (verbs like , can take an arg on the left, whereas nouns like {} can't), not questioning the fact that all functions are first-class?

<moon-child> @ngn I'm saying that syntactically, some functions are second-class

@DyalogAPL <moon-child> you're inventing terminology

<moon-child> ?

@Adám by "you always have to specify the depth" you probably mean each, eachright, eachleft (' /: \:). i'd argue they are more intuitive than ⍤ and ¨⊂ and it's better to have one concept for building nested structures than two.

You're entitled to your opinion.

@DyalogAPL <moon-child> "first-class" means that at runtime you can pass functions as arguments, return them as results, put them in lists, etc like any other object. nothing to do with parsing.

@Adám You're entitled to your opinion.

@MartinJaniczek @Adám @ngn re language bar: since it stops the input event in its tracks, I've had to emit a custom event whenever the t.value = ... mutation happens, to allow at least catching that custom event and reading value off of that. Would you like a PR to any of your lb repos? ellie-app.com/c7RNshqjSLHa1

@MartinJaniczek relevant lines in the HTML/JS at the bottom left: 102, 107, ... let em = x => x.dispatchEvent(new Event('lang-bar-insert-char'));

<moon-child> @ngn alright then, call it whatever you like. User-defined functions have different syntactic behaviour than builtin ones, and I find that inelegant. That is all.

@MartinJaniczek The idea is that the lb should be able to "slot in" on most any website. Stopping the default event is not good. However, raising a custom event won't help any 3rd party site function, will it?

@DyalogAPL <moon-child> do you find apl inelegant because you can't do √←{} or +←{}?

@Wezl In terms of compatability you have a point, but lately I'm leaning more toward capitalizing names of called functions anyway

moon-child: isn't it more that built-ins have an additional way of being used, one that user-defined ones can't use?

@phantomics Is April versioned? There are a few early releases on Github but nothing recent, and I'd like to update the infobox on the wiki to represent current development better.

<moon-child> @Adám that's fair

: could also be used but it would only be necessary when you do something like the application of a vector of functions to rows of a matrix like I described above

@phantomics Any particular reason you capitalise functions rather than arrays?

@Adám couldn't you say that about anything that's not first-class?

<moon-child> @ngn mutability is inelegant ;)

@phantomics I didn't notice that using : to apply fixed the problem with BQN's approach, that { can't be capitalized, so it's unclear whether a {} function is a subject or not

@Adám The underlying website (or it might be something specific to Elm? dunno) doesn't receive the input event whenever input through the language bar happens. Fixing that would be ideal. My custom event is a hack, for people that want to embed the language bar in the apps they control source of, not for users that want to use it on arbitrary websites. Yeah...

@dzaima I didn't object the the label.

@DyalogAPL <moon-child> so you prefer k's immutable dicts over apl's mutable namespaces then? :)

@Marshall I'm planning on a new release soon, clearing bugs and making improvements

<moon-child> @ngn on a more serious note: a little bit, yes. In my apl I do allow reassigning builtins

<moon-child> @ngn and yes, I don't like dyalog namespace

Goal is to have it out by end of January

@phantomics Cool.

nothing about √←{} has anything to do with mutability, as it doesn't already exist, right?

@MartinJaniczek So, in my example, I listen to input as usual, but also I listen to the new event to not miss the new characters. Html.Events.on "lang-bar-insert-char" (Json.Decode.map SetInput Html.Events.targetValue)

@Marshall I can make some contributions to the wiki as well

@rak1507 i believe moon-child meant +←{}

yeah but that's only half of what you said

@Adám Mainly because I see functions as more "special" than value-referencing variables

<moon-child> @rak1507 it does exist in dzaima/apl. Dyalog rejects it because unicode. And yeah I meant +←{}

@phantomics Well don't wait for my permission.

I think +←{} would be a bit weird but √←{} would be fair enough as it doesn't already exist

I agree

And if in a future version it is added?

@Wezl In the case of {} you would need to use :, or highlight it in some other way

Wouldn't that reduce √←{} to a case of +←{}?

@rak1507 but dyalog doesn't even consider √ to be an identifier. user-defined functions look different from built-in ones. which was exactly the point in guy steele's "growing a language", and also the point i wanted to make for moon-child.

@Marshall Once the release is done

@code_report Yeah, I noticed.

@rak1507 IMO it's unfair that +, *, ⍳ etc. get their own tokens, and APL should go with forth/lisp's approach with naming -- but I don't think I can convince APLers to put spaces between their builtins

@code_report huh interesting

@Adám I think +←{} should be syntactically valid but with no guarantees about how much stuff would break

We could simply ask @arcfide

@ngn I'll have to watch that talk

<moon-child> @Wezl one solution: lambda calculus-style names. fgh ←→ f g h. Use sigils for longer identifiers: a$abc d ←→ a $abc d

@Wezl they could be single-char tokens identifiers

that's acceptable

I think the no reserved identifiers

I like the idea of using sigils, though I've never actually used a PL with them

… is one of the best features of APL

I think this question about +←/√← is mostly pointless. Unassigned characters are just another token class (otherwise allowing ←←1 or )←1 would also be an acceptable question)

@Adám instead of reserved identifiers, reserved characters so kabob-case can't be used

@dzaima Hey, what do you have against ⠀←?

@Wezl I like camels and dromedaries better anyway.

<moon-child> @dzaima yes, but you can't say f←) or f←← either. Whereas you can say f←+. +, like f, is a name that stands for an object, so why can't that name go on the left side of a ←?

@Adám i think there's tension between implementer interests and user interests there. implementers always want to be in full control over + × ⍳ etc, because it makes their job easier, but users want to be able to extend the language or work around bugs, or simply be as creative as iverson was

@dzaima ← shouldn't get it's own token either :) use setq

can you do (setq setq something else)

@rak1507 yes

lol

@Wezl well, yeah. There are 2 reasonable options - 1. no special characters, everything's the same; 2) special chars exist

actually use let, mutability is bad

<moon-child> @Wezl eh setq only works because quoting is a first-class construct in lisp. (setq x y) ←→ (set 'x y). Which implies there must be ''''''x, which doesn't exist in apl

@ngn Depends on which users. I don't think many large commercial users (but you probably don't care about those!) would want that kind of freedom.

@Adám i do care, of course

moon-child: I'm making a lisp-like without setq, only let, and you have to quote its first argument

<moon-child> @ngn +←-⋄a+b should be constant-foldable into a-b. Obv mutability is hard, but rebinding should be ok

@Wezl Another option for first-class inline functions: take a page from BQN and call an inline function if it's enclosed with 〈〉 instead of {}

<moon-child> @Wezl let should be a macro implemented in terms of lambda, which shouldn't need quotes

<moon-child> (as the latter needs to be a special form anyway)

@DyalogAPL <moon-child> preventing users from being able to shoot themselves in the foot is a lost cause! always design to empower the smart ones, not to make life safe for the stupid or deliberately subversive ones :)

moon-child: not necessarily (needing a special form), in conCurr there are no special forms, quote is the only builtin, and it's used by calling nil

I remember in a john scholes talk he mentioned potentially adding ; as 'where', that would be interesting

@rak1507 So ; would have a use outside of separating axes?

<moon-child> @ngn right; I was saying that allowing rebinding of builtin names doesn't necessarily harm implementor freedom much

@Wezl which may have been a bad idea, but it makes it portable between natural languages

@phantomics yes

<moon-child> @Wezl so you don't have macros? If you have macros, then it shouldn't be hard to implement a lambda|let that doesn't need quoting

@rak1507 it should be noted, that was "where" in the haskell sense, not in the sense of k's &x or apl's new ⍸⍵

@ngn right yeah my bad should've specified that

I quite like the idea personally, I think it could be interesting to have a dfn where the first line is a high level overview, and the rest gets progressively more detailed, rather than the other way around

<moon-child> ooh, what's interesting. What syntax was used to bind the names? Something like x+y;x←5;y←6 ?

moon-child: this is how it works currently

@DyalogAPL yeah something like that

youtube.com/watch?v=y33XDD6ANt0 I found the talk, near-ish the end

<moon-child> @Wezl what is :? (Maybe this is too OT)

@Wezl but I'm considering ditching semi-purity and going lazy

30:00

@DyalogAPL moon-child: it is, I'd make a new room if the bridge worked there. maybe #proglangdesign ?

<moon-child> @rak1507 'optional type specification - boo!' lol

lol

<moon-child> @Wezl could bring it up there yah. I think it's already bridged to a discord server

@Wezl I had a question about your bigPix font, it's off-topic here so is there another way to reach you?

@phantomics email github.com/ErmineII/UnMiRa/blob/main/LICENSE

@Wezl Cool

@Adám Is this a known issue with the font?

@MartinJaniczek Try dzaima.github.io/BQN386 instead.

@Adám Thanks, I will. BTW in the same browser the APL385 Unicode on tryapl.org seems to work just fine.

@MartinJaniczek Sure, you can try APL385. Using FontForge on the original has clearly caused some issues.

@MartinJaniczek those some browsers just completely ignore hinting information embedded in fonts. i recall seeing this issue when Adám merged BQN386 into APL386

Maybe I can ask Adrian Smith which software he used to create APL385.

@dzaima (here)

@dzaima Yeah, no kidding, it's not the only problem I have. It seems to break the character encoding somewhere during the roundtrip to TryAPL Exec endpoint. Probably ignoring the charset explicitly specified. Meh, mobile browsers :)

@MartinJaniczek unicode chars in your app thing don't work for me on linux/chromium too

@MartinJaniczek i forgot to reply: thanks, no need for PR as i'm deleting ngn/apl this month

@dzaima Ah, so maybe Firefox vs Chrome thing. I only tried in Firefox on Linux on my PC

Firefox@Android works just fine. Dang, so much for compatibility.

Anyone has any idea why the large title link at abrudz.github.io/ngn-apl goes to ngn's GitHub repo?

@Adám There is <a href=https://github.com/ngn/apl#readme>ngn/apl</a> in the h1. Is that not what you have in your source?

<moon-child> @Adám probably because of github.com/abrudz/ngn-apl/blob/gh-pages/web/index.html#L10

<moon-child> (that is, gh-pages branch not master branch)

Aha.

That fixed it. THanks!

before anyone complains: that is valid html5 :) you don't have to write "" or '' around attributes (unless they contain special chars)

<moon-child> @ngn is anything not valid html5?

<moon-child> HTML5 ::= .*

html5.validator.nu

for instance ⍋ (after the doctype) is not valid html5 :)

Because it is supposed to be escaped as &#whatever;?

No, it can be part of the body just fine

Shortest valid HTML containing an APL char: <!DOCTYPE html><title>⍋</title>

<moon-child> - smaller

<moon-child> because utf8

s/APL char/APL-specific char/

@Bubbler One thing I'd love to track down is which APLer was also a dentist and "invented" the dentistry symbols.