jdhartley has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
devyn has joined #elliottcable
devyn has quit [Ping timeout: 255 seconds]
devyn has joined #elliottcable
<purr>
<alexgordon> FUCK cups
<racaille>
>:(
<prophile>
cups of fuck
<whitequark>
mmmmmmm
<whitequark>
EC: PING
<ec>
who the hell is racaille
<ec>
whitequark: WHAT
<ec>
whitequark: shoulda tweeted at me brah
<ec>
whitequark: hi brah
<whitequark>
hi
<purr>
whitequark: hi!
<ec>
whitequark: hi
<ec>
whitequark: whazzup
<whitequark>
-draft
<whitequark>
or how was it called
<whitequark>
-paws
<purr>
whitequark: “the scientology of programming langiages” <http://ell.io/iksN9>
<whitequark>
ugh
<whitequark>
EC: WHAT HAVE YOU DONE ON PAWS YET
<ec>
how do yew mean
<ec>
been driving, brah
<ec>
and it's -spec
<whitequark>
-spec
<purr>
whitequark: Paws' half-arsed Version 10 specification <http://ell.io/ihQzs>
<ec>
whitequark: gmail address, so I can add you?
<whitequark>
ec: I'm already there
<whitequark>
for years!
<ec>
what
<ec>
no, I mean, to give you access
<ec>
right now you're anonymous! D:
<whitequark>
mhm? I can read
<whitequark>
whitequark@gmail.com by the way, in case IT WASN'T OBVIOUS :p
<ec>
ISN'T OBVIOUS
<devyn>
GUYS
<ec>
omg devyn
<ec>
devyn: you too, gmail addy
<devyn>
my server won't crash every 5 minutes any more!
<devyn>
wow holy shit
<ec>
devyn: what?
<devyn>
spec
<devyn>
kind of impressive now
<ec>
what about it?
<ec>
is it?
<ec>
it's not even half done, for the stuff we have *now* |=
<devyn>
it's still looking good
* devyn
pats ec on the back
<ec>
awwww
<ec>
well CONTRIBUTE BITCH
<ec>
:D
<ec>
(also you're a bat)
<ec>
(gmail so you can be a devyn)
<devyn>
devyn.cairns@gmail.com
<devyn>
you already have had it
<devyn>
I also have me@devyn.me when I feel like being an egomaniac
<ec>
sent
<devyn>
cool I have no idea what to do
<ec>
what we're doing, is talking through all of the design that exists right now
<ec>
looking for inconsistencies, holes, and unspecified bits
<ec>
and as we work through it, I'm doing my best to write a normative spec
<ec>
or, at least, a first stab at one
<ec>
since I'm crashing soon: best you can do for me, is read through everything that's there, and try to find errors, try to break it, try to find contradictions, etc
<ec>
there's always as many elements in the stack, as you are deep into sub-expressions. If there's no previous combination-result to *put* in the stack, there's an empty index there instead.
<ec>
and when you're combining against an empty index, it's an *implicit* combination. obviously.
<ec>
i.e. against locals, as described in the spec.
<ec>
with me?
<alexgordon>
right
<alexgordon>
the null stuff is weird
<alexgordon>
I think it's just your notation though
<ec>
yeah
<ec>
it definitely is
<ec>
this is a tightly-coupled mess.
<ec>
For Design-11, I'm going to rip *all* of this out. FYI.
<alexgordon>
lol
<purr>
lol
<ec>
replace it with practically identical semantics,
<ec>
but defined in terms of *reductive* coroutines
<ec>
that is, replacing elements in the Script *with the results*
<ec>
So,,,,,,
<ec>
no. not going to muddle your view of things with future-changes yet.
<alexgordon>
elol
<alexgordon>
eh
<ec>
so, that was the first thing you needed to know: how ((foo)) works
<ec>
but here's a puzzler for you:
<alexgordon>
why not leave implementation details to me
<ec>
`foo () bar`
<alexgordon>
just say how it should wok
<alexgordon>
work
<ec>
only because *at the moment*, I can only *explain* it in terms of impl-details
<ec>
which is my own fault, and I'm sorry for it. It'll be improving with the next version of the design.
<ec>
I think I'm going to split the next version of the spec into three completely separate sections:
<alexgordon>
ec: I just worry
<alexgordon>
that if you keep changing how things are explained
<alexgordon>
it makes it difficult to keep up
<alexgordon>
stick to one model, however shoddy
<ec>
Grammar, Paws' Object-Model (defined native interfaces for object types, and defined algorithms for methods of those types), and then an Operational Semantics (rules from *within* the language)
<alexgordon>
make the changes you need
* ec
nods
<ec>
but now, we're *spec'ing* it. Which means all the changes are written down. Which improves that massively.
<alexgordon>
ec: also if you define in coroutines, how is anybody going to implement it in languages without coroutines?
<ec>
wat?
<ec>
okay. queue that.
<alexgordon>
you said you were going to replace it with a definition in coroutines
<alexgordon>
I prefer the current definition
<ec>
-queue "ec: also if you define in coroutines, how is anybody going to implement it in languages without coroutines?" @ alexgordon
<alexgordon>
lol
<purr>
lol
<ec>
'k.
<ec>
very important thing:
<ec>
since the `foo () bar` is *completely* senseless in the framework I've just outlined, we intentionally override it with special meaning, outside of that framework.
<ec>
An empty expression in a Script results in the currently-executing execution.
<ec>
we generally write it as <me>, or since I've been tagging types here, E<me>
<ec>
so:
<ec>
`[foo] () bar`, {O<foo>}
<ec>
COMBINE(O<foo>, E<me>)
<ec>
=> O<return-value>
<ec>
`foo [()] bar`, {O<return-value>}
<ec>
COMBINE(O<rv>, S'bar')
<ec>
presumably, (although not necessarily), O<foo> is an execution; and thus, we're calling it.
<ec>
then we're looking up S'bar' on whatever it re-calls us with, or, “returns” to us.
<ec>
make sense?
<alexgordon>
wtf is O<return-vaule>
<ec>
just the result of COMBINE(O<foo>, E<me>)
<ec>
the assumption was that O<foo> is actually an E<foo>
<alexgordon>
k
<ec>
so, we're resuming some execution, that we're calling <foo>, with *ourselves*
<ec>
some time later, they call that *ourself*-execution, so we resume, with a resumption value from them.
<ec>
a “return” value.
<alexgordon>
so is that it for advancing executions?
<ec>
shouldn't be difficult to read therefore, I hope
<ec>
in that implementation, advance() *takes* an Object
<ec>
that Object being the result-of-the-previous-combination
<ec>
because it's a tightly-coupled mess that *also* handles the ->stack as described above
<ec>
I *want* to spec advance() (PC-management) and push()/pop() (stack-management) seperately.
<ec>
which is what I'm trying to do right now: un-spaghettify that design enough to specify it.
<alexgordon>
I see
<alexgordon>
ish
<alexgordon>
ec: promise you won't rewrite the whole thing after making this spec LOL
<purr>
LOL
<ec>
I fully intend to.
<alexgordon>
gaah
<alexgordon>
then why make the spec!
<ec>
I'm very open-minded about changing *any* of this, if it becomes necessary for bubbling or distribution.
<ec>
for you?
<ec>
I *told* you it's likely to change a lot.
<ec>
But you guys were entirely right: this is very good for me. For the project.
<alexgordon>
yeah but if you're going to change it, then it'll be out of date in a week or so
<ec>
oh, no, not within a week
<alexgordon>
month
<ec>
I intend to change it only in large increments. The next big change is going to be a few months from now, and I hope for us all to update our respective implementations in tandem.
<ec>
i.e. Design-10 implementations should always run the same code, as they should all be operating off of this spec.
<ec>
but Design-11 will be fixing semantics that I consider broken (the entire point of this iteration *being* to find the broken bits, so we can iterate, and “fix” them), and thus probably be backwards-incompatible with this.
<ec>
and so on, through at least three more iterations.
<ec>
I won't necessary write a whole new spec for each iteration, nor will we necessarily have to throw out much code. Depends on what all we find that is broken.
<alexgordon>
fixing stuff is alright
<alexgordon>
but redesigning the whole thing is dizzying
<ec>
But, seriously, if we find out that an object system where every object is a function, is more in-line with my goals for distribution, and I think it fits into the parts of the design I care about well … then I'll damn-well throw away three quarters of this spec and re-write it in terms of objects-as-functions.
<ec>
lol, I've already re-designed the entire thing a solid five times.
<purr>
lol
<alexgordon>
exactly
<alexgordon>
you need to settle down
<ec>
Stratums 2, 3, 5, and 7 each changed a solid 80% of the specifics of the language.
<ec>
Strata*
* ec
shrugs
<purr>
¯\(º_o)/¯
<alexgordon>
thing is
<ec>
I know what I'm doing. Okay? Trust me on this?
<ec>
I'm not going to change everything endlessly and iterate forever: I have very specific goals.
<alexgordon>
if nobody else understands it, because you're the only one who can keep pace...
<ec>
Listen: I can tell you with genuine confidence that we're near the end of the changes related to the stuff you're learning.
<alexgordon>
then it limits the *other* problems that people can find
<alexgordon>
you need other people to look at the design
<ec>
The only way this changes much, is if we find *problems* with it, and how it interacts with my goals related to transactions and distribution.
<ec>
(for instance, if we find out that this object-model is extremely unfriendly to distribution … or that moving-forward executions are completely incompatible with the transactional error system I want.)
<ec>
make sense?
<ec>
so it's much less likely to change now than it was in the past; and if it does so, it will be because it *has* to.
<alexgordon>
I get the idea that you live in a different planet to me
<ec>
in other words: the likelihood of change is trending *downwards* with time, as everything begins to fit together elegantly.
<alexgordon>
yeah but we've been doing this for years...
<ec>
change is still possible, even likely, but less and less drastic change, as most of the big incompatibilities are ironed out.
<alexgordon>
gotta stop some time
<ec>
not really.
<alexgordon>
say "enough is enough"
<ec>
there's been maybe a solid year-and-a-half of real, forward-moving effort, by *one person* for the most part, on Paws' design. and even then, as a free-time project; far from full-time.
<ec>
there's more people truly involved now; and we're solidly 3/4rs through the mutable design stage.
<alexgordon>
point is, if you started a project (when was it? 2009?) and then 4 years later you're still redesigning the whole damn thing… what's the probability that it will ever be stable
* ec
shrugs
<purr>
¯\(º_o)/¯
<ec>
minus approximately a year lost, collectively, towards World of Warcraft obsession and a big location-move/relationship on my part that's turned out to be a mess,
<ec>
we're right on schedule.
<alexgordon>
stratum 10!
<alexgordon>
that's a big numbe
<alexgordon>
r
<ec>
Paws is always going to have big version numbers.
<ec>
I fucking hate semver; I'll be incrementing the number every time I damn feel like it.
<alexgordon>
it just seems silly to go to all this work to make a spec, then in a month it'll all be out of date
<ec>
Paws.js version 50 is a solid possibility within the year.
<alexgordon>
and paws will once again only exist in your noggin
<ec>
not at all
<ec>
I intend to keep a version of the spec solidly in-line with any changes we make; and to boot, all changes from here on out will be discussed on GitHub Issues.
<alexgordon>
right but you need me to do that
<ec>
Timeline: I wanted a solid, design-stable (for the most part) Paws Nucleus, and a partially-designed and partially-implemented Paws Core, by 2014.
<ec>
At least three widely differing, mutually federating, implementations of that stable Nucleus spec, themselves at least alpha-quality and relatively stable, all properly executing the in-progress Core implementation, before 2015.
<ec>
I'd say I'm a solid year behind on that schedule; *but* I also now have more people involved than I previously thought I would. I always assumed I'd be doing this entirely alone; but micah's solidly involved, and now I've managed to re-rope you, prophile, and whitequark into the spec-work at the very *least*, if not talking about a compiler.
* ec
shrugs
<purr>
¯\(º_o)/¯
<ec>
I'm optimistic.
<ec>
all make some kind of sensE?
<alexgordon>
yes but I can only contribute so long as we have these kinds of spec-building sessions *on irc*
<ec>
Don't get me wrong. I *believe* I understand your objections. I'm trying to demonstrate why there's nothing to worry about, *without* having to say “NO WE'RE NOT CHANGING THE DESIGN ANYMORE.”
<alexgordon>
github issues doesn't cut it: it's too slow
<ec>
I'm more interested in a more *coherent* product, a year later down the road, than a half-arsed *mostly* coherent product with tacked-on distribution that doesn't really work well, a year earlier.
<alexgordon>
if you rewrite half of it, and suddenly I don't understand it anymore, then there's nothing I can do
<ec>
That said, I have zero desire to drag this out *indefinitely*.
<ec>
There's a big difference to me between “a year later” and “three years later.”
<ec>
alexgordon: You're building one of less-than-five extant implementations.
<alexgordon>
at the moment, while it's current
<ec>
alexgordon: believe me, I'll keep you *thoroughly* appraised of any changes I'm considering. ;)
<alexgordon>
yeah but your idea of full appraisal generally involves a metric shitton of technobabble
* ec
laughs
<ec>
and that's what we're working on right now.
<ec>
a spec, without Elliottbabble.
<ec>
that's, y'know, *why you're here*.
<alexgordon>
right
<ec>
Don't worry so much. It'll all be okay.
<alexgordon>
but I have to be here, every step of the way, apparently
<ec>
well, for now.
<ec>
I think I'm getting the hand of being a little more alexgordon-compatible with the terminology, no?
<ec>
so. advancement, although it's a spaghetti clusterfuck, you understand, yes?
<alexgordon>
I don't see the spaghetti clusterfuck
<alexgordon>
unless you mean that js code
<ec>
well, basically, the stack-handling and PC-handling have to be handled *together*.
<ec>
which means that advancement needs to be *aware* of the result of the last combination.
* alexgordon
makes a prediction that 6 months from now, the spec will either be: A) an indecipherable heap of elliottbabble, B) completely out of date
<ec>
I'm trying to remove that coupling: the advancement algorithm should be spec'd independently of any context with regards to the actual stack, and vice versa
<ec>
Well, if you stick around and help me prevent that, it'd be pretty great.
<ec>
(Not that I think it's particularly a foregone conclusion *without* your assistance, but …)
<alexgordon>
I don't know if I have the patience to stick around through another 10 strata
<alexgordon>
it gets difficult, keeping track of both what's new, and what's obsolete
<ec>
three*
<ec>
basically, here's what you should expect. tell me if you think this is unreasoanble.
<ec>
First off, now that we're spec'ing it, we're finding some new inconsistencies in the design. Also, there's some open questions left over from the whirlwind changes of about a year ago. I want to clear those up; and altogether, I expect they *might* make reasonably major changes to the semantics (let's say, ≥ 20%). We'll call that D11.
<ec>
Then, we need error-handling. obviously, there's some interesting stuff with transactions in the pipes. We need to smooth that partially-specified plans into real spec, and find the problems and inconsistencies with what has been discussed. That'll be D12.
<alexgordon>
ec: there is a big difference between *tweaking inconsistencies* and *redesigning half of everything*
<alexgordon>
small changes are good
<ec>
Finally, distribution, the last big huzzah. Everything *else* should be stable by then, so we just need to figure out how the design handles being spread out like that. D13.
<alexgordon>
I feel like if you o
<alexgordon>
oops
<alexgordon>
well whatever
<alexgordon>
I've said it already
<ec>
Then, *if*, and only if, I feel it's a spaghetti mess, maybe I'll allow for another maintenance iteration wherein we re-work things that don't fit together well after all the new stuff with transactional-error-handling and distribution. So, a possible D14.
<ec>
Three, *maybe* four more iterations, none of which should *change* more than 30% of what exists, isn't bad.
<ec>
And each should change less than the previous one, because the design is already *largely* coherent in my head; we only have to solve problems where what's in my head is naturally inconsistent as it's put to paper, put to code.
* ec
nods
<ec>
talked it to death. I'm curious what incomprehensibly and devyn have to say on the matter. Let's pick it back up later.
<ec>
Up for more spec-work now?
<alexgordon>
-spec
<purr>
alexgordon: Paws' half-arsed Version 10 specification <http://ell.io/ihQzs>
<ec>
brb
<ec>
fuckl
<ec>
errands, storm preperation.
<ec>
will be back later, *hopefully*. unless the cell towers go out.