No, sorry, it was an expression that I was trying to evaluate

fun behavior - )eding a string vector containing newlines doesn't keep them

@dzaima Wait what?

@Adám a←'123' ('789',⍨'456',⎕ucs 10), )ed a, make some meaningless change, now ≢a has changed from 2 to 3

@dzaima Oh, "string vector" means vector of character vectors. Right.

Would you say it should rather refuse to edit such?

@Adám no clue. probably

@dzaima Seems to be a RIDE (that's what you use, right?) issue. Doesn't happen in the Windows IDE, where \n is then just treated as a normal inline character:

@Adám how about \r\n?

@dzaima Same. Two regular chars.

huh.

so that's why the RIDE protocol sends lines as separate strings - it does indeed request to edit ["123","456\n789"]

unfortunately pretty much everything considers a single line containing newlines to be stupid and impossible

It is just data.

@Adám but you cannot store all lines as a single string

Neither can you a vector of vectors of vectors, i.e. a book.

@Adám each tail vector would also need to include spacing details. And in most digital forms they're either a vector of (character; page; x; y) (or similar), or a single string anways

what happens if you copy&paste the newline character?

@dzaima It breaks the line.

so the Windows IDE breaks the fact that ctrl+a ctrl+c ctrl+v is an identity operation

Yup.

if this is really intentional behavior, the proper thing to do would be to disallow selecting multiple lines & make pasting newlines paste the character form. (of course, doing that would be stupid, but otherwise I'm calling the windows IDE broken)

Feel free to email support about it.

@dzaima (the proper behavior obviously being not needing to rely on non-newline newline characters)

Using array notation to edit such an array would be a better experience, I think.

definitely, but that requires having array notation

It is coming…

IMHO array notation is one thing, escape sequences are another

oh right, how would array help with the newline issue (other than just an ugly '…',(⎕UCS 10),'…')?

It would be exactly that:

('123'
 '456',(⎕UCS 10),'789')

As long as we don't add strings with escapes, then that's the best it can do.

why not add strings with escapes then...

Because the current system is so nice and simple. Doesn't mean we won't, though. We're also looking into multi-line strings and heredocs.

imo "a\nb" is simpler than "a",(⎕UCS 10),"b"

^

Simpler to use, sure, but the documentation for (i.e description of) character constants is currently extremely simple.

^^^ + imo (obviously biased by years of usage) the quote doubling is much more ugly than escapes

Delimited by '. Internal quotes are written ''. Cannot contain line breaks. Done.

Simple use is more important than simple documentation

Not that 'backslash escape sequences exist' massively complicates documentation

What are they, though?

\n, \t, \\, \ustuff that no one ever uses, probably some other stuff

It's standard and well enough understood across languages that pretty much no one would have any issue with its addition imo

@Adám "Delimited by ". Internal quotes are written \", backslashes are written \\, newlines are written \n." Not that much worse. (ofc you can add more escapes, but ¯\_(ツ)_/¯)

^

@dzaima "Delimited by ". " → \", \ → \\, ⎕UCS 10 → \n, ⎕UCS 9 → \t, 13 → \r, ⎕UCS x → \u + hex encoding of x"

@dzaima At the very least you need CRs and nulls, and probably NEL and VT too, and how about a general Unicode format? In hex? Decimal?

@dzaima How many hex digits after \u?

however many is standard

@rak1507 Standard is 4. But that isn't enough!

@Adám ah right, that's a valid question (i had toyed with \-char-literals implementation in BQN, where any length will do)

JS also supports \U{xxxxxx} or something

yeah, \Uhhhhhhhh according to en.wikipedia.org/wiki/Escape_sequences_in_C

It quickly gets hairy.

Not that hairy

Wikipedia has "\xhh…" ― how does that work?

All escape sequences in JS

We definitely wouldn't want that crazy octal $#!+. Does anyone actually use that?

@Adám octal you can indeed leave out

and I think it's fine to exclude \x too

what we need right now is a few control characters and a general Unicode escape, that's all

How about "abc{⎕UCS 10}def"?

Agreed, I can't really think of any other one possible addition that everyone would use

@Adám apparently it goes until the char isn't a hex char. But it errors if the resulting constant is >255, so i have no clue why that's a thing

That would be ok-ish if {} evaluated code so it could also be used for string interpolation stuff

@dzaima That's horrible!

@Adám yep

@rak1507 That was my idea, yes.

I mean, ideally I'd like something like that and \n, but if it was one or the other I'd probably choose that

@Bubbler \x is probably the most useful one though - for codepoints less that 32. For everything else you can mostly just write literals

@dzaima Is it so bad to add two extra 0s for those?

@Adám is it so bad to write log instead of ⍟?

:O

@dzaima Yes, as that makes a reserved (English) word.

Don't get me wrong. We are interested in all this, but as you can see, it isn't so obvious how it should all work.

@dzaima I'm fine using Unicode escape for that

@Adám they're pretty useless. You'd end up with >90% of uses of \u starting with 00

One tradeoff between string interpolation + ⎕UCS and Unicode escape is that one supports only decimal and the other supports only hex

Maybe a better system is one with a terminator, like HTML's.

Proposal: add hex integer literals.

@Bubbler There's nothing preventing \d10. Wonder why nobody has.

I think string escape sequences is something that doesn't need to be particularly innovative and the most productive use of them would be to do what is standard in other languages

@Adám very pointless. And everyone knows the hex codes of important characters instead of decimal values anyways

0x41414141

The problem is that many character resources/lookup tables are in hex

@Bubbler GNU APL has $2a and J has 16b2a.

@Bubbler that'd first require being able to do anything useful with binary-y constants

@dzaima Except APLers used to ⎕UCS ;-)

@Adám that's not much of an argument as there's literally no usable alternative

@dzaima The very first useful thing will be the character codes

@rak1507 Heh, 'abc',0x2a,'def' isn't terrible.

not much better than ⎕UCS

@Adám Not 'abc',(⎕UCS 0x2a),'def'?

@Bubbler No.

Hm, ⎕U2A?

@Adám that'd require breaking backwards-compatibility of x←0, and be extremely confusing to anyone who has used any language where 0x2a would be a number

while on this topic, any nicer way to convert a hex string to decimal than {⎕UCS 16⊥⍉↑h⊂⍨1 0⍴⍨≢h←1-⍨⍵⍳⍨⎕D,⎕C ⎕A}?

@dzaima Right, I forgot that we've painted us into a corner regarding constants. Arrg.

@rak1507 What is the intended input and output?

@rak1507 ^

⋄ {⎕UCS 16⊥⍉↑h⊂⍨1 0⍴⍨≢h←1-⍨⍵⍳⍨⎕D,⎕C⎕A} '7468697320697320612068657820737472696e67'

@rak1507
┌→───────────────────┐
│this is a hex string│
└────────────────────┘

So you treat chunks of 2 as a single char?

yep

sounds easy enough

⋄ ⎕IO←0 ⋄ (⎕UCS 16⊥∘⍉⊢⍴⍨2,⍨≢÷2⍨)(⎕D,⎕C⎕A)⍳'7468697320697320612068657820737472696e67'

@Adám
┌→───────────────────┐
│this is a hex string│
└────────────────────┘

For bonus points: make it invertible (or write a string to hex function that is invertible, same thing really)

Not sure if that's possible

Should be.

Fun way: ⋄ {⎕IO←0⋄⎕UCS(16⊥⊢)⌺(⍪2 2)⊢⍵⍳⍨⎕D,⎕C⎕A} '7468697320697320612068657820737472696e67'

@Bubbler
┌→───────────────────┐
│this is a hex string│
└────────────────────┘

Ah ⌺, nice

@rak1507 dzaima/APL

@rak1507 Hm, won't work unless replacing ⎕UCS with a lookup, as for some reason ⎕UCS⍣¯1 doesn't work.

Right

@dzaima Cheater!

ucs←(⎕UCS⍳256)⌷⍨⊢ or something

Oh for some reason that isn't invertible either, I'm sure I wrote an invertible version but can't remember it, argh

@Adám (⍬2⍴)⍫, is kind of unavoidable. inverse of ⍳ is the 4th item in my dzaima/APL TODO list (and at some point was implemented, but it didn't check for errors so was abandoned for later)

ah it was the other way round, ucs←(⎕UCS⍳256)⍳⊢

@dzaima (heh, ⍬2⍴ could be invertible with leading axis reshape)

@dzaima (also to note is that ⍬2⍴ is invertible in under)

(⍪2 2) is really smart in stencil

Didn't know about that, thanks @Bubbler

@rak1507 But it'll look better with array notation: ⌺[2⋄2]

I'm not even quite sure how that works

the ⍪2 2 thing

The first row is neighbourhood size, the second is step size.

Isn't [2⋄2] the same as 2 2?

Only in dzaima/APL.

@Bubbler unfortunately, no. non-dzaima/APL array notation 1/es expressions

Here, we've prioritised utility over purity.

If you want 2 2 you can write (2⋄2)

Makes sense

@Bubbler What does?

@Adám note that ⍪(1 2)(3 4) is still a bit ugly as [⊂1 2⋄⊂3 4] (and [⍮1 2⋄⍮3 4] is equivalent, so the special case only "helps" in the ⍪simpleScalarVector case, assuming ⍮ exists which it really really really really should)

@dzaima But without ⍮ then it does help in the [⊂1 2⋄⊂3 4] case, which, while indeed a bit ugly, avoids the very ugly [(1 2⋄)⋄(3 4⋄)]

@Adám in that case i'd much prefer [,⊂1 2⋄,⊂3 4]

@dzaima I know, but only from a stand on purity, no?

Of course, all this wouldn't have been a question if APL had a properly though out array notation from the outset, i.e. if people at IBM hadn't ignored Iverson's protests.

@Adám well, array notation still can't represent ⊂1 2 so you have to fall back to code sometimes anyways

@dzaima True, but the only limits are "extraneous enclosures" and and empty axes.

So array notation plus ⊂ and 0⌿ is enough.

@Adám well, they still would've had to come up with something, no?

@Adám I would much prefer ⍮x to (x⋄) in all contexts, whatever that takes

@dzaima Sure, but Iverson already used (1,2,3) for vectors, so it would have been natural to build on that.

I'm not sure how he wrote or would have written a 1-element vector.

@Adám assuming he also used parentheses for operation grouping, that matches the most concrete current proposal (s/,/⋄), no?

@dzaima He did, and yes, except we don't know how he would have disambiguated.

Ah, hang on, he used x for scalars, x for vectors, and X for matrices, so there might never have been ambiguity.

They would have been able to figure something out. Maybe allow a trailing , or something. (42,) doesn't bother me at all, while (42⋄) looks ugly to me.

Oh, wait, (,42) would work.

But of course, with nested arrays, that's problematic.

Aha.

Our pairing of ravel and catenate really doesn't make so much sense. BQN is better there.

If monadic , was instead "add leading axis", then it could work.