I like J's functions because the functions you use most are without . and :, and the functions that do use . and : are usually conceptually related to the function without the trailing char; compare |. with |: (reverse and transpose)
Challenge
You will be given an input string, anywhere the word "Lemon" is found it should be converted to "Lemonade" but the a, d, and e must be removed from somewhere else in the sentence.
Example
Example Input:
I found a lemon when I was a kid
Example Output:
I foun a lemonade w...
@ConorO'Brien Not to let you change meaning of existing glyphs, no. Possibly to allow assigning meaning to unused ones. But management are weary of doing so for fear that we'd want a glyph after "setting it free".
@ConorO'Brien We do allow some national characters in identifiers, and also ∆ and ⍙ and all the circled uppercase letters (Ⓐ Ⓑ Ⓒ…) so there are some possibilities. E.g. one of our utility libraries uses ø.
@ConorO'Brien True, but IMHO, it would make APL unreadable if I couldn't rely on the core symbols meaning what they always did.
@Phoenix No, but we put extreme effort into choosing the "right" symbol for every new primitive, and it would be sad if you couldn't "get" that one because we had set it free.
you could make the redefinition/definition of alternative characters obvious enough so that the one who reads the code know there's some trickery going on
@ConorO'Brien I can't imagine how that would work. Should such changes be global?
@Phoenix Then they wouldn't be available in regular fonts (albeit ugly).
@ConorO'Brien No, not in general. It is a special rule that assignment to ⍺ (which represents the left argument in the dfn type explicit functions) only works if the function was called monadically. Otherwise the statement is skipped.
@ConorO'Brien No, not yet. I've considered it, but being that explicit functions are easy, it is also easy to branch based on valence. E.g., traditional functions can ask the system if they were called monadically with 900⌶: Try it online!
@ConorO'Brien There's also the generalised checking of Name-Class of identifiers. So I can get the type of argument (or indication of its absence) with ⎕NC. Overloading is easy!
@ConorO'Brien Yeah, I've proposed that a dfn explicit function should be able to checks its valence with an extension of the "guard" syntax: {2:'dyadic' ⋄ 'monadic'}
@ConorO'Brien … or {2: result ⊣ second←expression ⊣ first←statement ⋄ result ⊣ second←expression ⊣ first←statement}
@ConorO'Brien Both of these already work. The only new thing here is the 2. Currently, the expression the the left of : must result in a boolean singleton.