« first day (1829 days earlier)      last day (833 days later) » 

12:01 PM
is there a way to check the C code equivilant of a apl code? like whatever the apl interpreter writes to c then to asm. my friend and i are discussing apl and optimizations
like my friend and i are confused how some apl code can be so fast. so having a way to see the "compiled"(?) version would be awesome
his exact wording:
can u get directly c output from apl compiler u got?
 
not exactly.
you can view the bytecode, but it's not very helpful.
as it's just tokenised source code, after all
additionally, Dyalog APL is interpreted. if you use something like CoDfns, then you can peek into the output, but i'm not sure how exactly.
to measure the performance you can use cmpx.
 
hmm alright thanks. sad. i wish it was possible. maybe some c programmer could figure out how to write really efficient code inspired by apl
 
well, there was a talk by roger hui about sorting/maximums
roger hui basically implemented counting sort in C which was a direct port of an APL solution
sadly stuff like this isn't really relevant nowadays. loop unrolling is a thing and vectorisation is a thing too
it's more efficient to do a "dumb" maximum of a vector than use Roger's method since CPUs sometimes work better with straightforward algorithms that describe what they want to accomplish and not what they want to do
 
lol dumb code is done faster in some cases. thats funny
 
@BrianBED on assembly level? of course not. but the compiler can optimise it to perform better.
this is why I believe that languages like C or Rust have no future and we all will be writing incredibly abstracted languages for maximum performance sooner or later.
when you're given an illegible mess of bit operations as a compiler you have no choice than maybe playing with them a little and emitting what you have. if the code author literally tells you what they want to accomplish you have many more optimisation options.
and APL & friends takes advantage of it because they're incredibly high level and also they're a tool of thought natural for humans.
 
12:14 PM
yaaaa the way symbols work in apl is sooo awesome. the efficency is just a pluss!!
 
a simple example - if you sorted a vector in C, you would probably pick something like mergesort. but counting sorts and insertion sorts are better for non-sparse/small vectors!
APL can take advantage of it and pick an algorithm depending on the input data.
it's not particularily important that currently APL's performance sometimes isn't as good as it could be, because it has so much potential for improvement.
 
@KamilaSzewczyk eh, that's more there being a standard library than a difference in languages
 
hm interesting. wait apl can be compiled tho right? is it even faster then?
 
(personally, i think that some decisions or core ideas burn a few optimisation bridges specifically in Dyalog)
@BrianBED well, not exactly. APL isn't strict enough to be compiled in the conventional way.
@dzaima interpreted/jitted languages can also take advantage of various processor features that might or might not be present, additionally, they can deoptimise and recompile bits of code on demand.
 
I think the example of where APL can be much better than C is integer width in arrays being dynamic. e.g. 1 2 3 will be an array of 8-bit integers, and whenever an operation needs more bits than that, the interpreter just changes the type
 
12:18 PM
this is what the JVM does for improving the performance of virtual functions, among others.
 
wait so dyalog cant compile apl code? or does it just not compile it efficiently?
 
dyalog sometimes pre-parses code.
but no compilation is done since APL can't be compiled for dumb reasons.
 
hm what dumb reasons?
or is it complicated?
 
the simplest one being presence of eval in the language.
 
OOoooh
 
12:22 PM
APL is a bit too dynamic to be compiled
 
@BrianBED there are way too many things a given builtin call may be - a+b could be any combination of 8-bit, 16-bit, 32-bit integers, 64-bit floats, complex numbers, a nested array. That's at least 36 different cases, and you won't know which it is at compile-time, and compiling every + to 36 loops is just stupid
 
that falls under "isn't strict enough"
but again i don't think i'd enjoy typed APL with various integer types.
 
my friend wants to know if apl is a "script language" or not
idk what that means but uh maybe you guys do
 
you can use APL for scripting.
you can use APL for everything for some reason.
can do OOP, tacit programming, functional programming, imperative programming, backend, desktop apps, cli programs, scripts, but i usually use it for messing with mathy or CSy stuff and nothing else
 
now, JIT-compiling, on the otherhand, could actually be beneficial, at runtime fusing multiple loops together for the specific types encountered. But that's pretty damn hard to do.
 
12:25 PM
whats JIT-compiling?
 
In computing, just-in-time (JIT) compilation (also dynamic translation or run-time compilations) is a way of executing computer code that involves compilation during execution of a program (at run time) rather than before execution. This may consist of source code translation but is more commonly bytecode translation to machine code, which is then executed directly. A system implementing a JIT compiler typically continuously analyses the code being executed and identifies parts of the code where the speedup gained from compilation or recompilation would outweigh the overhead of compiling that code...
 
@KamilaSzewczyk not sure about this. Programming “to the metal” has the great advantage of forcing you to be frugal. Today’s overbloated, overlarge, overfat, overslow application are a direct result of HLL’s and many layers of libs and frameworks.
 
that's more of a skill issue between programmers than anything. i don't consider most contemporary HLLs well-designed.
i spent way too many years writing C and x86 assembly all day
 
@KamilaSzewczyk eh, there are things that are really hard or impossible to abstract away. And abstractions will necessarily lose performance by disallowing the programmer to write precisely what they want
 
For many use cases, programmer efficiency matters more than application efficiency. That's why Python sits in such a sweetspot. Easy to get up to speed, libraries for pretty much everything, and if you really need speed, someone will have written a library in C for that that you can use.
 
12:35 PM
@dzaima ideally the programmer states what they want, and the compiler makes it efficient.
and my vision of future is somewhat remote
 
@KamilaSzewczyk that would be easily treated as an exception by the compiler and passed to an interpreter or JIT compiler. eval alone doesn’t sound a convincing reason for not compiling.
 
abstractions are meant to make the code more expressive
 
@xpqz well, python isn't the "C or Rust" that kamila says has no future
@KamilaSzewczyk The best optimization tool is wanting things that can be efficiently done in the first place. Abstractions make that not really a possibility
 
how so? in my eyes, it's much easier to optimise a bit of code that calls sort(vec); instead of it having a mergesort implementation between the lines.
 
@dzaima Sure -- was mainly pointing out that "today's overslow applications" due to HLL is a pretty deliberate trade-off.
 
12:38 PM
the thing here is entropy and how much you're losing it if your code imperatively performs some operations
something is irreversibly lost when you change a general concept to it's particular instantisation
since they differ in, inter alia, behaviour and specifics.
the compiler has it's hands tied because it often can't change the algorithm.
 
@KamilaSzewczyk i mean of course there should be a predefined good sort somewhere. That's not really an abstraction though, just a sane stdlib
 
sort in the stdlib still has code backing it. a certain implementation of a sorting algorithm at least.
it might allocate an additional buffer which neither C nor C++ optimise out because you're invoking a syscall and writing the RAM, while the compiler decides "hey, sorting this vector isn't really needed here!"
a C compiler will never come up with an optimisation like this.
high level optimisations can be performed only on high level code and they're often the most important factor.
the times of an O(n^2) algorithm in assembly being faster than O(log n) in Pascal are long gone and i don't want to see them coming back
 
A friend of mine, who I taught programming for his first years, always asks me "what about the performance?" when I tell him about a language/library/framework I learn about
Over the years I learned to tell him "you really shouldn't care about performance until you do"
 
@xpqz I agree. Even though Python is not perfect, it has a fairly clean syntax with less syntactic overhead than other C-like languages. It can be compiled (with some restrictions). APL could also be compiled in a similar way, if it had even a fraction of the Python market share. It’s all a matter of having enough smart people investing enough time on it. APLers strike me as a smart, but very small, bunch.
 
(we're primarily frontend programmers)
 
12:43 PM
@dzaima but even then, for your data maybe a specific sort would perform better. (i guess you could choose a sorting algorithm based on profile-guided optimization, but idk, it's pretty fragile as people won't often have good tests for it)
 
and, well, while you could spot that something doesn't need to be done in your C codebase, it'll take you more time since C is less expressive than different high-level languages. you might not even notice it
 
We're no longer in the 90s. Our pocket devices have more processing power than some desktop computers from back then. We can allow ourselves not to care about performance, until that becomes an actual issue
 
oh btw, is dyalog also writen in apl aswell? like i know it has a lot of c code but i wonder if they programmed some symbols/gui in apl. did they?
 
you can write assembly code by hand, but it'll be often slower than what the C compiler generates. because registers are abstracted away, among others.
you'll never allocate your registers better than a LTO graph coloring algorithm, pinky promise :)
 
@BrianBED Some parts of it are, i.e user commands. I think(?) a handful of primitives are too.
You can model APL in Dyalog, at least
 
12:46 PM
@KamilaSzewczyk i have trouble believing that, besides a variable of the sort result literally being unused, there's anything that would seriously be able to utilize that
 
Oo thats cool
 
@KamilaSzewczyk I could, however, place non-volatile register push and pops in a function better than clang
(and i've seen clang generate an unnecessary mov in a small loop with a branch to a slower case that jumps back; yes, that slow case was __builtin_expect(cond,0)ed)
 
@dzaima what if you want to compute the median of a big vector which is already sorted? the compiler can figure it out if the language is abstract enough, but the compiler doesn't really know what a sort is! all in all, it's just randomly poking stuff into memory.
@dzaima and i never argued contemporary compilers are good :)
you outsmarted the C compiler once or twice, but that's because it probably didn't see something, because C as a notation obscured it too much, while you had a clear idea of what you want to accomplish.
 
@AndréLeria …only if you get something in return for the performance that you leave on the table. Programmers’ productivity is a good reason, sloppiness is not a good reason. Alas, many programmers don’t know or don’t care enough about what’s going on in the actual hardware machine. (Not talking about this group, obviously.)
 
I agree
 
12:50 PM
@KamilaSzewczyk if you put the sort and median calls not in the same function though (which you probably would), you lose that.
 
@dzaima I don't. Smart control flow analysis + the median function being module-local would help.
it's possible to optimise it out, just not with what we have currently.
 
@AlexB What I mean is, bad code using Svelte will still run slower than good code using React, for example. That's why you shouldn't worry about performance when choosing libraries and frameworks, unless it's an absolute necessity
 
@KamilaSzewczyk a clean tight loop and a __builtin_expect is most definitely everything a compiler would need to prioritize the loop for optimization. C literally doesn't play a part in this
 
well, you didn't show me the code in question so i've made a few assumptions
 
also, i'd rather have the language/IDE give warnings when I'm doing something time-complexity-unoptimially, rather than have it be quitely optimized away (and then potentially fail to optimize it if the code changes, e.g. by splitting into multiple functions)
 
12:54 PM
that's because you're used to using limited tools and treating the compiler with suspicion
it's hard to think out of the box in contexts like these because there's no tangible proof
 
@KamilaSzewczyk I have trouble believing that even a Sufficiently Advanced Compiler would be able to realistically do cross-function high-level optimization with any amount of useful results. And I definitely will say that it won't do so with precisely 100% precision
 
this largely depends on your notation. some code is easier to reason about and some isn't
a C compiler will never do that
 
but none can be reasoned about with 100% certainty, if it's turing-complete
 
of course it can't :)
but most programs aren't if(halting_problem_true()) a(); else b();
 
and thus, suspicion
 
12:59 PM
that's why e.g. purely functional languages are restrictive
no recursive types, no dependent typing, no imperative smells
it's easier to reason about the code this way
both for the compiler and the user.
 
@KamilaSzewczyk i mean, not precisely that, but there are pretty complicated things you could do - say, appending to a sorted array. To be able to keep the sortedness property for median calls, you'd need to statically make sure that the appended element is always greater than the max already in the array
 
wait isnt apl mainly a functional programming language?
 
APL is very far away from being purely functional
 
@dzaima and that can easily be impossible to know if the data comes from some outside source that you, as a programmer, know will be sorted, but the compiler won't
 
@dzaima if there is a way to optimise it, the compiler could figure it out.
you could use annotations and hints for the compiler if you absolutely needed to.
 
1:01 PM
hm alright. tbf i dont even know the definition of a functional programming language. in my mind it was just a language that uses math more than if statements but thats not that good of a definition
 
@KamilaSzewczyk at which point you're not any better than just writing what you intend to be invoked in the first place
@KamilaSzewczyk that's very much a "sufficiently advanced compiler will save us all"
 
@dzaima that's just an optimisation hint. no need to write the entire code backing it yourself
@dzaima one day it will, but the day is in the remote future.
@BrianBED "functional" is a very fuzzy term. generally you want to avoid explicit loops instead using recursion, they're often lazily evaluated, offer first class functions, anonymous functions, tacit programming, sometimes they offer advanced type systems
 
@KamilaSzewczyk why is the alternative to generic high-level unknown-algorithm calls implementing things yourself, and not calling a high-level known-algorithm stdlib function?
 
@KamilaSzewczyk hm alright makes a bit of sense
 
@dzaima i'm not sure what you're proposing?
if sort has constraints on what it does and is present in the standard library, then why not i guess.
ideally you wouldn't describe the sorting algorithm, only what you want - which is yielding the sorted vector, and the compiler would figure it out.
 
1:06 PM
@KamilaSzewczyk your proposal is to do median(vec) in your ideal lang, and everyone else needing to manually implement a median sort. My proposal is you just call median_sorted(vec) or median_unsorted(vec) or something
(ofc median is kind of a weird example for that, but whatever)
 
that's what (to a large extent) C++ does nowadays
but this greatly obscures the code, since you could totally change your caller to stop sorting the array (for some reason) and then your code breaks...
 
also, we have a case of a language being very generic and not specifying any algorithms, and there being a need for tons of optimizations - SQL
 
also the devtime of my language would be cut drastically - it's a good thing about it which can't be ignored
 
@dzaima and even with SQLs extremely limited scope, and being able to plan at runtime for the data, it is still very much a mess and it can easily misoptimize
 
i've heard about the horrors of contemporary database engines
but again - i'm speaking of theoretical future, not our current solutions which obviously suck.
 
1:11 PM
@KamilaSzewczyk of course, in your lang it'd end up sorting it on the median call instead. And, assuming the compiler can't insert a permanently stored sorted array on the heap, it'd have to sort for every median call if a function getting the median is called many times
 
Lessons 19 and 20 added to xpqz.github.io/cultivations
 
@dzaima strength reduction and memoisation are already known optimisations.
 
@KamilaSzewczyk I would not want a compiler to memoize things and store them on the heap willy nilly
 
of course sometimes you can't optimise your code this way because you know e.g. about the input data while the compiler doesn't
and in this case there's no other way of solving the problem than telling the compiler about it's specifics via annotations.
 
if you call the median-getting function only once, the sorted array being stored on the heap is horribly inefficient
 
1:14 PM
well, yes, of course
but the compiler ideally wouldn't do it.
it would depend on how do you call the median function.
it's not C where you can take the pointer to one function, add something to it, and then call the median function indirectly to troll the compiler
 
@KamilaSzewczyk I'm imagining something like there being a structure for a thing you want to get statistics on, and there being a function getMedian. Pretty much everything would call getMedian only once, but there's nothing technically preventing it from being called multiple times (e.g. reading a config file that has two rows of "getMedian")
 
so your behavior greatly depends on the input data obtained by the runtime.
the compiler theoretically could generate two versions of the function - one that memoises, one that doesn't.
 
@dzaima I as a programmer would know that there's zero point in optimizing for mutiple getMedian calls. The compiler won't. But if you just trust the compiler, it could easily do the wrong thing
 
you're forgetting that my compiler is Sufficiently Advanced :)
of course there could be inefficiencies in this case introduced by the compiler not knowing anything about the input data, but you could instruct it about your input data and providing it the necessary knowledge to spew out an efficient program.
 
@KamilaSzewczyk you won't know whether to memoize on the first getMedian call though, which is where you do need to know
 
1:21 PM
why?
the compiler would see that you're calling in a loop that depends on something (contents of a variable read from a file)
and insert a runtime check that diverts the control flow to one or the other function
you'd still have profilers and you could still perform some optimisations by guiding the compiler via annotations through stuff that it can't know.
 
@KamilaSzewczyk you'll only know whether you need to memoize on the second getMedian call, but you need to know if you need to on the first
 
but what's the point in manually optimising stuff that it does know?
@dzaima but if the config file has two rows, surely you'd know?
maybe a better example here is data transferred over the internet in an obscure format.
in which case you as a human don't know if you want to memoise or not either
 
@KamilaSzewczyk yes, but if it has a thousand and you haven't loaded it all, you won't. Even worse if it's multiple gigabytes from including some data too, and there being a getMedian at the start, and another one potentially gigabytes down
 
and if you know, then you can just enforce one solution or the other.
@dzaima yeah, so it's the streaming case.
 
all I'm saying is that relying on a compiler to make optimization decisions on things it might not precisely know is a bath of footguns
 
1:26 PM
you as a programmer know that e.g. memoising is bad in this particular case (or you've observed it via profiling/compiler reports), so you disable it using #[no_memo] and go further while a C programmer is trying to get that one triply nested for loop right having segfaulted thrice already.
 
again, there can exist better languages than C
 
like my theoretical language, for example :)
 
that don't necessarily need a Sufficiently Advanced Compiler to be sane
 
well
i don't think either of us will live long enough to see the Sufficiently Advanced Compiler thrive
 
Isn't there Scala for an example of good abstractions, good performance (for a JVM language), but horrible compilation time?
 
1:29 PM
@KamilaSzewczyk you have to know that there may be automatic memoization in the first place, at which point you need to know the whole internal logic of how the compiler works, which is quite a bit because it's Sufficiently Advanced. (or look at its optimization notes, but that's time wasted)
 
I guess there's also Rust but I'd argue against it's good abstractions.
@dzaima i guess that this might be a fair point
with memoisation being a risky optimisation
but maybe we can leave the decision to the programmer after all, and make it easier to turn on memoisation.
so that very little time is spent on tiny nitpicks and programmers can focus more on high level optimisations
 
if god wrote C, would it be better code than if god wrote in apl?
 
@BrianBED optimal C would look like char[] asm = "[a bunch of random characters and escapes]"; int main() { return ((int(*)())asm)(); } :)
 
haha
absolutely
but i think you meant char asm[]
 
yeah too used to java (or sane syntax in general)
 
1:36 PM
@BrianBED APL already looks like old testament angels, perhaps angels were programmed in APL
 
Now show us optimal APL :)
 
lmaooo
 
@FawnLocke something something ⎕NPUT something ⎕SH
 
Genius
 
d⍬ n⍬⌈ b∊ ⍺f⍴⍺⍳d
 
1:38 PM
@dzaima i think that sometimes executing the assembler would be slower than an APL implementation :)
but it's sometimes not the case.
 
@KamilaSzewczyk lol
 
i was shocked to discover it's faster to shell out to PHP and do regex stuff there instead of using <regex> in C++
 
how do i use the "]keypress" thing to record keypresses from the keyboard? i've looked in the apl 1.12 manual and i frankly have no idea how to use it. all i need is a function that has a output based on what key i press on the keyboard
 
2:20 PM
@BrianBED If you can get the built-in compiler to compile your code, then yes:
      avg←{(+⌿⍵)÷≢⍵}
      2(400⌶)'avg'
      4(400⌶)'avg'
Dump of bytecode for avg:
  0000: 00000012 // version 18
  0001: 00000000 // localised system variables: none
  0002: 00000201 // 2 slots
  0003: 00000002 // 0 uslots
  0004: 00002005 rel Larg
  0005: 00000F46 cpy slot[0], Rarg
  0006: 00001F24 eval 0x1F // ≢
  0007: 00003F11 tokoff 003F
  0008: 00000E45 mov Rarg, slot[0]
  0009: 00003BC5 cpy PFUNCTION, rawlst[1]
  000A: 00002E66 mov slot[1], Rslt
  000B: 00000024 eval
  000C: 00003A11 tokoff 003A
 
that just calls the functions contained in the function though, e.g. eval 0x05 // ÷ is the whole ÷, even though division of two arbitrary APL objects is quite complicated
so that doesn't do much to make APL faster, besides scalar code which you shouldn't be writing anyway
 
ohhh is that replying to if apl code can be compiled? i thought he was replying to my question on getting keyboard inputs lol
 
@BrianBED you can click the arrow to the left of a message to see what it's replying to
 
ahhh thanks
 
@BrianBED As FawnLocke wrote, user commands and various tooling (SALT, Link) are pure APL. Some parts of the Windows IDE and its GUI are in APL, and internally, some algorithms and primitives are in APL too.
 
2:28 PM
ah cool
 
@BrianBED Not sure what "1.12" is but if you're on Windows, just enter ]keypress and you get a GUI.
 
i dont get any gui popup
well atleast on RIDE
ok yea also nothing on dyalog
 
Are you on Windows?
 
oh and to clarify, yes im on windows 10. and by 1.12 i meant the manual i read was apl 1.12
 
Still no idea what 1.12 is.
 
2:35 PM
hm it doesn't matter. just the dyalog version i was reading documents on
 
I'd maybe try it from the normal IDE, not RIDE.
 
yea i did. still doesn't work
NO
now it does
thanks
 
:-)
 
:D
 
 
2 hours later…
4:25 PM
@AndréLeria Scala’s compilation time isn’t horrible anymore
Also, incremental compilation helps
I’d argue about good performance though, idiomatic Scala is probably a bit slower than idiomatic Java in many cases
 
4:44 PM
Is there a way to have ⎕R to return a list of each replacement, rather than the full thing in one?
'ab' ⎕R 'ba' ⊢ 'ab ab'

gives:

'ba ba'

but I wanted:

('ba ab') ('ab ba') ('ba ba')
 
 
1 hour later…
5:52 PM
how does FORTRAN compare to apl interms of preformance?
so like apl is better than c in some cases because of high level optimizing but FORTRAN is also high level so i'm curious, because fortran is also a language that is popular for its efficiency
 
you can't really compare the performance of languages. You have to compare effort needed to get certain performance. APLs big thing is that it makes it most trivial to write code that will vectorize easily. You can achieve that in C and fortran, but you have to be more careful about how you do it (idk much about fortran)
 
@dzaima fortran has vectorisation things like apl
fortran is much more like apl than like c afaik
 
@rak1507 hm it appears so
 
does fortran have array manipulation like apl??
 
not to the same extent but some of the basic stuff
 
6:04 PM
hm interesting
 
it seems you can just for example do array1 + array2 (i'm looking at this)
 
huh that's pretty interesting
 
nothing fancy like rank op though ofc
 
@rak1507 right, you kinda have to just loop for it, so making that explicit is good (there are fancier things you can do for a dyadic call and small cells, but you just shouldn't do that)
 
@dzaima true
 
6:13 PM
APL is kinda meh for imperative/iterative things when you need them, so has to fit everything under array-y regardless of whether or not that's the performant thing to do
 
yeah, I imagine that's something where fortran will be much better
 
biggest diffrence is prob syntax :p
but still, syntax is a pretty big part of apl. like iirc one guy (can't remember who) said he liked apl because of how all his code fitted on one slide, and how because of how simple it is he was able to decrease the size and improve preformance exponentially. also golfing apl is prob wayyyy more fun :)
 
6:28 PM
Well simple syntax doesn't mean much without simple semantics, which is where a lot of people actually like APL
Still, typing and mentally parsing less is a plus
 
@dzaima this has always puzzled me - is there anything stopping APL in principle being no worse than any other dynamic language at iterative things, say like Python? Or just a lack of interest/focus?
 
The problem is that if there's an "easier" way for traditional programmers to do something i.e write iteratively or use ascii instead of Unicode. 99% of programmers will use that. In order to preserve what we think is valuable about APL we have to choose not to include those features
At least in my opinion
I don't think it's a technical limitation, though
 
@xpqz having dynamically typed features like namespace fields/⍺⍺/⍵⍵/⍺←/ is the major obvious one. Then there's lack of need because you should be using arrays, and lack of things to optimize because there isn't much in the language that can even do imperative well
it's my intention with CBQN to get somewhat decent scalar performance though (it's already better than every arraylang i've gotten to compare to)
 
wait if i made a python discord bot use the apl eval and didnt include the ⎕ symbol and ⍎, would it be safe? i think i might just use tryAPL. oh actually is there a API for that?
 
You should use TryAPL, and there is an API for it, yes.
 
6:38 PM
OOooo YES
 
Alternatively you can build APL as a shared library but that's significantly more involved
 
TryAPL uses this to execute APL safely fwiw (and yes that's pretty much just fancily limiting characters you can use)
 
@FawnLocke i have no idea what that means so i assume its way above me :)
 
It's not that complicated, just annoying depending on your language
 
 
4 hours later…
10:59 PM
ok so i'm having trouble with the last script here:

ask ← {⍞←⍵ ⋄ (≢⍵)↓⍞}
screen ← {(⌽¨⊖∘.,⍨⍳z)+⊂⍵}
x←y←0⋄{x←⍵[0]-⍵[1] ⋄ y←⍵[2]-⍵[3]}'w' 's' 'd' 'a'=ask'move: ' ⋄ screen x,y

i made a grid, where each sqare shows its x and y quardinate, and you can move by inputting x y as the right argument and i finished that (thats the "screen" monadic function). additionally i added a zoom which is z. i am now making a way of inputing your movement and i made it so when you inpu w you should move up one. for now it doesn't save your state the next time you run the command but thats fine for now, all i w
wait no sorry. it does return an output. it just shows the original posision with no movement
 
The inner x← and y← create a new local variable. To mutate the outer one, you need x⊢← and y⊢←
also 'w' 's' 'd' 'a' is just 'wsda'
 
oh neat
alright let me try that
@dzaima OMG IT WORKS THANKS :DDD
 
@dzaima (if you intend to add to the position instead of replacing it, x+← and y+← would do that; x function← is a general modified assignment, it just has a side-effect of not creating a local variable also)
 
ahhh cool good to know. yea i was wondering why ⊢ had that property
 
11:41 PM
x←y←0 ⋄ {{x y+←(x,y)+⍵[0 2]-⍵[1 3]}'wsda'=ask'move: ' ⋄ disp∘←screen y,x}⍣≡'test'
i'm now getting insperation from the game of life game and i can't seem to get the display working. any idea why?
nevermind. i put the disp∘← before the x y stuff and now it works :D
 

« first day (1829 days earlier)      last day (833 days later) »