@Adám is this a new idea? what inspired the symbol choice?

@chrispsn not that new, it's been in extended for a while

@Razetime ah ty

interestingly enough, ⍛ first appeared as atop. Then, (ignoring this,) this, adding it to Extended (and two days later, dzaima/APL)

@dzaima thanks! love seeing the seed of an idea and how it changed over time

@dzaima (fwiw, ⍤ was mentioned as atop first here)

(thing i use to search APL chars for those wondering)

Was ⍛ ever implemented in Dyalog?

no

from my first message, its first mention was in may 2019, which is "pretty recent"

@dzaima but one could easily implement it as a custom operator, no?

Is there a library of these that people use?

@EliasMårtenson well, of course

How do you make it work? Dyalog gives me invalid token if I try: ⍛ ← {⍵ ⍵⍵⍨⍺⍺ ⍺}

Is there a way to mark a symbol as a valid one-character name?

oh, you of course can't have dyalog just recognize ⍛

Why not? All you have to do is to flag ⍛ as a valid one-character name?

and then Dyalog can't add an actual ⍛ without breaking backwards-compatibility

@dzaima Well, it could. If you flagged it as a custom name, the built-in functionality would no longer be available. But that would be fine, since any file containing such symbols wouldn't need the "new" Dyalog functionality.

that'd come with some runtime penalty on every ⍛ the dynamic parser encounters, i assume

@dzaima yeah, but not too bad I guess? The parser is already quite slow in Dyalog.

@EliasMårtenson it's decently fast for what it is, really. You also wouldn't be able to add custom syntax (e.g. multiline comments/strings, or like anything that's not builtins. iirc i said this in a previous discussion)

Well... :-)

In the context of Dyalog, I'm sure you're right.

It's not complicated in principle though.

In dyalog, are there any one-character symbols that are available for use by users?

@EliasMårtenson no

I guess Dyalog could have a special range of symbols that were guaranteed to never be used, so they were available to uses. Perhaps all the 𝕒𝕓𝕔𝕕𝕖𝕗 letters?

@EliasMårtenson well, in the context of any language that wants backwards compatibility and ability to extend the language in the future

That would be kinda neat.

@dzaima Well, I'm obviously thinking about this in terms of Kap, and it works quite well there. However, every symbol, includig single-character ones, have a namespace similar to how it works in Lisp.

So you can define your own custom ⍳ that is in a different namespace, which will not interfere with the existing implementation.

But Dyalog doesn't work that way, so I was trying to think of ways it could be implemented there, because I like custom symbols :-)

(also IDEs would be very unhappy if you define and use ", and then the language adds it as a string delimiter)

Well yeah, if you define a custom symbol that is later being used as a new kind of token on the tokeniser level, then you're kinda screwed even in Kap :-)

so you agree that no language can have all of extensibility, custom chars, and backwards-compatibility

@dzaima No. I still firmly believe it's possible. But neither Dyalog, nor any other array-based languages that I know of could easily do it.

Arguably, Common Lisp can do it.

is common lisp extendable though?

Very much so.

Or wait, what do you mean by extendable?

@EliasMårtenson e.g. it could decide to add [] as an alternative to () for improving readability (i assume lisp doesn't use [])

Yes, you can.

CL has a concept called the "readtable" that maps a character to a function that is responsible for parsing anything that follows that symbol. There are existing reader extensions that parse [...] as quoted arrays for example.

but could common lisp have an update that just introduces that (by default, everywhere), and doesn't break anything?

That wouldn't really be a problem. You can replace the entire parser if you really wanted.

my point is about whether the base language can, not a user

All you do is switch out the readtable and you can do anything you want. If you want a symbole being interpreted in the "standard" way, you just switch back.

Well, in CL the base language is kinda fixed in stone, and all development that has been done on CL since the 90's has been in the form of user-level stuff, so there is really no difference between what CL can do vs what users can do. Everybody are users.

@EliasMårtenson so that's a "no" to "extendable"

So there is for example a reader extension that allows you to use C syntax. It literally converts the C code to lisp as it's being read, so from the point of view of the caller they are just reading a file, and out pops Lisp code.

@dzaima Is it extendable. If the industry really wanted to release a "new version" of CL, then that would be fine.

It's just that there is no way that'll ever happen since there is no need to. Since the language can be updated using its own mechanisms, there is no need to define a new standard, really.

@EliasMårtenson well, this isn't a question about if it'll happen, but about if any language can do this

Well, I argue it can.

I really can't think of a program that uses custom syntax that would stop working even if there was a new CL. Assuming that the new CL would still be backwards compatible to the old one.

i guess if your way of defining a new entry in the readtable is doable somehow before anything further on is tokenized/parsed, it's possible

@dzaima Yeah. That's exactly how it works. You can inject code that runs as the reader is tokenising the symbols, so the first line in a file runs at read-time (i.e. just after the first form has been parsed), and it switches out the readtable which is then subsequently used for the rest of the file.

The key is that you can run code at different phases in CL, you can have code run at read-time, at compile-time, at load-time or execution-time.

Now that I think about it, the same could be done in Dyalog.

I guess I have to change my mind, I think it is possible to support this stuff in APL.

that means you must have a full read-time parser in your syntax highlighter (aka, my paste would need to implement a part of lisp)

Not sure if it's worth the effort though.

@dzaima For sure. And that's the reason most true syntax extensions are quite limited in scope, and doesn't do stuff like introducing new comment syntax or whatnot. Because they screw up the editors.

and any existing extension would retroactively look ugly if the base language defined it as new comment/string syntax

There is one that introduces the #I syntax for infix expressions for example. You can do #I(2 * (a + 1)) which is then read as (* 2 (+ a 1))

@dzaima Well, that's always going to be a problem with any language that supports custom syntax. But then again, languages that do tend to have very regular basic syntax and doesn't really get changed that much (since there is less demand for it as people can do what they want). This includes Lisp and its cousins, as well as Forth.

also

Woah

OK, that's both confusing and very neat

not quite sure why this doesn't work ¯\_(ツ)_/¯

I'm confused. Why doesn't this work? mlochbaum.github.io/BQN/…

i assume the tokenizer just isn't designed to prefer custom chars to the default ones

which makes sense, since this extended thing was added as an afterthought, not as a core goal

the first line of the tokenizer directly hard-codes the character '#', so you just wouldn't be able to replace it

Is it because x is considered part of a word?

yeah

@EliasMårtenson It's only designed to add characters not in the character set already. So it won't complain, but you'll get undefined behavior. I think since it does lookups with sorting and binary search (dyadic ⍋) it does end up favoring existing characters.

@dzaima SHARP APL used ⍤ for Over (on) and ⍥ for Atop (upon). I think Roger had mentioned these before and Adam just swapped them.

They're in Rationalized APL (1983). I'm guessing it was Iverson who came up with the symbols.

@Marshall Funnily enough, it did work with ↕

@code_report ,'a' instead of 'a'

ty!

@code_report Better solution: {¯1+{≢⍵}⌸⍵,⍨⎕C⎕A}

@rak1507 Enter reexecutes the block, Shift+Enter edits the dfn in the Editor, and <IL> (which I've assigned to Alt+Enter) inserts a line inside the block (in the session transcript) so you can add a line to the dfn.

@chrispsn In APL, underscored glyphs are generally conceptually related to their plain counterparts, e.g. </≤,=/≡, ∊/⍷ (member/find), ⍳/⍸ (index of/interval index of), ⊂/⊆` (enclose/enclose-if-simple). I needed a glyph for something closely related to ∘…

@Adám Alright, cool

thanks for forwarding on xpqz's book as well I will have a look tomorrow :)