<ELLIOTTCABLE>
devyn: walk me through your looping code
<ELLIOTTCABLE>
the first, not the new one, yet
<devyn>
ELLIOTTCABLE: for SerialReactor or ParallelReactor? because it's kinda different
<devyn>
SerialReactor obeys the spec, and I don't think ParallelReactor does completely
<devyn>
ELLIOTTCABLE: oh wait nvm
<devyn>
ELLIOTTCABLE: I know what you're talking about haha
<devyn>
ELLIOTTCABLE: basically my assumption was: take a branch of self and put it in locals as "self.portrait"
<devyn>
ELLIOTTCABLE: and then call that
<devyn>
ELLIOTTCABLE: and when I do, the branch was taken such that it's at the position where it's going to send something to set[]
<devyn>
and actually end up setting that again
<devyn>
so I can call self.portrait with another branch of self.portrait
<devyn>
and all will be good and it will loop, right?
<devyn>
well, wrong.
<devyn>
because I've already got to the point where I've called stage with []
<devyn>
and so stage's caller won't be the new branch
<devyn>
and it'll try to return to the old one
<devyn>
and no loop will happen
<ELLIOTTCABLE>
gimmie … 15 minutes, and I'll be able to focus
<devyn>
kk
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<ELLIOTTCABLE>
sorry
<ELLIOTTCABLE>
there's a girl over. that developed.
<ELLIOTTCABLE>
m'kay.
<ELLIOTTCABLE>
Paws, motherfuckers. Time to focus. (It's a week overdue.)
<ELLIOTTCABLE>
(goddamn Dwarf Fortress.)
<ELLIOTTCABLE>
devyn: re: your photos,
<ELLIOTTCABLE>
impressive.
<ELLIOTTCABLE>
glad to see you're happyifying your work a little bit.
<ELLIOTTCABLE>
it's so much more fulfilling to work on something that's pretty! O_O
<ELLIOTTCABLE>
Cheery: “should debug my cat” wat.
<purr>
beep.
* ELLIOTTCABLE
/ht vigs
<vigs>
hi?
<vigs>
ELLIOTTCABLE: /ht?
<ELLIOTTCABLE>
slashtag formatting
<ELLIOTTCABLE>
ht = hattip, a form of /cc
<vigs>
ah
<ELLIOTTCABLE>
in turn, a form of /via
<ELLIOTTCABLE>
;)
<glowcoil>
elbacttoille
<glowcoil>
ELLIOTTCABLE:
<vigs>
"elbactoille" - glowcoil, 2k14
<ELLIOTTCABLE>
vigs: hm?
<vigs>
that amused me
<vigs>
so someone on Twitter's getting subscribed to email lists by someone, and he found the IP, and it's from my city, so I'm kinda freaked out by this
<ELLIOTTCABLE>
wat
<vigs>
srsly
<vigs>
I think it's someone who follows both of us, who spoofed their IP or whatever
<vigs>
it's pretty fucked up
<ELLIOTTCABLE>
devyn: ahhhhhh
<ELLIOTTCABLE>
devyn: interrrresssting.
<devyn>
ELLIOTTCABLE: anyway, having an outside observer initialize the loop works, but I think it's kinda ugly
<ELLIOTTCABLE>
neh,
<ELLIOTTCABLE>
writing up a github issue, I thinl
<ELLIOTTCABLE>
but basically:
<ELLIOTTCABLE>
oooo
<ELLIOTTCABLE>
maybe can be made to work by abstracting away the `stage[]` specifics that are making this difficult?
<ELLIOTTCABLE>
mmmmmmmmm,
<joelteon>
I thought paws didn't have syntax
<joelteon>
what's with the brackets
<devyn>
joelteon: Paws doesn't, but there's cPaws, which is a syntax that represents a subset of Paws
<joelteon>
why
<devyn>
it's a temporary thing. just so we can actually use it for now
<devyn>
but the idea is that you could basically rewrite the syntax within Paws starting from a very basic syntax, and generate whatever you want
<devyn>
we haven't gotten that far yet though.
<devyn>
Paws itself just deals with Scripts with embedded objects and some instructions and a stack
<devyn>
in my implementation it really is a sort of concatenative language
<ELLIOTTCABLE>
joelteon: a paws program is pretty much a set of pre-defined interactions between two networks of data, two graphs.
<ELLIOTTCABLE>
and the usual format for that shit is to start out with only *one* graph, the graph of instructions, and allow the second (the data) to be initialized to a minimal, default state … and then include instructions in the first one to construct the second one.
<ELLIOTTCABLE>
(i.e., traditional program flow: “a file of source-code that generates object structures in memory” in any other language.)
<ELLIOTTCABLE>
joelteon: it's an important distinction that that's only *one* way to do it, though.
<devyn>
and there are some pretty cool things you can do by embedding objects directly inside scripts
<devyn>
other than symbols
<ELLIOTTCABLE>
both because A) what devyn's talking about, where not all useful instruction-graphs can be usefully serialized to a common textual format; and also B) because the latter, the data-graph, can be serialized *too*, if the setup is complex
<devyn>
my REPL actually works by rewriting the script to inject a little 'printer'
<ELLIOTTCABLE>
(i.e. in situations where it's easier to ship around both a data-graph *and* instruction-graph, than to ship just an instruction-graph and assume the user will construct it that way)
<ELLIOTTCABLE>
meh lotsa words
<ELLIOTTCABLE>
“why”
<ELLIOTTCABLE>
joelteon: 'cuz we wanna do cool extensible things.
<devyn>
I'm already envisioning some pretty cool optimizations based on static analysis, btw, ELLIOTTCABLE. but I'm not going to do them until waaaay later, probably not until rulebook is completeish
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
so:
<joelteon>
now i get to compile LLVM again
<ELLIOTTCABLE>
thinking functionally for once (LOL WAAAAT, ELLIOTT DOIN' FUNCTIONALLSES?), if an intermediate routine takes (me),
<purr>
LOL
<ELLIOTTCABLE>
oh nope
<ELLIOTTCABLE>
ugh I've got nothin'
<ELLIOTTCABLE>
without *truly first-class* support, branch is useless.
<devyn>
yeah I don't think there's really anything that can be done about it :/
<ELLIOTTCABLE>
well not within the *current* frameowrk
<ELLIOTTCABLE>
there's a reason I want to find this shit before I stop iterating the design
<ELLIOTTCABLE>
tentatively:
<devyn>
well, branch isn't really useless, it's just pretty much always useless to branch yourself
<ELLIOTTCABLE>
separate branch from clone,
<ELLIOTTCABLE>
clone is as current, but only meaningful outside,
<ELLIOTTCABLE>
branch, a new operation that clones the caller, *and advances the clone* (see? first-class support.)
<devyn>
advances the clone with a given response?
<ELLIOTTCABLE>
hmmm possibly
<devyn>
because that could work
<ELLIOTTCABLE>
need to look into it in more detail, but am sleepies
<devyn>
I think
<ELLIOTTCABLE>
but yeah. definitely a solvable problem.
<ELLIOTTCABLE>
I got side-tracked; can you write it up for me?
<devyn>
ELLIOTTCABLE: I'm not actually sure that that solves it though…
<devyn>
anyway
eligrey has quit [Quit: Leaving]
<purr\Paws>
[Issues] devyn comment on issue #4: This is still an issue, by the way, and I've run into it with Paws.rs a little bit. I'm actually not even sure why the examples run just fine on the parallel reactor, because they shouldn't... but maybe things are just executing so quickly that it ends up working? https://github.com/Paws/Issues/issues/4#issuecomment-50304535
<devyn>
joelteon: I'm experiencing the same problem as you connecting to GitHub
<devyn>
or
<devyn>
wait was that you?
prophile has joined #elliottcable
<devyn>
nvm fixed it
<ELLIOTTCABLE>
devyn: you badly need a new avatar. :P
<devyn>
ELLIOTTCABLE: I have like 5 different ones floating around; the github one is kinda old. should change it though.
<devyn>
ELLIOTTCABLE: and yeah I agree, but the only abstraction I can think of is basically what I did: create an execution and give it a copy of itself in its locals
<devyn>
ELLIOTTCABLE: what do you think of [;] = [locals] btw?
<ELLIOTTCABLE>
er
<ELLIOTTCABLE>
finding the pair on locals, for which the key is locals itself? what's your use-case?
<devyn>
well you know how [locals] returns locals itself, currently?
<ELLIOTTCABLE>
and either way: syntactic sugar at the cPaws level just seems pointless. Best-case, it makes a small number of low-level abstractions a little easier; and worst-case, it discourages us from working on the preprocessor design soon :P
<devyn>
well semicolons make that unnecessary
<ELLIOTTCABLE>
ah yiss?
<devyn>
because while [] is special, [;] is not
<devyn>
and [;] ends up returning locals
<ELLIOTTCABLE>
hold on don't twist my brain with that just yet, doing a writeup
<purr\Paws>
[Issues] ELLIOTTCABLE comment on issue #4: Well, this is exactly the thing that, if you look at it one way, stops being an issue, if we're discarding ordering *anyway*. All this issue is really saying is that the implicit-ordering system that sort of exists in the current spec, really provides nothing useful: if the above example is so flawed that we need to invoke responsibility to make it predictable (which, by the way, is the solution t
<ELLIOTTCABLE>
wat? no link, purr?
<devyn>
ELLIOTTCABLE: avatar better?
<ELLIOTTCABLE>
devyn: sure
<ELLIOTTCABLE>
devyn: it's light on the googly eyes, but that's just a nitpick
<ELLIOTTCABLE>
so. let's chat Paws.
<devyn>
hahaha
<ELLIOTTCABLE>
I forgot about #4.
<devyn>
sure
<ELLIOTTCABLE>
by the way:
<ELLIOTTCABLE>
I *really* want to put some concerted effort into summarizing all our work (and there *is* a lot of work that happens exclusively in here: entire fucking design stages that never even get written into a spec or commented on anywhere or implemented, that then get thrown away when we come up with a problem and tweak them further.) somewhere reliable and
<ELLIOTTCABLE>
permenant
<ELLIOTTCABLE>
i.e. GitHub Issues, unless someone's got a better idea.
<ELLIOTTCABLE>
but anyway.
<ELLIOTTCABLE>
brought it up there but
<devyn>
yeah, I think gh issues are a good place to track discussion efforts
<ELLIOTTCABLE>
#4 belongs to a whole class of problems with ordering.
<devyn>
yep
<ELLIOTTCABLE>
and that's *far* more of a blocker for me, than nebulous performance issues
<devyn>
like I said, I'm actually not sure why the current ParallelReactor in Paws.rs even works
<devyn>
like I literally don't know why
<ELLIOTTCABLE>
*even if* those issues hit home on one of the the three fucking words I chose as Paws' tagline :P
<ELLIOTTCABLE>
(what's the inverse of a race condition?)
<ELLIOTTCABLE>
(like, instead of something working sometimes because of timing, but then you notice it's broken *because* it sometimes doesn't work …)
<devyn>
uhhh
<devyn>
dunno
<ELLIOTTCABLE>
(… you already know it's broken, but it works perfectly, causing you to notice that maybe it's not broken)
<ELLIOTTCABLE>
anyway
<devyn>
lol
<purr>
lol
<devyn>
basically that though
<ELLIOTTCABLE>
so, here's my issue with non-ordering:
<ELLIOTTCABLE>
it will mean *several orders of magnitude* more responsibility work.
<ELLIOTTCABLE>
the code we'd be writing for the lowest layers of abstraction, is going to get unbelievably insane, if we have to encode specific responsibility-ordering crap.
<ELLIOTTCABLE>
I haven't tried to do it yet, mind you, so I'm talking mostly out of intuition, but … it's clear to me that it's going to be horrific.
<devyn>
honestly the simplest solution, even though I know you don't like it, is to make everything always return somehow
<ELLIOTTCABLE>
-learn intuition = your ass
<purr>
ELLIOTTCABLE: Learned `intuition`.
<devyn>
solves it completely
<ELLIOTTCABLE>
to do this, I suspect heavily that we're going to find that we need a *lot* of work on responsibility itself
<ELLIOTTCABLE>
making it more first-class in the design. I'm talking stuff that's going to tear up a lot of what we've got so far. (which is fine, if needs-be.)
<ELLIOTTCABLE>
or, to rephrase all of the above … to remove implicit ordering constraints, we'll need explicit ordering constraints … and what's good at explicit ordering? Tires.
<ELLIOTTCABLE>
“We'll need to make Paws more Tiresey.”
<ELLIOTTCABLE>
and this brings up a related issue that's basically been consuming my Paws-related mindspace for a while, now:
<ELLIOTTCABLE>
responsibility is just currently painful.
<ELLIOTTCABLE>
and it's too *useful* to be painful.
<ELLIOTTCABLE>
more on this later, though.
<ELLIOTTCABLE>
I don't see myself taking it as *far* as tires, for several reasons
<ELLIOTTCABLE>
(for one, I've got serious concerns about the abstractability of the Tires approach: it doesn't look like something that'll abstract well. I think it'll need to be much more traditional, if I *do* build it; with a lot of things built into the syntax or special-cased, to be usable.)
<ELLIOTTCABLE>
but … nonetheless, there's several “first-class” concepts in Paws (function-calls are basically first-class members of the design, for instance; except in specialized situations, you can often stage something without calling `stage()`, simply using the syntax / arrangement of script nodes),
<ELLIOTTCABLE>
and responsibility isn't currently one of them. It's thrown out into natives that you call, and left there.
<devyn>
I think it's still worth noting that responsibility totally isn't necessary if all of the natives return somewhere… if not to caller, then somewhere else explicit
<devyn>
hell it could even be void if you don't care
<ELLIOTTCABLE>
that still only makes it not necessary *for using the natives*.
<devyn>
well, I mean, responsibility still is necessary, just not in this case I mean
<devyn>
no, if user routines are designed in that way too, then ordering is still explicit
<ELLIOTTCABLE>
the kinds of interaction-patterns currently used in the natives are ones I *want to be valid*; even if it's expident or meaningful for all the natives to be re-designed to return, we still need to address the issues currently impacting them
<devyn>
I know it's kinda 'ugly' but I think it's less ugly than any responsibility based approach
<ELLIOTTCABLE>
by the way:
<devyn>
the thing is, to do this with responsibility relies on the fact that responsibility is dropped when an execution is completed
<ELLIOTTCABLE>
relevant-ish-ly,
<ELLIOTTCABLE>
‘Paws' booleans’ work.
<ELLIOTTCABLE>
`not` is trivial to implement.
<ELLIOTTCABLE>
to my surprise.
<ELLIOTTCABLE>
here's the realization:
<ELLIOTTCABLE>
it's not “non-returning” that's the falsey side of the boolean, with returning being the truthy side
<ELLIOTTCABLE>
it's *completion* that's the falsey, and returning being truthy.
Sgeo has joined #elliottcable
<devyn>
yes, we went over this before
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
very churchey, except instead of taking two continuations (or lambdas, or whatever), we use another property of the system to semaphore one of the two states, and only take a single continuation
<devyn>
I still think that's problematic
<ELLIOTTCABLE>
oh, sure, I'm about 70-80% on including a native true/false
<ELLIOTTCABLE>
*even if* they're actually continuations which operate churchily or something
<ELLIOTTCABLE>
but this is still a relevant note:
<ELLIOTTCABLE>
‘completion’ is seeming more and more crucial to Paws, in my head
<ELLIOTTCABLE>
and that's relevant *because* completion is basically an aspect of responsibility.
<ELLIOTTCABLE>
responsibility system just needs some love, period.
<devyn>
agreed
<ELLIOTTCABLE>
improving the traditional uses,
<ELLIOTTCABLE>
improving the usage *enough* to solve things like #4 and to contribute to #15,
<ELLIOTTCABLE>
and making completion a little more first-class.
<ELLIOTTCABLE>
among, probably, other shit.
<devyn>
so how do you plan to make it more first-class?
<devyn>
because I don't really think stage_receiver (i.e. execution default receiver) can be modified in a way that makes sense for this
<devyn>
which I know you were thinking about before
<ELLIOTTCABLE>
thinking about it a lot
<ELLIOTTCABLE>
I think too syntactically, for some of this.
<ELLIOTTCABLE>
I *try* to be ivory-tower about everything, but I'm actually surprisingly bad at it.
<ELLIOTTCABLE>
#14: your solution seems a little different from mine.
<devyn>
I don't think it helps
<devyn>
so, forget about my solution
<ELLIOTTCABLE>
I'm saying abstract it:
<ELLIOTTCABLE>
write a routine `loop` that, given an execution, clones it … resumes the original with the clone (which will be pointing at the call to `loop`)
<ELLIOTTCABLE>
but yeah two ways to do it: remember, resumptions are free-form
<devyn>
ELLIOTTCABLE: make a routine {loop [blah; blah; blah; loop]} and give it itself as loop
<ELLIOTTCABLE>
oh lol that too
<purr>
lol
<ELLIOTTCABLE>
think this:
<ELLIOTTCABLE>
`loop`, the same execution, not clones thereof, gets advanced once, with the original of the caller; it clones itself, and resumes a clone of the caller with itself.
<ELLIOTTCABLE>
er, sorry, with a *clone of itself*.
<ELLIOTTCABLE>
caller can then resume clone-of-loop, which re-clones the original caller, resumes the newest clone …
<ELLIOTTCABLE>
I think. uh. need to write it down.