<ELLIOTTCABLE>
devyn, glowcoil, vigs / vil: anybody around? got some programming-language work from this weekend I totes wanna talk through
<glowcoil>
hi ELLIOTTCABLE
<vigs>
hi
<purr>
vigs: hi!
<vigs>
going to bed soon, but hi
<ELLIOTTCABLE>
aw poo
<glowcoil>
urgh, long day, tired, and work tomorrow :c
<glowcoil>
but i will make an effort to pay attention
<ELLIOTTCABLE>
doesn't really fit with my goals for Paws, but:
<ELLIOTTCABLE>
a new language, with similar semantics,
<ELLIOTTCABLE>
but implicit executions.
<ELLIOTTCABLE>
what *is* an execution, at least in paws?
<ELLIOTTCABLE>
a start, an end, a linear path from one to the other, and an associated scoping.
<ELLIOTTCABLE>
if we get rid of the start and the end (haven't figured out scoping right now, but it's on my mind),
<ELLIOTTCABLE>
then it's just "a linear series of combinations."
<ELLIOTTCABLE>
or specifically, an ordered series of combinations.
<glowcoil>
yesssss
<glowcoil>
(except take out the order and make it a graph ;)
<ELLIOTTCABLE>
shush
<ELLIOTTCABLE>
now, add in branching: since you can branch an execution in Paws at any point, executions no longer necessarily have "a start". There's just some special-case ones, for which the 'start' of the series of combinations was defined ... for the rest, the 'start' was somewhere in the middle of *some other* series of combinations.
<ELLIOTTCABLE>
so, put that on hold.
<ELLIOTTCABLE>
I was thinking heavily (I love roadtrips. Eight hours of straight *thinking*, literally. It's so freeing.) on the old musings about what I was calling "diagonal execution."
<ELLIOTTCABLE>
which boils down to, "let's find a way to spin off multiple series-of-combinations that are part of the same execution, simultaneously." Or rather, spin off multiple *lines* of code, since that's the most common instantiation of that concept.
<ELLIOTTCABLE>
so I ran back into some of the original problems.
<ELLIOTTCABLE>
for one thing, it's really complicating a simple language, fairly fast. that bothered me.
<ELLIOTTCABLE>
for another, clearly, the entire design element of diagonal execution, is determining *dependencies* between lines of code, so you can execute them in an ordered fashion. (line 3 uses variable A, so we have to wait until line 1 finishes *assigning* variable A ... but in the meantime, line 2 can spin off the code to generate variable B simultaneously with
<ELLIOTTCABLE>
line one generating variable A.)
<ELLIOTTCABLE>
but Paws, by extremely intentional design, is extremely dynamic. There *are* no variables, or lexical scope, or anything else. After much deliberation, I've concluded that it's downright impossible to implicitly determine dependency-relationships between given combinations in Paws.
<ELLIOTTCABLE>
so, diagonal execution in Paws is Out(tm).
<ELLIOTTCABLE>
but that's got me on a new train of thought: taking a lot of those observations out of the framework of Paws, while trying to retain as much as I could of the parts I liked, I've got a very interesting new semantic.
<ELLIOTTCABLE>
glowcoil, you've definitely talked some about this, at a high level
* glowcoil
is feeling happy about this so far
<ELLIOTTCABLE>
so. Paws is a language that defines semantics for "zipping" up two graphs, basically: an operations-graph, and a data-graph.
<ELLIOTTCABLE>
processing the operations-graph in a well-defined way, and manipulating the data-graph as the operations-graph describes.
<ELLIOTTCABLE>
so, taking glowcoil's dependencies talk on that operations-graph, what do we have?
<ELLIOTTCABLE>
a series of combinations, each with three kinds of dependencies:
<nuck>
So I just showed somebody ELLIOTTCABLE's avatar and they went "holy shit that guy"
<ELLIOTTCABLE>
zero, or one, "input dependencies" (think: left-hand-side in a Paws combination, or right-hand-side in an indirected combination),
<ELLIOTTCABLE>
(exactly)
<ELLIOTTCABLE>
exactly zero, or one, "output dependencies" (other combinations for which our result is either the left-hand-side or the right-hand-side),
<ELLIOTTCABLE>
and then zero or more "side-effect dependencies" (other combinations whose assumptions about the state of the system depend upon our results.)
<ELLIOTTCABLE>
now, recall the first stuff I said:
<ELLIOTTCABLE>
an "execution", ignoring some of the Paws context the word now has, is basically a single execution-path.
<ELLIOTTCABLE>
every time there's *more than one*, total, of those kinds of dependencies, you have *new* execution paths; but when there's exactly one, it's still a part of the current execution-path.
<ELLIOTTCABLE>
(mind you, that's still *asynchronous*: in this fledgling system, I would still absolutely plan to have those executions be first-class, as they are in Paws, and treated like continuations [I have other thoughts regarding holes, here, too] ... and thus a particular path may have only one output at its current stage, but still be suspended, to be resumed
<ELLIOTTCABLE>
externally at a later date)
<ELLIOTTCABLE>
the "side effect dependencies" are the new element, here: in the semantics for this Paws replacement, if there are no dependencies (side-effect or result) between two combinations, then those two combinations are spun-off simultaneously. Basically, if I had a syntax for this (which I absolutely don't; that's proven an intractable problem, so far), those
<ELLIOTTCABLE>
would be "separate lines of code."
<ELLIOTTCABLE>
now, a Script, in the Paws sense, no longer has sub-scripts in the sense of executions in a Paws program: there's no *specific delineations* here, where a particular code-path must start, and end. Instead, they're more open-ended: anywhere a combination has more than one thing depending on it, a new "execution" starts; and when that code-path has no more
<ELLIOTTCABLE>
combinations pending, it ends.
<ELLIOTTCABLE>
I have no idea what this will *look like*, or how useful it will be, but it definitely satisifies some of my original concerns with diagonal-execution: there's no need for a static element to Paws (i.e. lexical scope, or anything else I find abhorrent in this solution-space) ... because all dependencies are *encoded* into the operation-graph.
<ELLIOTTCABLE>
whether that's from some sort of parser and type-system (some static system, in other words), or something we find a syntax for the programmer to write by hand, either way, the semantics don't need to care. I like that.
<ELLIOTTCABLE>
oh, scope, by the way: I don't know how to replace the "indirection" semantics from the original Paws (if you turned every sub-expression in a traditional execution 'on its side', you'd see a graph remarkably similar to the one emerging from this new semantic, by the way) ... a 'new' series of combinations (basically, ones where each one has a
<ELLIOTTCABLE>
data-dependency on a previous one), such as the beginning of a line, or the beginning of a sub-expression, was *bootstrapped* by combining it against a "locals", representing scope.
<ELLIOTTCABLE>
that scope is an inherent property of executions; now, I've got a new semantic that's a language basically without any sort of scope. yet.
<ELLIOTTCABLE>
I'm thinking of doing some sort of Paws-execution-ish thing, but instead of a {...} where we define both the start *and end* of a code-path, we leave the code-path semantics to what was describe above, *completely divorce* scoping from that, and have a tool to declare the start of a new scope for the rest of the current code-path. idk.
<ELLIOTTCABLE>
anyway.
<ELLIOTTCABLE>
this is my new language work,
<ELLIOTTCABLE>
and I call it Tires.
<devyn>
wow, apparently I have good timing to get on IRC
* devyn
is in the clouds
sharkbot has quit [*.net *.split]
Sgeo_ has joined #elliottcable
vil has quit [Ping timeout: 264 seconds]
sharkbot has joined #elliottcable
Sgeo has quit [Ping timeout: 240 seconds]
* devyn
comes down
<devyn>
ELLIOTTCABLE: hi
<ELLIOTTCABLE>
hi
<purr>
ELLIOTTCABLE: hi!
<ELLIOTTCABLE>
ish
<ELLIOTTCABLE>
i haven't remotely got a syntax to *express* this yet, though. Problem is, how multi-dismensional it is.
<ELLIOTTCABLE>
there's a couple terrible ones.
<devyn>
the best way to handle non-linear dependencies really is something like an SSA form
<devyn>
I think
<ELLIOTTCABLE>
using ASCII lines, for one; and another, treating "width" as a dismension of code
<ELLIOTTCABLE>
(stuff adjacent is data-dependant, as with Paws; stuff more than a whole tab-stop to the right is side-effect dependant; stuff on a new line is independant)
<ELLIOTTCABLE>
or semicolons for a similar semantic
<ELLIOTTCABLE>
but all, just, so, ugly
<devyn>
you're probably going to hate this, but something like LLVM IR, which looks like this
<ELLIOTTCABLE>
oh, I *did* have an interesting one, but everybody'll hate it
<devyn>
%reg0 = a b c...; %reg1 = d e f...; %reg2 = %reg0 %reg1
<devyn>
basically you can never redefine them
<ELLIOTTCABLE>
yeah, familiarish
<devyn>
so like, implicit linear dependency like Paws for just combining like that with spaces
<devyn>
and then an SSA-form for joining multiple
<ELLIOTTCABLE>
yeah, but that seperates concerns in a way I don't like
<ELLIOTTCABLE>
I want a syntax as close as possible to the *actual graph* you'd be drawing.
<ELLIOTTCABLE>
I forgot completely about this, but here's something I was coming up with on the drive:
<ELLIOTTCABLE>
it'd drive everybody *batshit nuts*, because it's the complete opposite of everything they're used to ... but it maintains visual ordering of events (left-to-right, top-to-bottom-ish) as expected
<ELLIOTTCABLE>
unfortunately, it's also a harder compile-target than Paws currently is
<devyn>
needs explanation :p
<ELLIOTTCABLE>
and being so into Lisps lately, I'm a biiiiiiig fan of simple non-syntaxes like s-expressions and cPaws
<ELLIOTTCABLE>
the last combination on line 1 is data-dependant on the result of the <widget-result>+dongle *and* <foo-result>+bar combinations,
<ELLIOTTCABLE>
as with Paws,
<ELLIOTTCABLE>
line 2 is completely un-dependant on that, as it is at the same indentation level,
<devyn>
it really isn't enough. even in Lisp you use let-expressions
vil has joined #elliottcable
<devyn>
and touching locals all the time is not so nice for this; we want something the compiler can be more easily aware of
<ELLIOTTCABLE>
but line 3 is dependant on both finishing.
<ELLIOTTCABLE>
it still can't express *all* possible dependency graphs, but I'm sure you're familiar with the fact that i'm not worried about a textual syntax encoding all possible programs ... just the common and commonly desirable ones.
<ELLIOTTCABLE>
and many-to-one dependency is the most likely.
<ELLIOTTCABLE>
idk it's a first stab, but it has some advantages:
<ELLIOTTCABLE>
ugh I'm tired
<ELLIOTTCABLE>
ha ha ha 'tired'
<devyn>
what are the advantages, really, other than looking clean
<devyn>
because frankly I'd rather have something that more accurately represents the graph even if it doesn't visually look like it
<devyn>
this is more like a tree
<devyn>
I think it's also more useful to talk about dependencies in terms of actual values than explicit statement-level dependency ordering
<ELLIOTTCABLE>
er, that's missing the point
<ELLIOTTCABLE>
Paws' existing form already expresses value-dependencies
<ELLIOTTCABLE>
the point here is to express side-effect dependencies
<ELLIOTTCABLE>
(remember, lession 1: Paws is an anti-functional language, everything interesting happens as a side-effect)
<devyn>
right right
<devyn>
ok
<devyn>
hmm
<devyn>
what about line 3 and 4
<devyn>
unrelated?
<ELLIOTTCABLE>
with the original diagonal-evaluation stuff, you basically would have to assign dummy-values to "variables" in order to order things
<ELLIOTTCABLE>
whereas here, ordering is always explicit in the Script
<ELLIOTTCABLE>
lines 1, 2, and 4 all spin off simultaneously, yes.
<ELLIOTTCABLE>
considering doing the same sort of thing with parenthesis, somehow, because explicit syntax is more composable and abstractable (in the Paws / Lisp sense) than implicit, whitebase-based syntax.
<ELLIOTTCABLE>
the latter being a sugar for the former.
<devyn>
what if I were to insert a further-indented line above 1 and a further-indented line above 2
<ELLIOTTCABLE>
gist it, wat
<devyn>
and frankly I still think the best way would be to have 'named actions' and draw out dependencies much the way a Makefile does, for explicit syntax
<ELLIOTTCABLE>
the problem is in needing to name every leaf of the graph. /=
<ELLIOTTCABLE>
and gets really verbose, really fast
<devyn>
yes, but that's actually the simplest and most optimal for code generation, if we're talking about Tires as a target for higher-level code
<devyn>
and implementation is so simple that way too
<ELLIOTTCABLE>
here's the same stuff translated into a bracketed syntax:
<ELLIOTTCABLE>
[foo bar (widget dongle); baz mud] wibble wobble; spaz
<ELLIOTTCABLE>
well, remember, again like Lisp and as with the original Paws, I fucking *hate* generated code
<ELLIOTTCABLE>
this is a toolkit targeted by abstraction, not by compilation
<ELLIOTTCABLE>
basically, each minute layer of abstraction (each macro, each function, each library), when peeled away, should still be human-usable, human-sane
<ELLIOTTCABLE>
in yours, lines 1, 3, and 6 are spun off first,
<ELLIOTTCABLE>
2 when 1 completes, 4 when 3 completes, and 5 when all of those are complete.
<devyn>
what happens if I have a program I want to write that doesn't fit into that
<devyn>
how do I make the ordering work then
<ELLIOTTCABLE>
need a different syntax. probably a graphical editor, or a different textual syntax that makes different trade-offs.
<devyn>
right, so if we're talking at the Script, binary-level, probably still want Makefile-esque dependencies
<ELLIOTTCABLE>
just as with Paws, because of the complexity of what "code" means, when dealing with asynchronous systems and complex dependancies, text falls short; and a more usable *subset* syntax becomes the full *data-type* representation instead.
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
no, it'll be a graph
<devyn>
er
<devyn>
oops
<devyn>
yeah
<devyn>
haha
<devyn>
duh
<ELLIOTTCABLE>
same as current Script, actually, but with additional poitners on the nodes
<ELLIOTTCABLE>
pointers*
<devyn>
would that be a go-to or come-from pattern, Script-wise
<ELLIOTTCABLE>
basically, think current Script, but in addition to the data-dependency "next" node, plus sub-expressions, you'll also have a "depends_on" array for pointers to other nodes
<devyn>
how would that work
<ELLIOTTCABLE>
honestly, I think I'd revamp the design to be all come-from.
<ELLIOTTCABLE>
but that's something that's implementation-specific, unless I try to bring the distributed-semantics goals of Paws into this as well.
<devyn>
ok so what if multiple Nodes have a specific Node as their come-from; how does the engine resolve that with that data structure
<devyn>
obviously you don't just want it executed twice
<ELLIOTTCABLE>
that's exactly what the above syntactic example conveys
<ELLIOTTCABLE>
a combination is only valid to preform when *all* of its dependencies (both data, and side-effect) are completed.
<ELLIOTTCABLE>
as with Paws, combinations would be "one-shot" ... that is, to execute the same combination (or more usefully, series-of-combinations, i.e. line of code) more than once, you have to *branch* at a previous point in the program.
<ELLIOTTCABLE>
I still haven't figured out how I want to relate all of this to locking semantics, i.e. ownership-stuff,
<ELLIOTTCABLE>
because this is all just a wild idea, and nowhere near *usable* yet.
<ELLIOTTCABLE>
(this whole design, at the moment, basically requires the programmer to be completely aware of all possible side-effects of the entire system, and encode concurrency-safety into his script to account for them.)
<ELLIOTTCABLE>
(impossibly terrible. clearly a stepping-stone to a more evolved system.)
<devyn>
ok, so, hoold on, so I have `[abc; def] foo; bar`, right. what happens if instead of that I want [abc; def]'s completion to spawn both foo and bar, instead of having bar spawned immediately
<ELLIOTTCABLE>
that's one-to-many, and not represented by this syntax at all. that's where you've either got to resort to data-level hacks (assigning it to a variable, like ssa, I suppose? idk yet?), or use a different syntax.
<devyn>
ok but Script-level, one-to-many
<devyn>
I know, obviously, how that works with pointeres
<devyn>
pointers*
<ELLIOTTCABLE>
hm, could you do that with more brackets? does that make sense?
<ELLIOTTCABLE>
[abc; def] [foo; bar]
<ELLIOTTCABLE>
does that work in all situations ...
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
by the way, if *not*, instead of assigning to a variable, one possible hack is to make bar dependant on foo
<ELLIOTTCABLE>
you lose concurrency there, but maintain the ordering you want
<ELLIOTTCABLE>
basically making the two of those sequential
<ELLIOTTCABLE>
[abc; def] foo] bar]
<devyn>
no, let's say I actually want foo and bar to be able to be executed in parallel
<devyn>
because that's a very real-world thing
<ELLIOTTCABLE>
yeah, then, I bet we can actually express that
<ELLIOTTCABLE>
oh of course it is
<ELLIOTTCABLE>
my assertion wasn't "one to many isn't useful"
<devyn>
yeah
<devyn>
I know
<ELLIOTTCABLE>
just that "many to one is *more* useful"
<ELLIOTTCABLE>
actually could even be wrong there.
<ELLIOTTCABLE>
anyway.
<ELLIOTTCABLE>
need more meaningful code to start exploring these things. I should throw together a simple code-example, likethe ones that spawned Paws.
<devyn>
oh man there's something just on the tip of my tongue that might solve this
<devyn>
hmmm
<ELLIOTTCABLE>
okay, so, the [][] approach solves *some* of those situations, but still can't represent an entirety of possible Scripts,
<ELLIOTTCABLE>
but it definitely handles *most*.
<ELLIOTTCABLE>
it can handle many-to-many, and many-to-one, and one-to-many,
<ELLIOTTCABLE>
but not **arbitrary** many-to-many.
<ELLIOTTCABLE>
the subsets of many-to-many specifically (not mto, or otm) must not have interrelationships amongst themselves.
<ELLIOTTCABLE>
idk the computer-science term, but I'll call it a "segregated directed acyclic graph."
<devyn>
okay, let's say `;` always means "can be executed in parallel". [] means 'fork off at this point. everything before this must complete first, and everything in here must complete before we can move forward'
<ELLIOTTCABLE>
so, in `[abc; def] [ghi; jkl]`, there's no further way to define the additional relationship "jkl depends on def".
<ELLIOTTCABLE>
er, what, that sounds wrong
<ELLIOTTCABLE>
thinking too synchronously
<devyn>
if you do [abc; def] [ghi; jkl], both 'ghi' and 'jkl' depend on both 'abc' and 'def'
<ELLIOTTCABLE>
[] only defines a dependancy relationship between the stuff inside of it, and the token to the immediate right of it.
<devyn>
it's basically a barrier
<ELLIOTTCABLE>
in the syntax used so far, anyway.
<ELLIOTTCABLE>
yah, sounds accurate, yah?
<ELLIOTTCABLE>
I hate this syntax, but it works :P
<ELLIOTTCABLE>
definitely something that would need some beautiful abstractions on top of it >,>
<devyn>
hmmmmm
<ELLIOTTCABLE>
so the question is, how common is an inter-relationship-y many-to-many dependancy?
<ELLIOTTCABLE>
can you even think of a single example? I can't, right now.
<devyn>
the thing is, would `foo [bar; baz] bax [bonz; ber]` be legal? what would that even mean?
<ELLIOTTCABLE>
simple.
<ELLIOTTCABLE>
think of it this way:
<devyn>
actually, that would make sense to do if it were more like (foo bar) [bar; baz] x -- basically saying we can execute (foo bar), then [bar; baz] in parallel, then combine 'x' with (foo bar)'s result
<devyn>
it makes sense with a subexpression
<ELLIOTTCABLE>
adjacent object-token declares dependancy (data-dep, obviously, 'cuz we need the result) on the combo involving the token to the left
<ELLIOTTCABLE>
oh, you're right, mixing data-deps into this tree becomes problematic fast.
<ELLIOTTCABLE>
nah, just like semicolon, brackets break the data-dep chain.
<ELLIOTTCABLE>
think of [] as being preceded by an implicit semicolon:
<ELLIOTTCABLE>
foo bar; [bar; baz] x
<devyn>
I actually think it could be useful
<devyn>
and not problematic
<devyn>
basically the brackets disappear and have no bearing on data-dependency whatsoever
<ELLIOTTCABLE>
can't conflate data-dep ("combine x against") with that, because then how do you say, "x is a new statement, side-dependant on those brackets"?
<ELLIOTTCABLE>
which was the meaning as defined so bar
<ELLIOTTCABLE>
so far*
<devyn>
to say x is a new statement, side-dep on those brackets, you just add the semicolon
<devyn>
but without it
<ELLIOTTCABLE>
er,
<devyn>
it means the combination of x with the previous thing in our data-dep ordering is side-effect dependent on that bracketed thing
<ELLIOTTCABLE>
so far, semicolon has described non-dependency.
<devyn>
yes
<devyn>
I'm saying:
<ELLIOTTCABLE>
okay, then in that syntax, how do you describe the same, with x non-dependant on any of those?
<ELLIOTTCABLE>
re-phrase: show me all three, seperately, of the following:
<ELLIOTTCABLE>
each starting with (foo bar) [baz; widget],
<ELLIOTTCABLE>
A) x data-dependant on (foo bar) and order-dependat on baz;widget
<ELLIOTTCABLE>
B) x order-dependant on [baz; widget] (and therefore foo-bar as well),
<ELLIOTTCABLE>
C) x non-dependant on any of the above
<devyn>
A) (foo bar) [baz; widget] x
<devyn>
B) [(foo bar)] [baz; widget] x
<devyn>
C) [(foo bar)] [baz; widget]; x
<ELLIOTTCABLE>
nono B is implicit, because [baz widget] is already ordered after (foo bar)
<ELLIOTTCABLE>
and the question is, in B, how do I write it different from A so that it's not data-dependant
<devyn>
right, we don't need the first pair of brackets for B or C
<devyn>
ok
<devyn>
hm
<ELLIOTTCABLE>
so.
<ELLIOTTCABLE>
sorry, was tearing that down, 'cuz I saw problems, didn't mean to be mean :D
<ELLIOTTCABLE>
but I agree.
<devyn>
actually, yes! B works the way it is
<ELLIOTTCABLE>
semicolon and brackets are already pretty meaningful as described above ..
<devyn>
the brackets would prevent the data dependency
<ELLIOTTCABLE>
how can we carry data-dependency through ...
<devyn>
[(foo bar)] [baz; widget] x
<devyn>
I stand by that for B
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
I feel like there's an issue
<devyn>
just say brackets never affect data dependency, only order dependency, and the stuff outside is always data dependency
<ELLIOTTCABLE>
hol onenanigraw
<ELLIOTTCABLE>
I can't quite wrap my head around that. Feels complex? And I definitely sniff out an issue, I just, can't, put, my, finger, on, it,
<ELLIOTTCABLE>
idea.
<ELLIOTTCABLE>
we don't have sub-scripts anymore, so we've got {} ...
<ELLIOTTCABLE>
"{} is [], but subsequent tokens are *data-dep* on the prior token, instead of *side-dep* on the brackets"
<ELLIOTTCABLE>
so, we have,
<ELLIOTTCABLE>
; :: breaks all dependency links at the current level
<ELLIOTTCABLE>
[...] :: introduces a new level; further, each 'root'-level (the first token, or the first token after a semicolon) combination is side-dependent on the token immediately before the brackets; and finally, the token after the brackets is side-dependent on the final token of each component within the brackets
<ELLIOTTCABLE>
{...} :: introduces a new level; further, each 'root'-level (the first token, or the first token after a semicolon) combination is side-dependent on the token immediately before the brackets; and finally, the token after the brackets is data-dependent on that same token immediately before the brackets
<ELLIOTTCABLE>
so,
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
that doesn't answer my A, B, C question, though. I worded it differently than I meant to, but it also exposes an as-yet-un-syntaxified situation.
<ELLIOTTCABLE>
but I'll get to that in a sec.
<ELLIOTTCABLE>
so,
<ELLIOTTCABLE>
A) `(foo bar) {baz; widget} x` means Paws-equivalent `(foo bar) x`, although we haven't specified scope yet; but with `baz` *and* `widget` spinning off as soon as <foo-bar-result> is combined with the scope (or whatever.)
<ELLIOTTCABLE>
with x in no way relating to `baz` or `widget` data-wise
<ELLIOTTCABLE>
so, {...} "carries through" data-dependency; it's like Ruby's #tap, sort of.
<ELLIOTTCABLE>
B) `(foo bar) [baz; widget] x` has four data-separate "statements": `(foo bar)`, `baz`, `widget`, `x`, and expresses the expected ordering constraints on them.
<ELLIOTTCABLE>
C) `(foo bar) [baz; widget] ; x` also self-explanatory, probably
<ELLIOTTCABLE>
I'd imagine that that specific example is pretty strange and out-of-place. *Usually*, all the data-dependant stuff (basically "lines of code", because continuously building on the result of the previous combination works out to a line-of-code the way it did in Paws, and then you throw away the last result) happens at the bottom level, with higher-level
<ELLIOTTCABLE>
structure *amongst* the lines-of-code being expressed in the new syntax
<ELLIOTTCABLE>
but I can definitely see the use of {...}, I just think it'd show up much rarer.
<ELLIOTTCABLE>
devyn: thoughts?
<devyn>
still thinking
<ELLIOTTCABLE>
so, what *can't* be expressed with this setup,
<devyn>
ok, so `(foo bar) [baz; widget] x` === `(foo bar) [baz; widget]; x`? or no?
<devyn>
oh
<devyn>
wait
<devyn>
yes
<devyn>
I see
<devyn>
they're not the same
<devyn>
the first one still maintains order dependency
<ELLIOTTCABLE>
A) complex graph intra-relationships. everything here is basically a tree, with some special cases where we can relate two branches of a tree and get a psuedo-graph. but, as with my caveats way back above, it still can't do stuff where a part of one branch, but not the whole branch, is dependant on a part of another branch, but not the whole branch.
<ELLIOTTCABLE>
and now, newly, B),
<ELLIOTTCABLE>
my first question above. "x data-dependant on (foo bar) and order-dependat on baz;widget"
<ELLIOTTCABLE>
I see no way to express that particular situation. We can carry data-dependancy through, or order-dependancy, but not both. I think.
<devyn>
ok, just hold on, let me interrupt because I don't think distinguishing between [ and { actually adds anything at all, because you can do everything you can do with [ with { too
<ELLIOTTCABLE>
I think you're right, but before we dig into that, i'm having an inkling of another issue, here.
<devyn>
so my original proposal was that [ just be what { is now
<devyn>
so then we're just left with [
<devyn>
anyway
<devyn>
continue
<ELLIOTTCABLE>
basically, we're conflating the space-operator. And I realllllllllly liked the simplicity of the space-operator in Paws.
<ELLIOTTCABLE>
now, depending on whether there's brackets before or after it, or a semicolon,
<ELLIOTTCABLE>
juxtaposition of two tokens could either express a dependency, or express a combination.
<ELLIOTTCABLE>
so, ... I want to make a new stab, that leaves it explicitly *only* one or the other.
<ELLIOTTCABLE>
two possibilities:
<ELLIOTTCABLE>
data-dependency, use a period or a dash or a slash or something, similar to other languages,
<ELLIOTTCABLE>
and then a space is always side-effect dependency.
<devyn>
the way I see it that isn't such a bad thing; the default is data-and-order-dependency, and then [] just break out of the data-dependency part but leave the order dependency intact
<ELLIOTTCABLE>
or, vice versa, introduce syntax to draw side-depdenency, and keep juxtaposition as an exclusively data-dependency thing ... hrm.
<ELLIOTTCABLE>
ugh. switching tracks again. hold that thought. want to focus on the bracket semantics.
<devyn>
right right lol
<purr>
lol
<ELLIOTTCABLE>
so, ; still breaks any sort of dependancy within its nesting-level,
<ELLIOTTCABLE>
(going to keep using curly-brakets for differentiation until we actually settle on something for sure, for the moment)
<ELLIOTTCABLE>
in your syntax, {...} have *no* data-consequences? even when chained?
<ELLIOTTCABLE>
`(foo bar) {baz; widget} {x} wibble` is data-equivalent to `(foo bar) wibble`
<devyn>
yes, {} never have data-consequences, data goes right through but order is still interrupted
<devyn>
smirk {foo bar (widget dongle); baz mud} {wibble wobble}
<devyn>
;spaz
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
I still feel like you're wrong, but I think I'm just being stubborn. :D
<ELLIOTTCABLE>
okay, so, still bothered by this:
<ELLIOTTCABLE>
in the above, `...mud} {wibble...` doesn't represent a combination being applied, but `...foo bar...` does
<ELLIOTTCABLE>
not a *huge* issue,
<ELLIOTTCABLE>
but want to poke around alternatives.
<devyn>
we already have parens though, which cause something different to happen when we reach the space anyway -- yes, a combination still ends up happening, but something else has to happen first
<ELLIOTTCABLE>
yah, but it still feels okay because *mentally*, you're reducing the content of the parens to a value, and then a the space beside the parens still has the expected meaning
<devyn>
in the same way, a space *always* transfers order-dependency
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
what about using a dot for explicit data-dependency
<ELLIOTTCABLE>
(a dot or parens)
<devyn>
but you want order dependency to be a nestable thing, for sure
<ELLIOTTCABLE>
the actual serial-code operations are all explicit, within that visual graph of dependency.
<ELLIOTTCABLE>
crap this has gained nothing.
<devyn>
yeah that's not helping at all
<ELLIOTTCABLE>
although that does finally convey my worries about {} instead of [] /=
<devyn>
:s
<devyn>
in fact that's more restrictive
<ELLIOTTCABLE>
basically, I crave having data-dependency sections ("lines of code") visually differentiated from order-dependency information
<ELLIOTTCABLE>
yeah I noticed
<devyn>
it doesn't let us pass smirk's data dependency on to spaz, and then {} are order-dependent but spaz isn't and that's all weird
<ELLIOTTCABLE>
was just a reversion to the original brackts with a different syntax. back to having no way to express intermingled data- and order-dependency.
<ELLIOTTCABLE>
spaz *is*, in that example
<ELLIOTTCABLE>
same a with brackets
<ELLIOTTCABLE>
simple left-to-right reading
<devyn>
spaz is??
<ELLIOTTCABLE>
dependant
<devyn>
that's... weird, because now space still means two things
<ELLIOTTCABLE>
no, only means one thing. "stuff after" is order-dependant on "stuff before"
<ELLIOTTCABLE>
with those both being group-able with [].
<ELLIOTTCABLE>
(since {} was basically a typo above)
<ELLIOTTCABLE>
but not suggesting that. definitely lose a lot.
<ELLIOTTCABLE>
so, back to your example:
<ELLIOTTCABLE>
I still want to visually differentiate the *usual use-case* (lines of sequential code, basically, data-dependencies; ordered within a larger ordering-structure) between sequential-stuff and unordered (or expressed-ordered) stuff
<ELLIOTTCABLE>
i.e. bring the advantage of the [] syntax back, while still **allowing for** the occasional "inner-ordering".
<ELLIOTTCABLE>
sleeping soon, by the way
<devyn>
yeah, and I thought about that too; I knew that we'd lose that with an only-{} impl
<ELLIOTTCABLE>
what about this:
<devyn>
my point was more that the difference is purely syntactic and [] is merely a subset of {}
<ELLIOTTCABLE>
yeah agreed, I understand that now
<ELLIOTTCABLE>
what do you think about this:
<ELLIOTTCABLE>
starting with the original [] semantics (all brackets and semicolons in the code basically express ordering; all spaces and parenthesis express data, but without any way to intermingle that with data without losing data-ordering),
<ELLIOTTCABLE>
actually, nope, yeah
<ELLIOTTCABLE>
I really really like the combination together.
<ELLIOTTCABLE>
even if they're mostly synonymous.
<ELLIOTTCABLE>
[] in the general case, with code often looking like that gist I posted,
<devyn>
ok, here's my problem with that though
<ELLIOTTCABLE>
and then {} buried within some of the serial-execution "lines of code"
<ELLIOTTCABLE>
like #tap for order
<devyn>
it still doesn't help you write multiple lines of serial-execution code, unless you're going to use [] (as in, empty [])
<ELLIOTTCABLE>
huh
<ELLIOTTCABLE>
sure it does
<devyn>
show
<ELLIOTTCABLE>
[foo bar baz] [widget wodget snigger] [poop poop poop]
<ELLIOTTCABLE>
there's no concurrency in that snippet.
<ELLIOTTCABLE>
it's equivalent to current-Paws, `foo bar baz; widget wodget snigger; poop poop poop`
<devyn>
{foo bar baz} {widget wodget snigger} {poop poop poop}
<devyn>
is equivalent
<ELLIOTTCABLE>
or `void(foo bar baz)(widget wodget snigger)(poop poop poop)`
<ELLIOTTCABLE>
technically, yes; but I posit that the reader's eyes *believe* that there will be a combination in there, somewhere
<ELLIOTTCABLE>
because usually {}'s show up nicely in the middle of a series of combinations
<ELLIOTTCABLE>
in fact, if we are *completely* copying Paws' semantics (which I don't plan to do), that's actually still an operational expression
<ELLIOTTCABLE>
as {}'s have no implied combination-node value, that's basically an empty expression; so, it'd just "have a value of" `locals`.
<devyn>
okay, here's what I think is better: ditch [], leave only {}-semantics, add an additional statement terminator that only preserves sideeffect-ordering
<devyn>
instead of semicolon
<ELLIOTTCABLE>
but that's not how I intend for this to work. just a thought, there. it's clear that {}{}{} *could* have some data-meaning, whereas [][][] is always completely meaningless in a strictly-ordered program.
<ELLIOTTCABLE>
example
<ELLIOTTCABLE>
gogogo
<ELLIOTTCABLE>
popping a melatonin now, fyi
<devyn>
no, what I'm suggesting is that you wouldn't have to use {}{}{}
<devyn>
if you had an alternate separator
<devyn>
let's say
<devyn>
uhh
<devyn>
period
<devyn>
so
<devyn>
`foo bar baz. widget wodget snigger. poop poop poop`
<devyn>
all serial
<ELLIOTTCABLE>
that seems pretty specific to the case you brought up,
<ELLIOTTCABLE>
what about in general use?
<ELLIOTTCABLE>
try the gist agian
<devyn>
{foo bar (widget dongle); baz mud}. wibble wobble; spaz
<devyn>
oh
<devyn>
yes
<devyn>
there was one more thing supposed to be there
<ELLIOTTCABLE>
also, it was my own mistake, but let's not talk about it as "ending"
<ELLIOTTCABLE>
implies too much about parsing
<ELLIOTTCABLE>
it just represents "dependency-less union of nodes" or "order-only union of nodes"
<ELLIOTTCABLE>
(and space is "data-only union of nodes")
<ELLIOTTCABLE>
I like this!
<ELLIOTTCABLE>
so, in total, we have:
<devyn>
space is not data-only, since order is implicit there too, so space is data-and-order
<ELLIOTTCABLE>
no, data-dependency is a superset of order-dependency
<ELLIOTTCABLE>
yeah, exactly, thought that was implied
<ELLIOTTCABLE>
; :: no-dependency union of nodes on either side
<devyn>
yep
<ELLIOTTCABLE>
& :: order-dependency of right-hand-side Orderspression on left-hand-side Orderspression ( ;P )
<ELLIOTTCABLE>
_ :: (meaning optional whitespace) data-dependency of right-hand-side dataspression on left-hand-side dataspression
<ELLIOTTCABLE>
I'm still vaguely sketched out by the intermixing of data- and order
<ELLIOTTCABLE>
*but* it seems necessary to describe a large subset of useful code
<devyn>
and describe brackets? we're going to go with [] but that pass-through data by default?
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
ugh
<ELLIOTTCABLE>
there's not a simple explanation of them, maybe that's what's bugging me
<devyn>
well because []& is what you wanted from before
<ELLIOTTCABLE>
was goning to say,
<ELLIOTTCABLE>
[...] :: conflation of all children-nodes into a single node, whatever their relationships are
<ELLIOTTCABLE>
or something
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
problem is, that doesn't work with data-dependency ...
<ELLIOTTCABLE>
<raw> _ <raw> would normally mean, result-of-right data-fed to result-of-left
<ELLIOTTCABLE>
but <raw> _ <orderspression> is ... not.
<ELLIOTTCABLE>
it works for ; and &, but not _
<ELLIOTTCABLE>
I mean, intuitively-wise; it works fine in practice
<devyn>
the data is still fed into []
<devyn>
the feature of [] is that it just spits it right out the other end
<devyn>
it passes through
<ELLIOTTCABLE>
mmmm
<devyn>
basically, order branch-and-merge with data passthrough
<devyn>
find a less nerdy way to describe that
<devyn>
haha
<ELLIOTTCABLE>
lolol
<purr>
lolol
<ELLIOTTCABLE>
here's one for you:
<ELLIOTTCABLE>
what are the ordering-semantics of indirection, now?
<ELLIOTTCABLE>
and do we need a new set of syntax for the new possibilities *there*?
<devyn>
sorry, briefly describe what indirection means again here
<ELLIOTTCABLE>
parens
<devyn>
oh
<devyn>
yes
<ELLIOTTCABLE>
foo bar (baz widget) is strictly-ordered in current Paws.
<devyn>
it would be exactly the same as current Paws
<ELLIOTTCABLE>
but part of the original plan was attempting to dispatch, in parallel, `<locals> foo` and `<locals> baz`.
<ELLIOTTCABLE>
so, how can Tires achieve that?
<ELLIOTTCABLE>
I'm gonna go lie down.
<devyn>
well, what do you want to do with `<locals> foo` and `<locals> baz`?
<devyn>
example
<ELLIOTTCABLE>
but more on this soon.
<ELLIOTTCABLE>
glowcoil: wake the fuck up and read all of this :P
<devyn>
okok
<ELLIOTTCABLE>
glowcoil: all "boring" syntactic stuff, because in reality, the program is an unconstrained DAG.
<ELLIOTTCABLE>
glowcoil: but still. *interesting* syntactic stuff, for once. because against all the odds, we may actually be covering *new ground* in the programming world. (at least, as far as I know.) :P
<ELLIOTTCABLE>
*do* with, is the same as now.
<ELLIOTTCABLE>
basically, to duplicate Paws semantics, ignoring the syntax for a moment,
<ELLIOTTCABLE>
you've got a dag of (using dashes to connote single combinations / nodes),
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
<-- for dependency, and +-- for data-dependency
<ELLIOTTCABLE>
crap
<ELLIOTTCABLE>
difficult to denote a dag in text :P
<ELLIOTTCABLE>
well, basically, you'd have to have *both* data-dependency between <foo-bar> and <baz-widget>, **and** order-dependency between <foo-bar> and <locals-baz>
<ELLIOTTCABLE>
and that's unintuitive, in a Tires mindset
<ELLIOTTCABLE>
I'd prefer:
<ELLIOTTCABLE>
(), or an alternative syntax, has no order-dependency, *just* data-dependency between the end of each, with the two data being then combined
<ELLIOTTCABLE>
... and an alternative syntax of some sort for the old semantics of having *both* data-dependency on the results (indirection), *and* order-dependency (continuation of the left-to-right flow)
<ELLIOTTCABLE>
okay. i lays down.
<ELLIOTTCABLE>
more on this soon :D
<devyn>
ELLIOTTCABLE: ok, definitely interesting. good night
<devyn>
I think this will solve a lot of problems
<ELLIOTTCABLE>
rf, inimino, cloudhead, I can imagine that all of you would appreciate most of what we've been talking about tonight. come read the logs.
<ELLIOTTCABLE>
well, it won't solve any of the "problems" with Paws, because it doesn't address any of those things
<ELLIOTTCABLE>
it's simply a different language with subtly different goals.
<ELLIOTTCABLE>
Paws is *specifically* trying to appeal to JavaScript, Ruby, Java, whatever users.
<ELLIOTTCABLE>
executions are trying hard to be as asynchronous as possible, while still being procedural.
<devyn>
sure it does... one problem to me is that Paws is very very hard to parallelize and so by adding more explicit order-dependency it's easier to do
<ELLIOTTCABLE>
this new project is throwing away "let's appear procedural" in exchange for "let's be *as asynchronous as is possibly possible*."
<ELLIOTTCABLE>
eh, idc implementation. not the shit I think about.
oldskirt has joined #elliottcable
<devyn>
no, I mean Paws is *theoretically* hard to parallelize
<ELLIOTTCABLE>
but from the user's point of view, I think Paws is much more approachable than this. not necessarily a good or bad thing. just different projects in my head.
<devyn>
it's just not going to happen, the way it is
<ELLIOTTCABLE>
talk more on that later
<ELLIOTTCABLE>
g'night!
<devyn>
night!
<ELLIOTTCABLE>
(I still think we can solve those problems with minor semantic changes, or none-at-all. stuff like enabling pipelining of multiple operations, changing the ordering semantics slightly, etc; without fundamentally altering the feel of writing in the language.)
<inimino>
ELLIOTTCABLE ⋱ I read some of the backlog...
<inimino>
Up to "I call it Tires"
<alexgordon>
LOL
<purr>
LOL
<inimino>
ELLIOTTCABLE ⋱ It reminds me of something I am working on...
<inimino>
Which is a system for scripting.
<inimino>
In this system you have data dependencies, which are pure, like in a spreadsheet, and also exposed visually like in a spreadsheet.
<inimino>
And form something like a DAG.
<inimino>
And then there's a separate thing which is a sequential list of side effects.
Sgeo_ has quit [Read error: Connection reset by peer]
<inimino>
So if you want to script something you choose both a result and a sequence of side effects, and then the system stores the dependency graph and it will recalculate data accordingly, and also do the side effects in order.
<inimino>
I'm going to go hack on that for a couple hours, anyway, talk later.
Guest76736 has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
yorick has joined #elliottcable
Sorella has joined #elliottcable
Guest76736 has quit [Ping timeout: 272 seconds]
nicksergeant has joined #elliottcable
Guest76736 has joined #elliottcable
nicksergeant has left #elliottcable ["WeeChat 0.4.3"]
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<ELLIOTTCABLE>
so yeah, I have clear worries about the side-effects and usability.
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<ELLIOTTCABLE>
devyn: I'm still not clear on your parallelisation concerns for Paws.
<ELLIOTTCABLE>
for your lock-contention implementation issues, move the ownership information into the data-graph. then, your impl locks on *the object itself*, on which there will be no superfluous contention, as there would be with a global-table approach
<ELLIOTTCABLE>
I really, really *don't* think Paws will be hard to parallelise in the general case
<ELLIOTTCABLE>
as for the multi-operation reactors: I'm pretty convinced that's possible. It'll be a pretty substantially different semantic, but only *to the implementor*. The changes from a user's point of view should be very subtle; the language as a whole won't really change feel if we change those ordering rules to support pipelining.
<joelteon>
interesting design pattern within puppet:
<joelteon>
defaulting you can't disable
<joelteon>
"i request to install puppet 2.7.22"
<joelteon>
output
<joelteon>
"failed, got version 3.6.1 instead"
<joelteon>
what the fuck
<joelteon>
just fail
eligrey has joined #elliottcable
eligrey has quit [Ping timeout: 240 seconds]
eligrey has joined #elliottcable
<ELLIOTTCABLE>
hi, all
<ELLIOTTCABLE>
windows is a stinky little bitch
<ELLIOTTCABLE>
autohotkey is a stinkier little *buggy* bitch
<ELLIOTTCABLE>
ಠ_
<joelteon>
yea i much prefer the quartz key events api
<devyn>
ELLIOTTCABLE: the issue with the lock contention is not on the individual objects; I already have locks on each of those separately... it's more that globally queueing and ordering is a major point of contention and you can't really get around that in Paws' design
<ELLIOTTCABLE>
er, you mis-read me
<ELLIOTTCABLE>
I'm saying, move ownership *into the data-graph*. Then ordering is no longer a global operation, it's a local one.
<ELLIOTTCABLE>
as for the queue, that's "solved" if a series of combinations can be preformed without touching the queue. more on that later.
<ELLIOTTCABLE>
not to mention implementation-y fixes or performance enhancements that reduce the amount of global-queue-awareness that there needs to be; stuff like your copying it to each reactor or something. *shrug*
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE>
still definitely doesn't seem like a problem inherent to the design to me
<ELLIOTTCABLE>
need more convincing :P
<devyn>
ELLIOTTCABLE: ok, I might be missing something, but another thing: you said you were worried about queue-jumping... but already, things can be skipped over in the queue (if for example their mask isn't available at that moment), which is effectively jumping
<devyn>
so effectively the queue's order is just priority; it's not strict
<ELLIOTTCABLE>
the worry isn't about things moving *around* in the queue;
<ELLIOTTCABLE>
it's about the queue's order being deterministic.
<ELLIOTTCABLE>
basically:
<ELLIOTTCABLE>
run the same Paws program on two computers, right now, and things happen in exactly the same order. the queue guarantees that.
<ELLIOTTCABLE>
even if they're not *in the order they are in the queue*, they are still in *an* order, which is *managed* by the queue.
<ELLIOTTCABLE>
so, the next iteration of Paws, has to involve discarding that guarantee-of-ordering
<ELLIOTTCABLE>
which I'm uneasy about for obviou reasons, but which is also completely understandable: Paws is *supposed* to make no guarantees about order, except those guarantees about ownership.
<ELLIOTTCABLE>
"If you don't exercise the ownership tools, your code is going to go haywire. Sorry."
<ELLIOTTCABLE>
so. my worries aren't the "I don't want to do this until I solve them" kind of worries; they're literally, just, me-being-silly worries.
<devyn>
okay, let me ponder this a bit more. at work currently
<ELLIOTTCABLE>
yeah
<ELLIOTTCABLE>
and I'm doing dirty, dirty things to shells.
<devyn>
the bone kind or the UNIX kind
prophile has joined #elliottcable
Sorella has quit [Quit: Ex-Chat]
<ELLIOTTCABLE>
UNIX/
<joelteon>
something something bone eunuchs
<devyn>
ELLIOTTCABLE: toying with the idea in my mind right now that Tires might make ownership unnecessary, which would be a huge win
<devyn>
will explain if it makes sense, later
<devyn>
anyway I think Paws+ownership can be safely made non-deterministic