<devyn>
elliottcable: so I'm doing a group project with someone… who is only ever available at 2:30am, and even then, sporadically. bitch. >_>
<whitequark>
how much bitcoins for paws.js?
<elliottcable>
whitequark ⑊ thanks for the link. Saved with extreme prejudice.
<elliottcable>
whitequark ⑊ lol. You don't even know Paws!
<purr>
lol
<whitequark>
elliottcable: like that matters
<elliottcable>
whitequark ⑊ I'm just offering bitcoin and stale cookies to steal the attention of people who're already interested in the project. I want *more* of their attention, not somebody to write it for me.
<devyn>
one does not simply “know” paws.
<devyn>
one must date paws first.
<elliottcable>
I could always just throw money at a contract coder. Believe me, it's not like I haven't thought of it.
<elliottcable>
Yeah, Paws needs a little wining and dining. Maybe a good romantic comedy.
* whitequark
scratches his head
<elliottcable>
And even then, she won't disgorge her operational semantics until the third date.
<elliottcable>
She's a prude like that.
<elliottcable>
But to answer your question:
<whitequark>
you don't get it :) it's not like I'm going to work _just_ for money (and stale cookies, which are evidently equivalent of money)
<devyn>
she'll also want you to spend a lot on her, at least at first
<devyn>
but she's worth it
<elliottcable>
I dunno, I'm pretty sure I offered Micha 50 BTC at one point.
<elliottcable>
Wasn't entirely serious, but there you go.
<elliottcable>
whitequark ⑊ well, maybe it's time for you to get interested in Paws. ;)
<elliottcable>
she's available Tuesday after 8, I hear. Why don't you call her up?
<elliottcable>
oh my god i've given my programming language a gender kill me now
<whitequark>
on the serious note... I promised to roll out a beta of Foundry on about 15th July
<devyn>
oh man, I don't really have time to do that right now, but uhhh
<whitequark>
so that's what I'm doing in near future
<elliottcable>
I was joking. Wait, do you think you could actually teach Paws?
<elliottcable>
I forget, what's Foundry?
<whitequark>
elliottcable: my ruby dialect for embedded sw
<devyn>
whitequark: baaasically, it's a language designed around concurrency. think coroutine procedures (but not quite, and more flexible) + a data access model somewhat like STM
<elliottcable>
and the latter moreso than thef ormer.
<devyn>
right, right, and with asynchronicity and the STM-like data access model, the potential for automatic parallelism
<elliottcable>
CPS-ish, yes, but the actuality is a bit lower-level (subcontinuations that I call “executions”), and then abstracted away a bit to be somewhat procedural-looking
<elliottcable>
Current status: Arguing with CoffeeScript people because their shit is unintuitive. ಠ_ಠ
<devyn>
heh
<whitequark>
btw
<whitequark>
elliottcable: you seen delimited continuations?
<elliottcable>
yes!
<whitequark>
I kinda get the idea (awesome) but didn't catch up on the formal semantics yet
<elliottcable>
I can *barely* wrap my head around them
<elliottcable>
yeah ditto same place exactly.
<elliottcable>
My high-level opinion was “irrelevant / inapplicable to Paws”
<elliottcable>
and with my mind-state in life right now, anything that I can't state to myself in terms of Paws, I don't have room to care about )'=
<whitequark>
eating?
<elliottcable>
I can't be a generalist when I'm trying to keep an entire fucking abstracted stack of programming-environment sane in my head
<whitequark>
... breathing?!
<elliottcable>
and it sucks. because I'm missing out on a lot of shit I wish I could understand.
* whitequark
calls an ambulance
<elliottcable>
Did I ever hook you up with Bluebie?
<elliottcable>
VIM hilights xxd output? that's fucking cool.
<elliottcable>
#youlearnsomethingeveryday
* whitequark
has expected some wires there...
<devyn>
heh
<elliottcable>
wires? what?
<whitequark>
elliottcable: well
<whitequark>
how do you debug hardware?
<devyn>
well, holy fuck, I'll be interested to see what's causing this… o__o
<elliottcable>
I don't do anything with hardware. Confused. Are you working with hardware right now?
<elliottcable>
oh, that's right, Foundry.
* elliottcable
slaps self
<elliottcable>
devyn ⑊ causing what?
<devyn>
ok so the one on the left is the correct output, and the one on the right is this output that is correct at first and then suddenly diverges somewhat
<elliottcable>
oh, wait
<devyn>
and ends up being a somewhat significantly different file size
<elliottcable>
I thought that message was from whitequark.
<devyn>
lol
<purr>
lol
<elliottcable>
am SO much less confused now
<elliottcable>
9:00 AM here.
<devyn>
anyway, it diverges at address 04c0, with 0161 000a 00f6 in the correct output, which is, indeed, correct. but in the wrong output, it's like 0161 000d 0a00 f600
<elliottcable>
Time to turn the subs on and get productive.
<devyn>
so somehow the endian got swapped and an extra byte snuck in
<devyn>
what the fuck, windows?
<elliottcable>
Just watched a lizard-squirrel run by my window.
<elliottcable>
I kid you not, whatever the fuck it was looked exactly what one might expect the offspring of a grey squirrel and a common green gecko to look like.
<elliottcable>
Fucking squizzards. Fuzzy little creepy-ass bastards.
<devyn>
hahaha
<devyn>
I'm gonna sleep. Too tired to deal with windows weirdness.
<devyn>
oh nvm
<whitequark>
elliottcable: doing drugs again?
<devyn>
hahaha
<elliottcable>
<e o7
<devyn>
I got it
<elliottcable>
I love all of you have my codebabies
<elliottcable>
To my complete surprise, it turns out that I've only used the word “codebaby” *once* before in this channel.
<elliottcable>
I feel like it's something I say weekly.
<elliottcable>
Wow, ryah was in here for a while. I forgot about that.
<elliottcable>
You *do* all realize that you're intellectually enslaved to the programming equivalent of the Hypercube guy, right?
<elliottcable>
or whatever the fuck it was.
<elliottcable>
Timecube. That.
<devyn>
elliottcable: lol, so, the bug, man… the bug… I opened the file as "w", not "wb" — which is identical on Unix, but on Windows, without the 'b', it adds a '\r' before every '\n' from the C IO calls
<purr>
lol
<elliottcable>
“No man on Earth has no belly-button, it proves every believer on Earth a liar.”
<elliottcable>
Man, I should just say shit that crazy, then *I'd* be famous *too*
<devyn>
lol
<devyn>
yaaaay I fixed a stupid bug
* devyn
dances
<elliottcable>
Ugh every time I visit this. DO NOT KNOW IF TROLL.
<elliottcable>
DO NOT KNOW IF TROLL, AND IT BOTHERS ME
<purr>
Let it be known that whitequark hates javascript.
<whitequark>
-- any kind of javascript
<purr>
Let it be known that whitequark hates any kind of javascript.
<elliottcable>
oh, it's ಠ_ಠ
<whitequark>
-hates whitequark
<purr>
whitequark: whitequark hates semicolonless javascript, javascript, and any kind of javascript.
<elliottcable>
ಠ_ಠ whitequark
<purr>
Let it be known that elliottcable disapproves of whitequark.
<elliottcable>
-hates elliottcable
<purr>
elliottcable: elliottcable hates mordof, darkf, colds, Express, having to make things complex so that they seem simple, Node.js, oftn-bot, fear of words, albel727, all of you, very much, prophile, reddit, alexgordon ಠ_ಠing ಠ_ಠ, his_hoofiness, single-threaded software, unnecessary semicolons, google, google’s style guides, Owl City, cats, Cracked, mikolalysenko, chjj, dnyy, upgrayedd, Katie K., Java, PHP, Deleware, david_mark, alcohol, pot, Deamonboy, rea
<elliottcable>
“all of you, very much”
<elliottcable>
laughed
<elliottcable>
well-played, past-me.
<whitequark>
<3 LLVM
<purr>
Let it be known that whitequark hearts LLVM.
<elliottcable>
-wholoves elliottcable
<purr>
elliottcable: elliottcable is loved by devyn, locks, sephr, IamTash, gqbe, mix, little_boys, and brr.
<elliottcable>
-find a
<purr>
elliottcable: Found: bot, test, nuck, !, and clouds
<elliottcable>
-find (c)
<purr>
elliottcable: Found: where is the love (c)
<elliottcable>
-where is the love (a)
<purr>
elliottcable: var t=this; this.r=function(t,_,s){return Object.keys(t).reduce(function(acc,k){return _(acc,k,t[k])},s)}
<elliottcable>
have you seen µpaws.js? it's an insane fucking mess.
<elliottcable>
Like, it's mired down to the point where I literally cannot continue to develop on it.
<judofyr>
"elliottcable: have you seen [something I made]? it's an insane fucking mess." :D
<elliottcable>
So, I bit the bullet, and decided that since I now have a *working Paws*, now that I've proven to myself that the concepts are sound and that it's *doable*,
<judofyr>
oh, I didn't see the "mess" at the end there
<elliottcable>
it's time to re-do it in a way that I can actually accrue contributors with.
<elliottcable>
i.e. something that Micah and Devyn can meaningfully contribute to, so we can move this project forward as a whole.
<whitequark>
elliottcable: I'm not a fan of *any* music service
<whitequark>
though
<elliottcable>
That means using all the common tools, and writing clean standard code, and documenting, and testing, and blah-de-blah.
<whitequark>
wait a little bit of time and I'll explain what I like
<elliottcable>
Anyway, it *works*, but the problem is this: http://ell.io/iKYck
<elliottcable>
even *I* can't make heads nor tails of it when something goes wrong, and given that everything is completely fucking untested and there's absolutely no error-checking or sanity verificatiomn anywhere in it, things go wrong *constantly*.
<elliottcable>
So, moving on to the more *conceptually* complex shit ... I don't have the mind-space to *both* be trying to figure out whether it makes any fucking sense to call into an execution paused within on bubble from another parallel co-enclosed bubble **and** try and figure out why I'm getting `undefined is not an object` errors, at the same time.
<elliottcable>
which isn't surprising, or news to anybody, anywhere, ever.
<elliottcable>
µpaws.js served its' purpose: rapidly prototyping the boring but messy core shit in Paws, so we could work out the kinks in the object system and execution model in our own heads.
<elliottcable>
(Also, to give me a mental rallying-point, something I could point at and say “I did a real thing!”, instead of banging my head against these ideas for three years with nothing to show for it.)
<elliottcable>
it's time to move on, and apparently, CoffeeScript is where we're moving on *to*. >,>
<elliottcable>
anyway.
<elliottcable>
judofyr ⑊ how's life? We haven't talked in ages.
yorick has quit [Remote host closed the connection]
<judofyr>
Arrested Development season 4 has been released
<judofyr>
haha
<judofyr>
and I was too busy reading Getting.Started.md
<judofyr>
because I tried to say "life is good"
<elliottcable>
wat
<elliottcable>
oh shit
<elliottcable>
getting.starded.markdown is a thing
<elliottcable>
forgot completely about that
<elliottcable>
should proooooobably re-read that and fix it/finish it
<elliottcable>
meh
<elliottcable>
code.
<elliottcable>
1. clean implementation of the core concepts
<elliottcable>
2. working fowards into time-travel and distribution and the IPP
<judofyr>
let me rephrase: AD4 has been released, the sun is shining and it's hot here in Norway, this has been a chill weekend = life is good
<elliottcable>
*then* 3. documentation and advertisement
<elliottcable>
judofyr ⑊ by the way, you should contribute to Paws. ;)
<elliottcable>
despite CoffeeScript.
<elliottcable>
Wow, this write-up is actually pretty clear.
<elliottcable>
I mean, it's still confusing, because I suck terribly at explaining Paws, but it's better than anything I've managed before.
<judofyr>
yeah, although you never mention why you do the locals['locals'], what affix does (or does it only handle the back-and-forth?) and where's the print?
<elliottcable>
I don't know what any of those questions mean D:
<elliottcable>
where does it say anything about locals[locals]?
<elliottcable>
is that confusing enough that I truly need a bullet-point below to explain?
<judofyr>
oh, I didn't read it properly: you do mention that you want to store it in the locals
<elliottcable>
“handle the back-and-forth?”
<elliottcable>
affix is like Array#push
<elliottcable>
affix: Array#push
<elliottcable>
prefix: Array#unshift
<judofyr>
but where's the "get it out of the locals to print it"?
<elliottcable>
unaffix: Array#pop
<elliottcable>
unprefix: Array#shift
<elliottcable>
oh. that's a really good point.
<elliottcable>
I got side-tracked and never added a line of code later to actually print what I'd assigned, which is super-confusing when somebody's expecting that.
<judofyr>
elliottcable: I looked at the definition of `affix` is the source; do you use Function.prototype.length to detect how many times you must coproduce?
<elliottcable>
hahahaha
<elliottcable>
don't go digging into the source. worst idea ever. I wasn't kidding when I said it was insane.
<elliottcable>
but, if you must know,
<elliottcable>
look at the definition of Execution.synchronous() near the top of the file.
<elliottcable>
That's what's used to “generate” aliens from the JavaScript-function-implementations of various things down below
<judofyr>
I'm mostly wondering about the coproduction "protocol": are all arities defined on the executions/functions/whatever, or do the caller say like "now I pass 3 args" or "this is the last arg"
<elliottcable>
the actual generation is done iteratively by World.applyGlobals()
<elliottcable>
er, are you talking about in Paws, or are we talking about the implementation you're looking at?
<elliottcable>
I have trouble talking about both at once. Sorry. :x
<judofyr>
not sure :)
<elliottcable>
lol
<purr>
lol
<elliottcable>
answer in terms of Paws, I think, if I understood the question correctly:
<elliottcable>
there's no methodology of telling how many more “arguments” a “function” can take.
<elliottcable>
which sounds confusing, but makes sense when you understand that arguments aren't actually a thing.
<elliottcable>
it's easier to look at it as there being a certain number of “holes” in a ‘function’, and as you pass things to it, those holes are used-up
<elliottcable>
when they're all used up, the function is completely “spent.” It doesn't matter if you try to dump any more data on it to fill holes, nothing will happen.
<elliottcable>
does that remotely answer your question?
<judofyr>
remotely? yes
<elliottcable>
Wow, that was the weirdest error I've ever gotten out of CoffeeScript.
<elliottcable>
forgot the arrow after the constructor in a class-definition. The error message it generated was completely incomprehensible, and the generated code was even more confusing.
<elliottcable>
fuckin' C-script. ಠ_ಠ
<elliottcable>
ಠ_ಠ CoffeeScript
<purr>
Let it be known that elliottcable disapproves of CoffeeScript.
<elliottcable>
anyway.
<elliottcable>
judofyr ⑊ I'm surprised you don't already know this shit about Paws. I thought we sat down and talked about it quite a bit, once upon a time.
<judofyr>
elliottcable: I know parts and bits, but I still stumble when I see actual code
* elliottcable
nods
<elliottcable>
Bro, I *invented* that shit, have been working in it for three years, and it still confuses the shit out of me.
<elliottcable>
It's a language that's *designed* to make absolutely no sense until it's abstracted.
<elliottcable>
It's a bit like trying to make heads-n-tails of something by reading the LLVM bytecode.
<whitequark>
hey, LLVM bytecode is pretty clear
<elliottcable>
Sure, a sufficiently badass neckbeard from the 1970s could read and write raw x86 fluently, without getting confused, after half a decade of doing so.
<elliottcable>
Most of us can't do that, though.
<elliottcable>
Paws is a high-level VM, and cPaws is the “bytecode.”
<elliottcable>
(In fact, micahjohnston made a spirited attempt to convince me to re-design it such that the jux-stream *was* a bytecode; and he managed to implement something pretty close to that with zippers in his haskell implementation, as I understand it.)
<whitequark>
jux-stream?
<elliottcable>
AHLVM? Asynch, high-level VM?
<elliottcable>
ACHLVM? or CAHLVM?
<elliottcable>
CA-HLVM.
<elliottcable>
okay, done.
<elliottcable>
whitequark ⑊ Paws boils down to a series of “juxtapositions.”
<elliottcable>
There's only a single operator in the syntax, that of whitespace.
<elliottcable>
`foo bar`
<elliottcable>
you can “indirect” that operator with parenthesis:
<elliottcable>
`foo (bar)`
<elliottcable>
that's the entirety of the “syntax.” Which isn't really a syntax at all, because it's not yet actually a programming language.
<whitequark>
grrrr, grooveshark did not muck with my own uploaded file
<elliottcable>
judofyr ⑊ haven't the slightest fucking clue.
<elliottcable>
It took me a solid three days to write that example. Because I suck at Paws.
<elliottcable>
I'll stare at it for a moment and see if I can figure it out, if you like. (=
<elliottcable>
Oh. I'm an idiot.
<elliottcable>
The reason that stage() thing keeps happening, is that executions that don't have something *useful* to return, don't return *at all*.
<elliottcable>
and if you use the ()-pattern (“call pattern”) to stage them, then you yourself are implicitly unstaged, “waiting for a return value.”
<elliottcable>
follow, so far?
<elliottcable>
so, if we just did:
<judofyr>
ah, yeah
<elliottcable>
infra affix() (locals) (infra empty())
<elliottcable>
then “us” (the global-routine that all of this code is in) would stop right there, and nothing else would happen.
<judofyr>
it's like using a callcc and no one calls the continuation?
<elliottcable>
so, to avoid that, we use stage() to *explicitly* cause the very last staging of this routine we're calling into.
<elliottcable>
every staging up until the last one (every “argument” except the last argument) can be done implicitly and easily;
<elliottcable>
but the last staging (last “argument” we do explicitly.
<elliottcable>
exactly like that, yes.
<elliottcable>
this is a particular oddity of the API I designed for the core aliens.
<elliottcable>
like affix().
<elliottcable>
affix can't meaningfully return any value; it *changes state*, it doesn't *compute a value*
<elliottcable>
so I opted, instead of building an “Okay I'm done, here's <nothing>” value into the system,
<elliottcable>
or having some boring and unsemantic convention such as returning an empty string-ish,
<elliottcable>
I decided that the most semantic thing (even if it's not very easy to *write* at this layer of abstraction), would be to signify no-return-value by, uh, not returning.
<elliottcable>
so:
<elliottcable>
those two lines, are more clearly written:
<elliottcable>
infra affix() (locals) (infra empty())
<elliottcable>
infra charge() (locals) (infra length() (locals))
<elliottcable>
which basically boils down to, “add an element to this locals-array, and then “charge” that element”
<elliottcable>
(`charge()` takes an index)
<judofyr>
next question then: what does charge do? and how does that work when you call length() after affixing?
<elliottcable>
do you remember how ownership works?
<judofyr>
(e.g. wouldn't it return one number off?)
<judofyr>
nope
<elliottcable>
nope, because arrays are one-indexed in Paws
<judofyr>
ah
<elliottcable>
That was a decision made in December 2009, when Paws was still a series of long and involved threads on Google Wave.
<elliottcable>
it actually resulted in about 2/3rds of the people I had involved in Paws at the time, leaving in a huff.
* elliottcable
laughs
<elliottcable>
I've always been a bit unconventional. ;)
<elliottcable>
so, charging, has to do with ownership
<elliottcable>
before I even try to *explain* it, let me tell you *why* that line's there.
<elliottcable>
that line contributes to *ordering* the following code in the file.
<elliottcable>
Since the language is inherently asynchronous and massively concurrent, obviously, there's gotta be some way for ordering sequential tasks or intra-dependant tasks.
<elliottcable>
Ownership is that way.
<elliottcable>
'k.
<judofyr>
makes sense
<elliottcable>
code that's going to run, can “own” (verb.) data, to declare to the system that it's going to do things involving that data.
<elliottcable>
very simple locks-like system.
<elliottcable>
can get read-ownership or write-ownership.
<judofyr>
I was wondering how you would guarantee that the affix() would happen before the length() though
<elliottcable>
when it's done with some data, it can disown it.
<elliottcable>
ah!
<elliottcable>
good question!
<elliottcable>
that's the inverse of why we use stage() the way I explained!
<elliottcable>
when we do that last staging, via stage() (*explicitly*), it's because we don't want to be unstaged ...
<elliottcable>
... because the *implicit* stagings, like `infrastructure affix() (locals)`, *do* unstage us.
<elliottcable>
So, basically, the back-and-forth coproduction between ourselves and the `affix` routine, is synchronous.
<elliottcable>
that is beacause those implicit justapoxitions (like juxtaposing `(locals)` against it), result in us being unstaged; where we then “wait”, and are later staged again by affix() when it has some more data for us.
<elliottcable>
with me so far?
<judofyr>
yes
<elliottcable>
this pattern is what we call “coproductive argumentation”.
<elliottcable>
coproductively argumented routines, like most of those aliens provided by the system (affix, charge, stage ... all being examples you've seen),
<elliottcable>
expect to *first* be staged with *you* (the ‘caller’)
<elliottcable>
which is what those two empty parenthesis do:
<elliottcable>
`affix()` is the first implicit-staging happening, and is equivalent to:
<elliottcable>
affix( arguments.caller ) in JavaScript
<elliottcable>
since it's an *implicit* staging; as I mentioned earlier, this involves unstaging *us*, the caller,
<elliottcable>
so the very first thing a coproductively-argumented routine is going to do, is take the value it just got, and stage it again, *with itself*. Which resumes us, with them.
<elliottcable>
Still with me?
<judofyr>
yes
<elliottcable>
after that, it can consume as many arguments as it may be specified as needing, each time re-staging us, the caller, which it now has a handle on, when it's ready for its next argument
<elliottcable>
the ()'s in that syntax are implicit-stagings, and then the last one is explicit; thus, after the line containing d=, we can continue doing other things.
<elliottcable>
that's exactly what happens in the linked code.
<elliottcable>
with me?
<elliottcable>
however, there's no *assignment* at this level of abstraction (we haven't implemented it yet!), so, Lisp-like, we just toss it inside the parenthesis.
<judofyr>
what happened with empty() ?
<elliottcable>
empty() just generates a new, meaningless object.
<elliottcable>
think of it as `new Object()`a
<judofyr>
right, but won't have to stage c with that object?
<elliottcable>
except our core object is an array, not a dictionary, so in this case, it's being used more like `new Array()`
<elliottcable>
yep!
<elliottcable>
which is why the second argument to stage() is that object
<elliottcable>
so:
<elliottcable>
the “return value” from `infrastructure affix() (locals)`
<elliottcable>
is the *execution* for affix
<elliottcable>
because it hasn't consumed all of its arguments yet, and it just returned itself to us one last time, expecting its last argument
<elliottcable>
that execution, is the *first* argument to stage()
<elliottcable>
then, on the next line, an empty() is the *second* argument to stage()
<judofyr>
well, I still don't see how this ensures that the first `infrastructure execution stage()` (which does affix) is executed before the second (which does length())
<elliottcable>
I just literally said “... oh.”
<elliottcable>
out loud.
<elliottcable>
and made that sort-of-sick face that makes me look like an idiot.
<judofyr>
or, what happens after we've called stage() with two arguments?
<elliottcable>
Barring ownership considerations, stagings are guaranteed to process in-order.
<elliottcable>
but, you're right, that may very-well be a race condition on multiple cores.
<elliottcable>
I don't have a working multi-threaded Paws yet to test that out. /=
<elliottcable>
it'd be easy to work around that with ownership, though; you'd just need a hell of a lot more boilerplate code up there to set-up the ownership constraints around that call. hm.
<elliottcable>
I'm going to create an issue for that.
<elliottcable>
to remind me to look into it in-depth in the framework of my planned semantics. You may have sussed out a substantial bug.
<elliottcable>
Anyway. Ignore it for the moment. Any further questions?
<judofyr>
elliottcable: so the next code (line 12-19) will push two two values to the object we just allocated: the label "‡" and the existing infra-object
<elliottcable>
yepyep
<judofyr>
s/two two/two/
<elliottcable>
basically building an assignment-pair out of them
<judofyr>
which somehow dictates the scoping rules further down the file
<elliottcable>
(the 10th example is implementing actual assignment as a useful, call-able routine)
<judofyr>
question: what makes Paws suddenly look into the new object when it tries to lookup "‡"
<elliottcable>
'k, time to discuss the actual semantics of juxtaposition
<elliottcable>
`<foo> bar`
<elliottcable>
(to be clear: I'm not talking about `foo bar`, which is *two* juxtapositions, the first of which is special; I'll get to that in a moment. I'm talking about the juxtaposition of `bar` against a given value that we already have in-hand, which we'll call <foo>.)
<elliottcable>
if <foo> is an `execution`, you already understand what happwns:
<elliottcable>
the call-pattern abstraction.
<elliottcable>
specifically, exactly three things happen, in order: <foo>, the execution, is clone()'d. The clone thereof, is stage()'d. Then we, ourselves, are unstage()'d.
<elliottcable>
treating each object in the `thing` as a “pair” (that is, another `thing`, the first element of which is a `label`, and the second of which is any other value),
<elliottcable>
it iterates over them in reverse-order, pulling out ones where that `label` compares truthfully with the key we're find()'ing.
<elliottcable>
Thus: find() returns the *value* from the *last* pair in the thing, having a key matching the key-being-searched-for.
<elliottcable>
simple enough?
<judofyr>
yes
<elliottcable>
bringing it back to your original question:
<elliottcable>
we laboriously created a pair that looks like this: (‡, <infra>)
<elliottcable>
so that when it find()'s through <locals>, which looks like (..., (‡, <infra>)), it returns <infra>.
<elliottcable>
now, back to discussing juxtapositions.
<elliottcable>
the *first* label in an expression is implicitly juxtaposed against `locals`, which we'll call $ for a moment
<elliottcable>
so `foo bar` is $['foo']['bar']
<elliottcable>
in many of the later lines in the file, that's $['‡']['affix']... or similar
<elliottcable>
which means it looks in $, which looks like [ ... , ['‡', <infra>] ], and finds <infra>
<elliottcable>
reducing that line to <infra>['affix']
<elliottcable>
so, the {} itself right-off-the-bat, points to the *start* of it (or, as this implementation looks at it, it points at the whole thing)
<elliottcable>
in the example you linked to, we're passing a pristine execution (that when eventually staged, will simply print “success!”), *as a value* (as a continuation) to affix
<elliottcable>
clear at all?
<elliottcable>
forgive me if I over-explain everything. I've seen too many people make bad assumptions and get completely confused about Paws.
<elliottcable>
they're staged with 1. the *caller*-execution, 2. the left-side (value), and 3. the right-side (‘key’)
<elliottcable>
so, up at #L42-L44, we're putting together that list of parameters;
<elliottcable>
which, as you said earlier, is self, my.routine, locals;
<elliottcable>
and then we're argumenting the “find” algorithm with that, priming it for easy realization
<elliottcable>
with me?
<judofyr>
yes
<elliottcable>
the rest should be fairly obvious, it seems to me
<elliottcable>
we proceed to expose the “implementation” bag within the function-body, by storing it on the locals; then we can call the function, and it will operate as intended.
<elliottcable>
honestly, I haven't the slightest fucking clue what's going on with the receiver(parameters) thing
<elliottcable>
I can't figure out for the life of me why I'm doing that, but I'm sure there's a reason
<elliottcable>
I take the same approach in the (much *much* more complicated) implement.assignment example
<judofyr>
that whole receiver() business made my head dizzy
<judofyr>
what is my.locals?
<elliottcable>
Dude, if that's the only thing that makes your head dizzy about that file, then you're wayyyyy smarter than me
<elliottcable>
my.locals is the locals *of my.routine*
<elliottcable>
look up at the routine literal again:
<elliottcable>
it does: locals['implementation']['util']...
<elliottcable>
which means locals['implementation'] needs to exist.
<elliottcable>
The only place where, right out of the gate, `implementation` is *defined*, is on the locals of the root-level execution.
<elliottcable>
To use it in *sub*-routines, we need to add it to their locals from the outside.
<elliottcable>
yet more bootstrapping. get it?
<judofyr>
where's the connection from my.routine to my.locals?
<elliottcable>
gives us parameters = [<me>, my.routine, "locals"]
<judofyr>
I'm going have nightmares where everything I read looks like "‡ execution stage"
<elliottcable>
LOL
<purr>
lol
<elliottcable>
then,
<elliottcable>
#L54,
<elliottcable>
okay, 46-46 is creating a new pair on the end of our root-locals, just like we've done a billion times elsewhere,
<judofyr>
I thought I understood L54, but no. `receiver() (‡ empty())` returns the receiver of Thing. that is an execution that requires two arguments (rv, here). correct?
<elliottcable>
50-51 is setting the key of that pair to "my.locals",
<elliottcable>
and 52-54 is setting the *value* of that pair, to the result of receiver.apply(parameters)
<elliottcable>
which means, given our parameters,
<elliottcable>
setting that value to the result of my_routine.find('locals')
<elliottcable>
oh duhhhhh
<elliottcable>
which reminds me *why* we do all that.
<elliottcable>
basically:
<elliottcable>
here.
<elliottcable>
really great way to explain it.
<elliottcable>
Function.toString() is gonna return some function-y shit. It's overridden.
<elliottcable>
But in this case, we want the *objecty-stringy-ness* of our function.
<elliottcable>
so we do Object.prototype.toString.apply(our_function).
<elliottcable>
common JavaScript trick. yeah?
<elliottcable>
this is the Paws equivalent of *that*.
<elliottcable>
We're grabbing the *object* receiver (which preforms a find), and effectively `apply()`ing it to our *execution*.
<elliottcable>
Because if we just juxtaposed against our execution, since it's an execution, it would *stage* it. Not at all what we want.
<elliottcable>
storing the result of looking-up 'locals' on my_routine, in my_locals
<judofyr>
but didn't Thing.receiver take two arguments (one list and one "here"?)
<elliottcable>
three
<judofyr>
oh wait
<elliottcable>
here, a thing, and a key
<elliottcable>
looks up key on the thing
<judofyr>
I'm mixing up the coproducer thingie
<elliottcable>
yep, no coproduction going on here
<elliottcable>
except for the routine affix() and charge() and such
<judofyr>
so every execution literal/AST has its own "locals"?
<elliottcable>
yep
<elliottcable>
there's absolutely no scoping *built in* at this level of abstraction.
<elliottcable>
if you want to “expose” something to a sub-routine, lexically or otherwise, you have to explicitly grab their locals and copy the data you want over.
<elliottcable>
that's all abstracted away quickly.
<judofyr>
why wouldn't just `my.routine locals` work again?
<elliottcable>
because that'd *call* my.routine
<elliottcable>
remember, although you're used to the looks of it from other languages, parentheses *aren't* a call.
<elliottcable>
they're indirection. irrelevant to the call.
<elliottcable>
so the next juxtaposition uses the *execution*-receiver
<elliottcable>
...['util']['print']('Success!')
<judofyr>
I get your example of Function.toString() now
* elliottcable
nods
<judofyr>
Execution is_a Thing
<judofyr>
but you want Thing's receive, not Execution's
<elliottcable>
yep!
<elliottcable>
yepyepyep
<elliottcable>
this is all hax.
<elliottcable>
probably wouldn't be necessary.
<judofyr>
you can only execute this routine once though
<elliottcable>
easy enough to expose find().
<judofyr>
I'm confused again: does calling my.route automatically clone it, or is that something you have to do inside the routine (when implementing a function call with coproduction)?
<elliottcable>
calling it *by juxtaposition* clones it.
<elliottcable>
but any other methodology, you'd have to clone it if you wanted it cloned.
<elliottcable>
basically, jux-powered coproductive-argumentation (JPCA!) leaves behind a series of one-off clones that are never used again.
<judofyr>
what happens to the `locals` if you clone it. is it shared?
<elliottcable>
currently, shared.
<elliottcable>
that's actually a thing that's changing once I can copy the implementation over.
<elliottcable>
One of the big up-in-the-air design elements is how to *fork* the locals, along with forks of execution-path.
<elliottcable>
if we clone something twice, and resume it with different arguments, how do we “fork” the locals?
<elliottcable>
the goal being to have some sort of inherently-forking data-structure instead of a simple list.
<judofyr>
yeah, I was wondering how to deal with recursive function calls
<judofyr>
(where you want to set `locals` to different values in the same "stack frame")
* elliottcable
nods
<elliottcable>
gotcha
<elliottcable>
generally speaking, you clone it *first*, and then do your thing, and then call the clone
<elliottcable>
but as you mentioned that leaves questions about locals
<elliottcable>
another item for the new Issues repository :D
<elliottcable>
I'm pretty sure what I'd decided to do for the immediate future, is shallow-copy the locals object *itself*.
<elliottcable>
Allowing for shadowing “earlier” definitions with “later” ones, but allowing the sharing of data at deeper levels of depth.
<elliottcable>
Very naïve, but puts off dealing with the problem.
<elliottcable>
Needs more thought. (=
<judofyr>
is the plan that the parser of the "proper" language will be implemented on top of this? so calling "foo.bar(123)" still uses the jux system of cPaws.js?
<elliottcable>
neither
<judofyr>
or, more likely: "foo bar(123)"
<elliottcable>
there will never be another “parser.” Paws isn't meant to be parsed.
<elliottcable>
Paws programs are *shared* as something like bytecode, or a binary;
<elliottcable>
more accurately, a frozen, mostly-binary, data-space representation.
<elliottcable>
Those representations are *built up*, originally, obviously, from some sort of code; but that code is not intended to be standardized, nor is it intended to be universally-shared.
<elliottcable>
cPaws is only a bootstrapping language.
<elliottcable>
Think of it a little bit like this:
<elliottcable>
You know RPython? Or that restricted Ruby subset the RubySpec project uses?
<elliottcable>
that's a bit like cPaws.
<judofyr>
(restricted Python subset that PyPy uses, yes)
<elliottcable>
*but*, there's not any one standard “superset”, like there is fully-Ruby or full-Python;
<elliottcable>
instead, there's an infinitude of possible languages, built out on top of cPaws.
<elliottcable>
none of which are intended to be syntax/code-loading compatible.
<elliottcable>
Instead, they are *run* by whatever handles them, and they gradually result in what is called a Unit
<elliottcable>
and then, at some point, when the construction is “finished” for a given value of finished, that program-state can be frozen: a frozen Unit.
<elliottcable>
this is all very tightly tied into the distribution mechanic.
<elliottcable>
Operations are intended to change the program-data-space (what we call the “data graph”) in a particular way; and those changes can progress across implementation boundaries
<judofyr>
but must these languages on top of Paws be parseable/runnable by cPaws, or could you create a parser and "compile" to cPaws?
<elliottcable>
at any point, that entire graph can be frozen and serialized; or a graph can be loaded from a serialization.
<elliottcable>
not at all.
<elliottcable>
first off, you'll never *compile* to cPaws.
<elliottcable>
second, there's two ways to write code that *isn't* raw-cPaws, and result in Paws-stuff-happening.
<elliottcable>
One, is the obvious “write a new parser for your own syntax/whatever/system, and ensure it follows Paws semantics and federates via the Paws distribution protocol.”
<elliottcable>
only *my* Paws implementations will be necessarily using cPaws, as well as the specifications, of course.
<elliottcable>
But the far more interesting one, and the one I spend most of my time thinking about ... the one *my* implementations are designed for ... is the “IPP.”
<elliottcable>
or P₃.
<elliottcable>
the Paws PreProcessor, or more generally, an “Interpretative Pre-Processor.”
<elliottcable>
It's one of my more insane ideas, if I do say so myself. I get a lot of incredulous responses when I try to explain it.
<elliottcable>
Basically, I was dead-set on Paws' Units being *compilable*, for a given value of the term; that is, at runtime, I don't want the AST, executions' code-data bodies, being modifiable.
<elliottcable>
But, despite that, I wanted better-than-lisp-y self-modification abilities.
<elliottcable>
So, an IPP-powered Paws environment progresses through two, completely unrelated, stages of execution:
<elliottcable>
The first, self-modification stage, *all* external-world-accessing/modifying functionality is black-holed. Disabled. Inaccessible. If you try to access it, basically, nothing happens.
<elliottcable>
but, instead, a special API allowing access-to and modification-of the AST and source-code itself, is temporarily *enabled*.
<elliottcable>
During this process, every single time that API is accessed, the code is re-run.
<elliottcable>
Finally, when the code preforms a full realization without any new access to that API, it's considered “fully preprocessed,” that preprocessing API is disabled, external-access is again allowed, and *true* interpretation of the code is allowed to begin.
<elliottcable>
This means that the source-code can progressively self-modify, even modifying later parts that self-modify, until it's “constructed” itself into a final, stable state.
<judofyr>
yeah, I think I've heard about this before
<elliottcable>
Yes, that sounds slow as all ungodly hell (running the entire setup process possibly hundreds, thousands of times);
<elliottcable>
but it's not any different than a compilation phase or similar: once it's done, you won't be *running* it again, because you'll be storing your program as a frozen Unit after the first time you do that.
<elliottcable>
So, it's a bit like self-compiling code. It compiles itself once, and then it's no longer in a source-code state.
<elliottcable>
So:
<elliottcable>
Since, in the self-modifying state, it's still a full programming language (not some half-arsed shit seperated like M4 or even worse the CPP),
<elliottcable>
you can have libraries that *also* define *syntax*.
<elliottcable>
that is, define ways to process syntax into a slightly-less-abstracted form ... which can then, itself, be processed ... etcetcetc.
<elliottcable>
in this way, syntax is meant to be built, just like the semantics, from-the-ground-up, bootstrapped from within the language.
<elliottcable>
And, more importantly,
<elliottcable>
*also* just like the semantics, it's meant to be defined entirely by libraries / frameworks. Not by the language designer, myself.
<judofyr>
I like it
<elliottcable>
There's an entire plan in my head built ontop of these foundational pieces
<elliottcable>
what I've described thus far is “the Nucleus.”
<elliottcable>
You just spent several hours trying to decipher about 100 lines of Nucleus-level code.
<elliottcable>
there's “Paws' Core” on top of that, which is an absolutely minimal set of abstractions to “fill out” and “fatten up” the Nucleus; they're meant to be a bare-minimum shared-standard of sanity.
<elliottcable>
Writing code at the Core-supported level of abstraction will still be difficult, but *doable*. Not mind-bendingly painful.
<elliottcable>
Core includes basic shit like assignment, copying, iteration, etcetcetc.
<elliottcable>
conspicuously, it will *not* include any form of inheritance, or object-orientation/object-abstraction. It will adhere as closely as possible to the spirit of Nucleus that I've already shown you a bit of.
<elliottcable>
then, on top of Core, I intend for people to *create programming languages*
<elliottcable>
one of which I, myself, have: “Paws' Fullness.”
<judofyr>
and how many years until you're there? :D
<elliottcable>
Fullness being a langauge developed on top of [Nucleus+Core], something with true object-orientation/inheritance, with all sorts of nice syntactic sugar and helpful stuff
<elliottcable>
originally, the plan was seven years.
<elliottcable>
unfortunately, I'm only about two years' into my schedule, and it's *been* about three and a half.
<elliottcable>
But, I have high-hopes for garnering some support and attention soon. need to get a *cleaner*, contribute-to-able, working-example out the door;
<elliottcable>
and I also need to start implementing some of the more *exciting* stuff, to get the attention and time of the smart people I value.
<elliottcable>
I'm fairly certain I'll never keep devyn, or micahjohnston, or alexgordon's attention *until* I have something concrete to show for, say, time-machines. or distribution.
<elliottcable>
and to get those things, I need a clean codebase I can innovate on top of.
<elliottcable>
I'd like to have that by the end of the summer, basically.
<judofyr>
right now I really have no idea what to do with Paws: really terrible writing uPaws code, and I don't know enough about uPaws.js to contribute…
* elliottcable
nods
<elliottcable>
but you *could* contribute to Paws.js.
<elliottcable>
I have a little more to do before I can start pointing you at un-done stuff; I need to port some more over from the clusterfuck-that-is-µpaws.js
<elliottcable>
and I doubt I could talk anybody else into doing *that* task.
<elliottcable>
it's too ugly and I'm the only one who knows what the hell's going on.
<elliottcable>
but once it's ported over a little more, we've got obvious shit that can be worked on:
<judofyr>
if you write some tests, I can implement stuff ;)
<elliottcable>
I need the parser ported. Parsers are easy to understand, easy to implplement, and nicely-uncoupled from the rest of the code.
<elliottcable>
I need the debugging code ported.
<elliottcable>
Or, rather,
<elliottcable>
I need *all* of the debugging-code thrown away and ignored; and I need *some* debugging code of some sort, written.
<elliottcable>
sorry, er, debugging-output-code.
<elliottcable>
Stuff for printing out a Thing in a pretty way to the terminal. Stuff for showing the state of an AST within an execution.
<elliottcable>
There's extant, and quite-beautiful stuff in µpaws.js that you can *run* to show you the kind of output I'm talking about, but the code is the most spaghetti, tangled, bullshit mess I've ever written in my life.
<elliottcable>
(Seriously. I've never written any code worse than µpaws.js; and there's no part of *it* that's worse than the D() code.)
<elliottcable>
It's not even interesting. Just fucking confusing.
<elliottcable>
Anyway.
<elliottcable>
If you really want to contribute, we can talk about it more.
<elliottcable>
But we've been talking for hours. If you're interested, but want to wait, why don't we schedule a time to dive into “showing you where to contribute?”
<elliottcable>
unless you seriously have another five hours sitting infront of you, un-spoken-for, right now.
<elliottcable>
:3
<judofyr>
nah, right now I need to get some sleep
* elliottcable
nods
<elliottcable>
thought as much
<elliottcable>
What're you doing tomorrow? It's a holiday 'round these parts, so I'll have the entire day free.
<elliottcable>
We can sit down and work out how to work together.
<elliottcable>
For whatever it's worth: you have no idea how much I appreciate the interest.
<elliottcable>
getting tired of feeling like the Timecube guy, only possibly crazier.
<judofyr>
17:00 UTC (or maybe earlier) tomorrow
<elliottcable>
judofyr ⑊ tweet at me, unless I'm already online in here. (=
<judofyr>
will do
<judofyr>
see ya
judofyr has quit [Remote host closed the connection]
<purr>
alexgordon: “03. puerto rican cousins [prod. gordon voidwell and alex kestner]”, Das Racist: <http://tinysong.com/IOKr>, “Song of Mor'du”, Patrick Doyle, Billy Connolly, Alex Norton, Carey Wilson, Scott Davies & Gordon Neville: <http://tinysong.com/1bZaT>, “Cutting Ferns/Alex Dan MacIsaac's/Brenda Stubbert's Reel/Mutt's Favorite Reel/Bernadette's Reel/Lady Gordon Of Gordonstown”, Jerry Holland: <http://tinysong.com/fw6K>
<elliottcable>
Obviously the T. Mills song is purr's anthem.
<elliottcable>
'k. bbl. all dressed.
<elliottcable>
-topic Puppy paws patter placidly through the pale passageways…
<purr>
elliottcable: SyntaxError: Syntax is `s/expression/replacetext/gi`.
<alexgordon>
elliottcable: have fun
<elliottcable>
ffuh
elliottcable changed the topic of #elliottcable to: Puppy paws patter placidly through the pale passageways…