@Adám but it would fail if it's missing wherever it was executed

and better error sooner than later

whatver, into the load function it goes

(well i guess in the case of namespaces it wouldn't error sooner because Reasons™)

Still. Feel free to do so, but I'm telling you it is a bad idea. Just use a tradfn that loads the data upon first use, and/or and initialisation function that loads all when called.

if the file doesn't exist, trying to read it at a later date is just delaying the inevitable

Maybe I can go as far as to say that namespace scripts are terribly hacky. Don't use them unless you have to. Or feel like it ;-)

just install linux and use #!

Or wait for 18.1 and use #! anywhere.

Hi, a question for those familiar with the [↑ mix] algorithm: what function is used to reorder the dimensional bases for transforming row-major indices of the outer and inner arrays? That may not be clear. so this paste better illustrates the question: dpaste.com/627MXG8QT

Another reason not to do this load-on-fix stuff, is that debugging will be close to impossible.

@phantomics Oh, you mean mix with axis? ↑[ax]

Yes, mix with axis

In the paste, the 0 1 2 numbers on the left show the axis that mix is operating on

@Adám I'd say that's very much a fixable thing though

Like ↑[0.5], ↑[1.5], ↑[2.5]

@Adám (is .apln somehow special over other :namespace declarations?)

@dzaima Yes. Link reacts to .apln files.

@Adám but iirc it also reacted to a .dyalog declaring a namespace?

@dzaima Indeed. And to .aplf and .aplo etc. too.

do they all behave the same?

with default settings yes (except .apla)

ok so code execution in :namespace is as it always has been (i.e. it's a poor man's #!/script)

Kind of.

@dzaima Because Link doesn't actually need to know the contents (except for arrays). It is all handed off to 2⎕FIX to figure out.

(also today finally decided to work more on my matrix bridge, have been chatting from it :D)

(also from a custom chat client because why not)

@dzaima They were never intended to be used like #! scripts, so YMMV if you try to abuse them for that.

In fact, out CEO was rather upset when she found out :Namespace allows arbitrary code execution at fix time.

@Adám besides the issue about multiline dfn operands, are there any other problems? (isn't a namespace what TIO uses?)

@dzaima Yes. Plenty.

@Adám and will #! scripts inherit those, or will it be a whole another evaluation mode (to add to the list of the current ±∞)?

@dzaima Nether. #! is just allowing a text file to supply what you'd type into the session (but with multi-line support and separated input stream for ⎕/⍞).

@Adám would anything break if :namespaces interpreted their contents like that too?

I was hoping that #! scripts were an opportunity to remove some of the bad stuff ⎕IO, ⎕ML, ⎕DIV... but not surprising that that's not the case

@dzaima Possibly not. Interesting idea. Though classes are built on the same system, and they need special treatment.

@rak1507 Heh, you might be surprised!

:O

@Adám do classes allow arbitrary code execution?

yes, just like nss

hehe, the last 2 messages taken without context sound like you're talking about vulnerabilities in nss (the tls library) :)

nss? @Adám

NameSpaceS

@rak1507 They are not being outright removed, but the, imo, worst aspect of those is that you never know what kind of settings your code will be run with, because the end-user computer may have envvars, reg settings, cmdline args, etc. So for #! scripting, we ignore all those.

but you can still set them in the script?

Yes, but you only need to set those you want non-default.

makes sense

In regular code, you have to set all those that will affect your code, so almost always ⎕IO and ⎕ML and often others too.

still think getting rid of ⎕ML in particular might encourage people to port legacy code 'want to use this feature? update your code! insert evil laugh here'

@Adám why

Because it means you can't safely load code to take a look at it. It may erase your HDD.

@nathanrogers it's like if a C header file printed to stdout on importing or something

@rak1507 It'd just make people not port.

@Adám there's no reason they have to use #! scripts

@dzaima you've heard of JAI? That's exactly what the preprocessor does

@rak1507 Right. In fact, why would they?

@dzaima the difference being that the loading and linking happens at compile time

often times you DO want to put out some kind of debug text as part of your precompiler

because what is a compiler if not just another program

I can print in python libraries on import

@Adám they probably wouldn't, but if they ever did want to use it then having to at modernise some code might be worth it for them

or load data on import

or at least if writing any new code, write it in a more modern way

@rak1507 If we were to remove ⎕IO in #! scripts, what would it mean for code that the script would load and run?

@nathanrogers I'm not disagreeing that there should be a way to do things at import time, but more trying to explain the actual purpose of :namespace

the purpose of namespaces in programming is to create... spaces... for names

otherwise normal bodies and blocks of code

@Adám true...

but they share.... the space.... of names

@nathanrogers right. And not evaluate code.

i mean

yes and evaluate code

how is func ← {thing} not evaluating code?

@rak1507 well, it is. ¯\_(ツ)_/¯

like are people just setting variable names to constant ints and charvectors and THATS IT?

here, I have a whole space for names, but I'm not allowed to name anything that might contain evaluation

lol

@nathanrogers you insisted on using dyalog, didn't you? get used to this kind of stuff

I mean, name me a more viable APL

i can't (unless you consider j, k and the similar to be apls)

Sometimes, the conversation here sounds like people are being forced to use Dyalog APL. Really odd.

(And no, none of the people that make it sound that way are locked into jobs that have them use Dyalog APL.)

Thanks for that clarification

@Adám assuming they want to use apl, yes they are kind of forced, though it's not you (dyalog) who forces them

When there are no other viable alternatives

yeah it certainly does seem that way

When the thing that "those people" like has problems that make it difficult to use, yeah you'd think "those people" have a vested interest in those things being fixed

odd, that someone who wants to use a tool wants the tool to work consistently and in a variety of contexts

@ngn How so? Are they not free to use another APL impl.?

⍥

@nathanrogers No, but odd that someone who wants to use a tool speaks as if they are forced to use that tool.

@Adám "assuming they want to use apl"

that's your projection because it isn't the content of the text in question

"I dislike using this tool. Fix the tool for me!"

more like "i'm having a problem how do I move past it"

seems like a pretty bog standard sort of question

what isn't bog standard is ignoring that it is an issue, and deflecting

thenib.com/wp-content/uploads/2019/08/… replace society with APL

I opted for the "write your own" solution, though that's not for most people

@nathanrogers Way more money is made using non-Dyalog APLs than Dyalog APL.

Which ones? APL2? I heard IBM just sold it off

that's fine, I'm not making money with APL, so

@phantomics And APL+

Thought I heard that APL+ is basically orphan now after STSC went bankrupt

@phantomics apl2000.com

@Adám this is the apl orchard, not the dyalog orchard, right?

@ngn Correct.

probably

because they're all over 80

@ngn I didn't mean leave the Orchard. I meant leave Dyalog APL behind.

@Adám ah, ok

Yeah, APL2000 seems to still be healthy, enough that they've told off hobbyists who've asked if they could release an evaluation edition

Do you have any idea what verticals are using it? Insurance?

@ngn Should have been clear from me mentioning "any thing".

@phantomics No, it is all very secretive.

Interesting

@Adám s/free to leave/free to leave it/

@ngn Fair. Sorry.

no problem