If you're interested in working with fonts, I've very recently been making an APL-alike called BQN with a different character set (see here) and would really appreciate some fonts that support it well. The symbols tend to be simpler, except it uses some double-struck characters like 𝕎.
@matt The idea is to clean up APL by fixing up irregular parts of the language and incorporating ideas like first-class functions and lexical scope that have become mainstream since APL was created (just yesterday, in 1966).
Definitely not a new idea, but BQN does take some new approaches.
@matt One of the bigger ones is to allow non-arrays in the language. APL makes everything an array, with scalars like 3 being 0-dimensional. This is valid, and works really well when arrays always contain basic data (characters or numbers). Then we would say every array has depth 1. But it doesn't work so well (IMO) when you allow arrays that contain arrays. I would say that if you want depths >1, you should also have depth 0, non-arrays.
@matt I obtained "BQN" by moving each letter in "APL" forward by one in the alphabet. I'd come up with the backronym "Big Questions Notation" by the time I realized N doesn't come after L.
@matt It has a different character set than APL, which existing fonts (especially the monospace ones) don't usually support fully. So I'm putting in a request to remember BQN if you decide to make an APL font, basically.
@RGS It may be on a hard-drive I salvaged from my father's home when he died. I used to create my own DOS fonts. IIRC, characters had to fit into 16 rows and 8 columns, but the rightmost column was duplicated, so you couldn't really use it, and 7 pixels wide for things like W and æ and ⍟ is tough.
OK, it looks like there's a bit of unfairness going on over in CGCC - my solution to the Dottie Number problem has been deleted as not meeting the spec, but the exact same algorithm in K is being allowed to stand.
@JeffZeitlin Most likely it's just that someone flagged yours for "not an answer", while they didn't notice the K one or weren't knowledgeable enough in K
I specifically commented back when it was happening that if the APL solution was invalid, so should be the K solution as it was the same solution - and this is ... just being deleted after the discussion being back in March.
@Adám - Yes, and the only reason for the arbitrary precision requirement was supposedly to block it from languages that had the Dottie number "hard coded" (e.g., recognized and optimized, or as a constant in an intended-for-golfing language).
@JeffZeitlin If I had written the challenge, I'd have included "the code should in principle be able to compute the value to arbitrary exactness, given enough memory, time, and numerical precision."
@Adám - Someone who won't be perceived as having a 'vested interest' in my solution - perhaps like Bubbler (or even better, someone who doesn't golf in APL at all) - would get a better response to setting an invalid flag on it.
We can split hairs forever over whether my solution and the problem were handled correctly, but you shouldn't be penalized by someone's arbitrary decision that I'm wrong.
@Adám - Well, one can argue whether there's any such thing as "too much rep", but I get that you really mean "I have sufficiently high rep that I don't perceive it as being worth worrying about". I'm debating whether to bring it up on Meta.SE; I seem to recall that there has been discussion that implies that it's not going to change. Maybe after 16:00 when I come off-duty for the day, I'll do some digging; if I start now, I'll get distracted and be late for work...
@JeffZeitlin Are you sure? Here I'm using a trick to be able to write the code over multiple lines without having to quote everything, but didn't old APL's allow dynamic ⎕FX using a local name?
Honestly, if the need had occurred to me, I'd probably have ended up doing something along the lines of 'inlining' the definition as a charvec, and then ⍎ing it.
Incidentally, while I'm thinking of it... If you haven't already, consider "fixing" the installer/deinstaller so that it gives me the option of leaving the fonts installed if I uninstall the rest of the package.
@JeffZeitlin [saving you the cost of a postage stamp :-)] I doubt if we'll do that .. can you get the font from dyalog.com/apl-font-keyboard.htm instead .. it's the same that's in the release (I put both in place!)
@AndyS - That's not a problem for me; when I get around to installing 18, I'll be leaving 17 in place anyway. But I suggest leaving the fonts because they're available to more than just Dyalog once installed, and you don't really know if I've used them elsewhere (e.g., in a book or tutorial that I'm writing about APL). If I "know" I have them, it's not necessarily going to occur to me to go and download them separately.
Most packages that I've encountered previously don't deinstall their fonts unless there's a very proprietary and restrictive license that they obtained them under; in such cases, they often don't "install" them in the conventional way, so that they're not available outside the program.
@JeffZeitlin Fair point, but on the other hand we like to tidy up after ourselves .. the font should only be uninstalled once you remove the last Dyalog version from your machine.
@AndyS - I like the attitude of "don't leave a mess"; the question becomes "Is leaving the fonts behind 'failing to tidy up'?". I contend that it's not. I could accept, as I suggested, making it optional - during the cleanup, ask if the fonts should be uninstalled.
Another way to look at it is with TMN's f(g(h(x))) where APL simply allows removing the parentheses: f g h x and clearly this moves from right to left.
@Adám who learns mult... AH! Adám, me and matt understood your message as "in school you were taught to do multiplication and then you were taught to do addition" but you meant the precedences, not the moments in time when we were taught those operations
Yeah, like 2×3+4 has × take everything on its right as right argument, i.e. 3+4 which is 7, so the whole thing gives 14.
On the left, they only take the immediately adjacent array (if any) as left argument. If what's to their left is a function or the beginning of the statement or the opening of a parenthesis, then they also stop.
@RichardPark I enjoyed your latest video. I have to say that the number of crashes you get in your Dyalog while working on these problems does worry me
@Adám but that is just because you optimized it under the hood, not because it is really array-oriented
the only point I want to make is that imo, and I would argue the majority of programmers would think in a somewhat similar way, using things like .map() and .filter() and .reduce() is more in line with a functional style of programming, which is also something many people aren't very comfortable with
Functional programming comes (up to an extent) naturally to me but I can't take those skills and convert them right away into array-oriented programming skills :)
Now, I have nothing against that piece of code per se, just wouldn't chain everything like crazy. Probably would introduce one or two intermediate variables.
But functional programming really is a thing I enjoy. I think for a mathematician functional programming can be a really elegant programming paradigm
Note: I could have over-ridden × in the local scope but then I couldn't have used × in the body definition and this is one of my first Raku scripts since getting my toes wet into APL and developing muscle memory for the keyboard so I was too excited to use the Unicode variant of multiplication. Generally Raku code uses *
@Adám as requested, good sir ^^^
@Marshall while I am spamming the APL Orchard with Raku (our symbol is a butterfly, kind of fitting...)
I wanted to raise to your awareness the Native Form Grapheme approach that was developed/followed for Perl 6^W^WRaku to have sane semantics with variably formed UTF -* sequences that are actually equivalent at some desired level of equivalency / case folding\
Not sure whether any of it might apply to BQN but it's by far the sanest Unicode environment I've ever tooled around in. The approach is lossy in Raku but it is trivial to create a class which keeps the original sequence around when you care about the binary equivalence of a round tripped thing-a-ma-jig. Some might call it anti-social to just quit the types of games that other languages play with Unicode by not supporting this kind of roundtripping out of the box.
@RichardPark great APL webinar today! looking forward to future "APL thinking" talks. Curious for the Miota examples, how come you didn't show the simplest solution?
@ab5tract Nice, will keep this approach in mind. It's not applicable to BQN source because there are no combining characters (I wish there were non-combining versions of a lot of the diacritics though), but it sounds good for programming. I think BQN has to use code points as the basic character type so that character arrays can be random-access. However, it should be possible to make a performant NFG library since everything's compiled.
Great! I definitely imagined the BQN approach would be something like this, byte-oriented but with NFG as a "relatively easy" win for the user space experience when desired
it really does make a difference to not be thinking about all the underlying implementation details of the Unicode characters you are dealing with
@Marshall what is BQN's attitude towards Unicode characters in function names?
@ab5tract At the moment, ASCII only. Uppercase/lowercase is part of the language design and I don't want to have to worry about how that works in all sorts of languages now.
@Marshall Looking back, perhaps what I meant by "byte oriented" should have been written "byte-transparent", as I understand that the idea is that it will do no massaging of the characters on ingestion
But I admit, even thinking about thinking about character encodings for too long makes me start to sweat
Which is why I love having the high level sugar, obviously.
We are aware of these issues. We may very well extend ⎕C in the future to do even more normalisation than the basic one it can do now.
If you look at its documentation, you'll see that it only accepts the three left arguments ¯3 ¯1 1 which may seem random and spread out, but that's because we've reserved numbers for Unicode normalisation purposes.
@Adám The presentation on casing definitely let me know that you are all well aware. But Jonathan Worthington is an unsung hero in the language implementation space and so I just wanted to make sure to raise his specific work in this Normal Form Grapheme.
Lots of unsung heroes in the implementation game. I really had no idea about Arthur Whitney just a few short months ago.
I don't think we can ever have NFG scalars in the existing Dyalog APLs. It'd take a split like the Classic/Unicode one, and we're still suffering badly from then. Having an installed user-base and promising backwards compatibility is a huge responsibility.
Ah, I can see what you mean there. Part of the reason Raku took so long / includes the kitchen sink and a house on top too is related to Larry's experience with those very issues.
Better to have important things like DateTime in core otherwise your core is going to depend on some third party DateTime, that kind of thing.
@Adám At any rate, I found the casing demo to contain impressive feats of Unicode processing. Congrats on being on the other side of all that work!
I'll tell Richard Smith. He's the one actually doing the grunt work with all this Unicode and date-time stuff.
@ab5tract One way to look at it is that we've just chosen to do pre-releases for the last 58 years, and now we're almost ready to release. I think 20.0 will be it, basically.
@Adám I noticed the recurring joke by John Scholes about how he had been working on a single program for five decades and it being "nearly finished" in YouTube videos :)
That's also quite similar to Larry and Perl 6. Just cook it until it's ready, even if it takes a few decades! Still, Dyalog clearly has Raku beat here :D
