« first day (2372 days earlier)      last day (500 days later) » 

02:00
@Adám Definitely hoping to publish more. At the moment I have one that's bouncing around in my head.
 
3 hours later…
05:27
@B.Wilson OK, added.
05:48
@Adám Cheers. How does this work? Do I poke someone every time I post something potentially relevant, or is there an automatic system of sorts?
apl.wiki/blogs is just a "static" list of blogs, not posts. I hope we can get to updating apl.news soon — that's a proper "live" feed of new posts, and would benefit from being notified.
Roger. Would be honored to have that previous article up on apl.news if it makes sense.
 
5 hours later…
10:59
@B.Wilson an answer
also the meta goes deeper
11:10
@RubenVerg "Some of these functions have matching operators in TMN" — What about converse implication ⇐, nonimplication ⇏, and converse nonimplication ⇍?
makes the paragraph too long
also might want to write an article just about Boolean functions
gotta keep some content :)
@RubenVerg Is intentional that your front page says "Madeline talks about stuff she is doing or has interested her", though your name is listed as Ruben Vergani?
oops, listed where?
I thought I put madeline everywhere
eh that's another site :)
I don't think github tos lets me use my chosen name actually
never looked into it though
11:24
@RubenVerg @B.Wilson Shouldn't you also link to @PaulMansour's entry in the series?
@RubenVerg What name do you want on APL Wiki's blogs page?
oo i'm going on the wiki that's an honor :)
Madeline Vergani is my full chosen name, I'd rather you use that one
@RubenVerg Hahaha! Starting a blog-off here. Very nice.
@Adám Should be in there already, "Paul Mansour makes a head start in his Boolean Techniques article, but I think we can go all the way:"
Indeed so. Sorry.
@RubenVerg Surely, your's should begin with "Recently, Brandon Wilson posted a nice article discussing a nice article discussing a nice article discussing a a way in which APL's algebraic properties absolutely shine."
11:58
@Adám I'm just hoping someone else replies to mine to keep the chain going
if @B.Wilson changes theirs to be two-levels deep, I'll change mine to three
Surely, there can only be 16 entries in this series, of which 4 are one-sided and 2 are trivial /jk
I suppose the least useful entry of the sixteen can be classified as 0⍨ and the most useful as 1⍨
12:12
on a scale of 1 to 15, how awful of an idea is it to start a series of articles about writing a tiny apl interpreter in {insert language}?
probably haskell, not sure though
I have a somewhat working Scala-implemented dialect, but I kinda wanted to start over in haskell and it might be interesting to publically document my progress and maybe turn it into some sort of tiny course
oh that series is ordered very differently than how I would order mine
I'd go
* implementing APL arrays/verbs/modifiers in haskell (1/2 articles)
* implementing haskell functions for working with arrays and verbs (several articles)
* writing a parser and AST (maybe two or three articles)
* executing the AST (a couple articles)
* extending the available functions and operators
I suppose not having a working interpreter until later in the series might make less people care
I don't really mind that, I'm mostly doing it for myself anyways
explaining things properly helps me making them less awful
 
1 hour later…
13:46
@RubenVerg Could be interesting! I've toyed with the idea of wanting to build an APL, but then I realized that really I'd rather be writing APL. So... APL in APL? But then we're bashing up against co-dfns.
It'd be cool to have a bare-metal APL. I've also thought it might be cool to write a Forth backend for co-dfns just for that.
14:09
instance Show Array where
  show (Array sh cs) = "{array with " ++ [G.rho] ++ " = " ++ unwords (map show sh) ++ " and " ++ [G.ravel] ++ " = " ++ show cs ++ "}"
not implementing proper display of arrays seems slightly like a crime to me
14:26
Implementing an APL is a dream of mine
Someday, perhaps
I still need to... you know, learn APL
KAP in particular is pretty interesting to me. I think lazy evaluation is exceptionally powerful given APL semantics
I also thought about something with Lua... I know Lua⋆APL exists but it's not even close to April as far as I've seen
14:46
@AndréLeria I think I know just enough APL to start doing a toy implementation
but then I also think actually implementing it would be a great way to learn more
I believe so
@AndréLeria I fear my implementation will be accidentally lazy because, you know, Haskell
I'm pretty hyped with my idea of a "TPL" (since Lua uses "Tables" instead of arrays) but then again, I hype easily and un-hype just as easily
@Adám I was really hoping aplan was the next iteration of Extended/Vision with a punny name (portmanteau of APL and plan), but this is cool too
15:41
@RubenVerg Vision is still the active WIP one.
I know, would have been a cool name tho :)
 
2 hours later…
17:20
Hi, quick question. I observe that
'p' ≡ ⊆'p'
How can one enclose single characters?
Such that the comparison is false
@SantiagoNuñez-Corrales You cannot. However, you can enclose a 1-element character vector.
What I am trying to do is, given a list of prefixes generated by
pfxs←{⍵∘ith_pfx¨⍳(≢⍵)}
and then I would like to compare each resulting prefix of non-zero length against a string
which works for prefixes of length equal or larger than 2
'te'∘≡¨ pfxs 'test'
0 1 0 0
What am I missing?
ith_pfx←{⍺↑⍨⍵}
17:59
@SantiagoNuñez-Corrales I suppose you've been doing 't'∘≡¨ pfxs 'test' but 't' is a scalar. You don't need to enclose it, you need to ravel it: (,'t')∘≡¨ pfxs 'test' will work.
(cc whoever cares) I have a very rough first draft for the first article in the tinyapl series, any opinions?
I think the biggest issue is that it is too code-heavy
I don't know what else to add though, I think the code does kinda speak for itself
I'm not sure you can actually read non-prod deployments or if it is something only I can do
I can read it (but not understand it).
oh right there's a haskell prerequisite I have no idea how to solve
I think one of the many benefits of Haskell is that it's easy to see what it's doing even if not exactly
Simple: Implement Haskell in APL first :-)
18:13
but maybe that's just me
@Adám is that not already in the dfns workpace? :)
Very interesting @RubenVerg. I wonder how various structures (applicatives, functors, monoids) will appear in your code as TinyAPL is fleshed out, particularly with operators.
I'm somewhat scared about the part where 3/4 of my functions will live in IO, I won't like that :)
@SantiagoNuñez-Corrales anything I should fix?
You'll definitely want to avoid hybrid function/operators.
of course :) in my roadmap I have, in big bold letters, "/ is reduce and is replicate"
(both first, ofc)
And no bracket axis. Tiny after all.
18:20
So far, the code looks reasonable and self-explanatory. Interfaces do suggest the type coercion observed in APL. I am eager to see how it progresses :)
The monadN2N pattern seems quite handy as written
I don't really like having do for monadN2N but also it makes it more symmetric to dyadNN2N which would be somewhat ugly without do notation
It is a trade-off for sure.
But finding and exploiting symmetries is probably more valuable than a more principled approach.
unerror, yes, unfortunate
I was considering a Prelude alternative with safe functions but eh
ambivalent operators aren't a thing, right?
Ken Iverson said no (dl.acm.org/doi/pdf/10.1145/357073.357074, pp 169)
But, not sure about contemporary implementations
@RubenVerg No. DyadicOperator Function makes Monadic Operator.
18:32
operators can be partially applied??????
@SantiagoNuñez-Corrales just wanted to check if nobody does that or if only I won't :)
@RubenVerg Yes, so you can write twice←⍣2 or onMajorCells←⍤¯1
cool
only on the right tho?
Yes, in Dyalog it is so.
so can't do f←+.
Sometimes I prefer parenthesising the operator with one operand, if they form a logical unit (like the above two).
@RubenVerg No, and you can't even do because . is special.
18:34
oh right
I also am definitely not doing that
I'll pick some generic symbol for outer product (probably squared plus) and keep dot for inner product
You could also just make dyadic f\ be outer product.
@RubenVerg Isn't it simpler to also not use . for inner product, to avoid parsing issues vs numeric literals?
hadn't considered that
If I could start over, I might use a high dot for it: f˙g
I already have 𝑗 for complex numbers to disambiguate 1j2 from 1 j 2
(that's the unicode for italic small j if it doesn't render properly)
What about exponent form numbers? 1E2/1e2?
18:39
I think I had subscript 10 in the back of my mind, haven't really decided though
@RubenVerg I think 1𝑗2 looks odd. How about 1ᴊ2 and 1ᴇ2?
(in the article you can also see 123𝑖 for pure imaginary numbers, not sure I'll keep it though)
@Adám I think it might look fine with the right font
1⏨2 could work. iirc, some graphing calculators use that.
it's about as odd as 1j2
@Adám yep that's the inspiration
@RubenVerg Seems odd that the imaginary part swaps to the other side. Should be 𝑖123 if anything, but then again, why not just 𝑗123 (or ᴊ123) just like many allow .5 instead of 0.5?
18:42
although mathematically equivalent, i123 does look rather odd
Agreed. I think it looks less odd with the small cap.
Anyway, these are details. Just makes sense that you could write 1. and .5 for 1.0 and 0.5 and then also 1ᴊ and ᴊ2 for 1ᴊ0 and 0ᴊ2.
So too 1ᴇ and ᴇ2 for 1ᴇ0 and 1ᴇ2 (?)
But hey, if you're creating a minimal implementation, maybe just require the full syntax for everything…
yeah that's what I'm concluding
I'll just have a, a.b, a.b[imaginary symbol tbd]c.d and a.b[exponent symbol tbd]c.d and negatives

« first day (2372 days earlier)      last day (500 days later) »