<ELLIOTTCABLE>
This green, ugly, evil looking health shit.
vil_ has joined #elliottcable
ThatGaySwooshy has joined #elliottcable
NuckingFuts has joined #elliottcable
vil has quit [*.net *.split]
SwooshyCueb has quit [*.net *.split]
nuck has quit [*.net *.split]
ThatGaySwooshy is now known as SwooshyCueb
<ELLIOTTCABLE>
CROSS YOUR FINGERS FOR ME, MINIONS.
<whitequark>
ELLIOTTCABLE: so.
<ELLIOTTCABLE>
wow I never sent that.
<whitequark>
lol
<purr>
lol
<ELLIOTTCABLE>
Well, it was unreasonably delicious.
<ELLIOTTCABLE>
ThatGaySwooshy: o7
<whitequark>
ELLIOTTCABLE: a few more things I don't currently understand
<whitequark>
what is the relationship between cPaws and uhh "AST" nodes?
<whitequark>
how are they parsed?
<ELLIOTTCABLE>
omg lagging
<ELLIOTTCABLE>
okay, hold on
<ELLIOTTCABLE>
do you mean Script, by "AST in quotes"?
<whitequark>
basically I want to have a working Paws data-structures and a parser in OCaml in a few hrs
<whitequark>
hm
<whitequark>
yes
<ELLIOTTCABLE>
or are we talking about an actual AST, between cPaws text and a Script?
<whitequark>
no, Script.
<ELLIOTTCABLE>
kk
<ELLIOTTCABLE>
relationship, I tried, and apparently failed, to convey at the very bottom of the document
<ELLIOTTCABLE>
here's one way of saying it:
<whitequark>
ahh, I think I'm starting to get it.
<ELLIOTTCABLE>
a cPaws AST (or the textual serialization thereof), is a single conflated format to store both Scripts, *and* further Scripts nested within them (by way of Executions.)
<ELLIOTTCABLE>
here's the thing:
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
words.
<ELLIOTTCABLE>
okay, again, …
<whitequark>
an Expression is a list of either Symbols, Expressions, or Executions.
<whitequark>
Execution has a root Expression.
<ELLIOTTCABLE>
yep
<ELLIOTTCABLE>
oh, thought that was all obvious
<whitequark>
several sequental words result in an Expression.
<whitequark>
() gives you a sub-Expression.
<ELLIOTTCABLE>
so, if we *ignore* the Execution you just mentioned,
<whitequark>
foo "foo" “foo” give you a Symbol.
<ELLIOTTCABLE>
then we can kind of pretend that the root-expressions can be directly embedded into a parent expression.
<whitequark>
that's all I think?
<ELLIOTTCABLE>
which is what cPaws does.
<ELLIOTTCABLE>
yeah, that's all of it
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
execution-literals.
<whitequark>
see above
<whitequark>
<+whitequark> an Expression is a list of either Symbols, Expressions, or Executions.
<whitequark>
<+whitequark> Execution has a root Expression.
<ELLIOTTCABLE>
yes, you didn't say {} gives you a sub-execution :P
<whitequark>
ah
<whitequark>
yes
<ELLIOTTCABLE>
{} will give you A) a Script, parsed from the stuff between the brackets,
<ELLIOTTCABLE>
and then B), and this is very very important,
<whitequark>
a Script? hmm
<ELLIOTTCABLE>
a pristine Execution object, pointing to the start of that new Script.
<ELLIOTTCABLE>
hence, “execution literal.”
<whitequark>
wait, what's even the point of a Script ?
<ELLIOTTCABLE>
errr
<ELLIOTTCABLE>
wat
<whitequark>
like, it is just a link to Expression.
alexgordon has joined #elliottcable
<whitequark>
useless indirection
<ELLIOTTCABLE>
look! an alexgordon! what good timing!
<ELLIOTTCABLE>
whitequark: Mmm, it is, with one exception,
<ELLIOTTCABLE>
er, one, er, caveat
<alexgordon>
ELLIOTTCABLE: not staying
<ELLIOTTCABLE>
how to words this,
<ELLIOTTCABLE>
alexgordon: poop!
<ELLIOTTCABLE>
I guess, here you go:
<alexgordon>
ELLIOTTCABLE: faeces
<ELLIOTTCABLE>
a Script is a “block of code.” Coming from something like a lisp world, that's an unimportant distinction. In fact, one that's avoiding. They like their homoiconicity.
<ELLIOTTCABLE>
But coming from a language with statements, even though Paws has none, “a line of code” and “a block of code” are very different things.
<ELLIOTTCABLE>
and Scripts conveys that concept of block-ness, even in the absence of line-ness.
<whitequark>
do they have any semantic effect?
<purr>
<ec> something something something those things you slap on your arm and they snap shut. (Snap-stick?)
<ELLIOTTCABLE>
Yes. The fact that once created (which *can* be done, see: IPP, or some weird-ass implementations of Paws that give constant homoiconic mutation access to Scripts), a Script can be instantiated into an Execution.
<ELLIOTTCABLE>
the Script is the starting-point.
<whitequark>
okay, you didn't get it
<ELLIOTTCABLE>
if given a big bag of expressions, the ones with Scripts wrapping them, are the places that you can safely create an Execution and start executing.
<whitequark>
I go and rip out everything related to the Script, instead directly replacing it with its root expression.
<ELLIOTTCABLE>
The spec will still result in a working paws machine.
<whitequark>
I don't see a single place where this would have a semantic difference.
<ELLIOTTCABLE>
a reader just won't understand as well. (=
<ELLIOTTCABLE>
sorry I didn't say that earlier.
<ELLIOTTCABLE>
almost did, but decided to go blabbering on instead. >,>
<whitequark>
since Paws is already very confusing to anyone coming from any other language
<whitequark>
I suggest we get rid of Script.
<whitequark>
I mean, really, it's entirely pointless and/or just making it more confusing
<whitequark>
because Scripts aren't really blocks of code
<ELLIOTTCABLE>
Reasonable. Just like the label-rules, will probably go poof in the next version, then.
<ELLIOTTCABLE>
Want to think about it some more.
<ELLIOTTCABLE>
hm? why aren't they?
<whitequark>
well... because they aren't any different from expressions
<whitequark>
semantically.
<ELLIOTTCABLE>
no, that's exactly what I'm saying.
<whitequark>
I mean, in C++ you have blocks distinct from statements because block creates a scope.
<whitequark>
it's not just "let's group some statements"
<ELLIOTTCABLE>
Maybe a better way to do this, then, would be to make Script a ‘sub-class’ of Expression, but make it the only sub-class that can belong to an Execution as ‘root’.
<whitequark>
it's "let's create and destroy shit at boundaries"
<ELLIOTTCABLE>
yissyissyissyiss
<whitequark>
well, that's still entirely pointless for a low-level Nucleus.
<ELLIOTTCABLE>
okay, the *semantics* of entering a Script, as opposed to entering an Expression,
<ELLIOTTCABLE>
are that you're (would have to be) creating a new Execution, to do so. (And vice versa: you couldn't enter an Expression, without an existing Execution that's poised to do so.)
<ELLIOTTCABLE>
and thus, creating a new locals object, just as you just mentioned with C++, to belong to that new Execution …
<ELLIOTTCABLE>
and so on and so forth
<whitequark>
well, you just said above that every Script will be wrapped in a new Execution anyway
<whitequark>
just as the toplevel expression too.
<ELLIOTTCABLE>
ahhah!
<ELLIOTTCABLE>
not quite!
<ELLIOTTCABLE>
there's a single *definite* exception to that,
<ELLIOTTCABLE>
and many possible ones.
<ELLIOTTCABLE>
No reason an implementation can't make Scripts themselves executable (not from within the language, so irrelevant to the spec, yes, but you get my point), i.e. saying “to run this Script, we create a new Execution, and queue it.” …
<ELLIOTTCABLE>
… and, of course, that's exactly what must happen at the start of a Paws program, if it's coming from cPaws. Coming out of a cPaws file, you have a Script, not an Execution, with some embedded objects in it. Every time you go to run the program, you're creating a new Execution from that Script, for the purposes of running the script.
<ELLIOTTCABLE>
ah, fuck it, I'm spewing bullshit.
<whitequark>
my plans were to modify Execution to give them that role, but more on that later.
<ELLIOTTCABLE>
like I said I'll probably remove it.
<ELLIOTTCABLE>
next!
<whitequark>
ok
<whitequark>
so
<whitequark>
now you will walk me through Paws evaluation of cPaws snippets I'll feed you.
<whitequark>
let's go:
<whitequark>
> foo
<ELLIOTTCABLE>
tell me what you think from what you've read of the spec, first. let me correct you, instead.
<ELLIOTTCABLE>
that gives me a chance to see any *more* misconceptions that spec has left you with, instead of letting them get glossed over because you were assuming you were thinking what I ended up saying *all along*, when you wouldn't have been.
<ELLIOTTCABLE>
(woahconvolutedsentenceholycrap)
* whitequark
sighs
<whitequark>
that requires me to apply my brain more
<whitequark>
but ok
<whitequark>
actually, you know what, not ok
<whitequark>
explaining why:
<SwooshyCueb>
Ugh, this fucking dog
<ELLIOTTCABLE>
SwooshyCueb: wat.
<purr>
beep.
<SwooshyCueb>
My flatmate's dog is screaming at nothing again
<SwooshyCueb>
She does this ALL. THE. TIME.
<whitequark>
what I currently want from you, and your spec, is to basically get rid of every single mention of Reactor, stacks, mutating Executions, pc, advance() and interface Combination from my mental model.
<whitequark>
I believe that everything I listed above is unnecessary to the spec and only complicates understanding.
<whitequark>
to build a better mental model, I need to know what you *intend* all that crap to actually *result in*.
<whitequark>
this will also address your spec concerns, because afterwards, I will be able to tell you how exactly to rewrite most of the spec :p
<ELLIOTTCABLE>
LOL
<purr>
LOL
<ELLIOTTCABLE>
Valid 'nuff
<ELLIOTTCABLE>
go.
<whitequark>
> foo
<ELLIOTTCABLE>
> being some sort of prompt? stick to the format used in the latter half of page 5, the post-parsing discussion form
<ELLIOTTCABLE>
how granular do you want me to get here? are we assuming that I need to describe the boot-up of the reactor and all that crap?
<ELLIOTTCABLE>
• the system will have to have an Execution object for that code. So, that's created.
<whitequark>
hmm. for this first thing, maximally granular, including Reactor stuff.
<whitequark>
then I'll gradually ask you to decrease/
<ELLIOTTCABLE>
the execution, however it's implemented, will indicate that the L'foo' node is the “next” one requiring combination.
<ELLIOTTCABLE>
(before the current representation used in that spec, we used to call Executions pointers; because they're basically first-class program-counters with context. Thus, we'll say it's “pointing at the L'foo' node.”)
<ELLIOTTCABLE>
• that Execution will be indicated as ‘needing to be evaluated.’
<ELLIOTTCABLE>
I'd say “it will be queued,” but apparently you want to build without a queue. I get that. Can't think of better terms than that.
* whitequark
nods
<whitequark>
it "will be scheduled".
<whitequark>
basically, your Executions seem to be exactly same as cooperatively scheduled tasks.
<whitequark>
in CS terms.
<whitequark>
so, "scheduled"
<ELLIOTTCABLE>
• if the Paws machine is capable of evaluating combinations *in general* right now, then, there being nothing else indicating evaluation, it will begin to evaluate that Execution
<ELLIOTTCABLE>
there's some ascertaining-evaluability stuff that doesn't apply right now, because there's nothing else that needs to be done, so ordering concerns don't apply.
<ELLIOTTCABLE>
trying to figure out how to describe evaluation without a stack, and without whatever you called in-place-replacement. :P gimmie a sec
<whitequark>
you can absolutely describe it using a stack or using term reduction.
<whitequark>
I'm not asking you to rewrite the spec in the way I think it should be done, based on my by definition incomplete understanding.
<whitequark>
That may well be simply impossible.
<ELLIOTTCABLE>
ok.
<ELLIOTTCABLE>
well, I don't want to just say what the spec already says; I'm *also* trying to work through my mental model in a new way. intentionally.
<ELLIOTTCABLE>
stretches my mind and improves my own understanding of Paws. That's always to the benefit.
<whitequark>
sure
<whitequark>
try term reduction this time, maybe
<ELLIOTTCABLE>
• normally, at this point, there would be a “resumption value” relevant to the process of evaluating the upcoming combination. There is none, because we're at the unique position of evaluating the first combination in a pristine Execution, *and* the additionally unique position of that first combination not having been triggered by a *call*, but rather
<ELLIOTTCABLE>
by the system.
<ELLIOTTCABLE>
(at some point in the future, this empty semantic may be used: it's the perfect place, for example, if I wanted to tie myself more thoroughly into UNIX, to get the argv UNIX stuff into the program.)
<ELLIOTTCABLE>
• the node the Execution is pointing at, is (and this would be different if it were a expression, so I guess we'll get to that later), is examined to produce a *value*, an object of some sort.
<ELLIOTTCABLE>
• Since A) this is a value-node, (i.e. that step succeeded because it's not an *expression), that becomes the message …
<ELLIOTTCABLE>
• … and further, since this is the first combination of a new expression (in this case the root expression), there is no pre-existing subject, the subject becomes the executions' locals …
<ELLIOTTCABLE>
• … and we begin the process of evaluating the combination we've arrived at. (subject: <locals>, message: <L'foo'>)
<ELLIOTTCABLE>
shit, side-note: during this process, the Execution will also be moved-forward, before we begin to evaluate the combo.
<ELLIOTTCABLE>
in the spec's description, the process of *acquiring* the next combination, also inherently moves-forward the Execution for you … but, that's really a separate process, and separating the two has been a goal of mine for some time.
<ELLIOTTCABLE>
do you understand the moving-forward? it's pretty simple. Basically, point at the next node, unless A) the next node is an expression, in which case you dive as deep into nested sub-expressions as necessary until you get to a value-node, or B) there *is* no next-node, because you're at he end of your current expression …
<ELLIOTTCABLE>
(need I go on on this subject?)
<whitequark>
yeah, I do. it's the usual recursive evaluation.
<ELLIOTTCABLE>
okies.
<ELLIOTTCABLE>
basically, the only ‘special’ caveats to that process are this:
<ELLIOTTCABLE>
A), an *empty expression*, which would otherwise be semantically meaningless, has been over-ridden to mean “the currently-being-evaluated Expression object.”
<ELLIOTTCABLE>
a little bit like `arguments.callee` in JavaScript, except it's more like `arguments.current_continuation`. Hybrid of call/cc and `arguments.callee`.
<ELLIOTTCABLE>
B), actually, no, B) is an implementation detail. ignore me.
<ELLIOTTCABLE>
cool. I like this.
<ELLIOTTCABLE>
OKAY. We have a combination, and the execution has been moved-forward to reflect that, so that the *next* combo generated will be, well, next.
<ELLIOTTCABLE>
• a receiver-Execution of some sort, is acquired from the subject of the combo.
<ELLIOTTCABLE>
sorry, carrying on two conversations.
<whitequark>
also how do you make an empty expression? () ?
<ELLIOTTCABLE>
that, any amount of whitespace, I suppose.
<ELLIOTTCABLE>
the BNF should express that.
<ELLIOTTCABLE>
generally ().
<whitequark>
yeah, right
<whitequark>
go on
<whitequark>
it's basically Thread.current, not arguments.whatever
<ELLIOTTCABLE>
fun fact: that means our “procedure calls” (calls into coconsuming APIs that also return a value) look oddly like other languages' function calls:
<ELLIOTTCABLE>
foo()(a)(b)(c)
<whitequark>
wait on that
<whitequark>
finish the > foo first
<ELLIOTTCABLE>
well, yes, but in our case, Thread is *also* the equivalent of arguments.callee
<ELLIOTTCABLE>
because it contains the locals / variables, and any other code-block-relevant state.
<ELLIOTTCABLE>
kkkkkkkk
<ELLIOTTCABLE>
receiver-execution comes from,
<ELLIOTTCABLE>
• if the object in question has previously had a receiver defined *for it*,
<ELLIOTTCABLE>
• then it's either that value previously defined (if it is stageable), or the results of this same process/algorithm, applied to that value (if it is not stageable).
<ELLIOTTCABLE>
stageable, meaning, at this point, “is an Execution.”
<ELLIOTTCABLE>
• if the object in question *has* no receiver, then we'll use a built-in algorithm, that will be different depending on whether the value is an Execution or not.
<ELLIOTTCABLE>
(reminder to keep context: what we're currently doing is basically deciding what the juxtaposition of these two objects *does*.)
<ELLIOTTCABLE>
sorry, combination*
<ELLIOTTCABLE>
old terminology :P
<ELLIOTTCABLE>
• if the subject-value were an execution, that would be flagging the execution for evaluation, as described above …
<ELLIOTTCABLE>
• … but it is not, so we're going to be preforming a lookup against it.
<ELLIOTTCABLE>
now. This is a wobbly-point.
<ELLIOTTCABLE>
a very, very important one in the long-run.
<ELLIOTTCABLE>
(mentioned in the spec, you made brief scoff at it in the Wave)
<ELLIOTTCABLE>
Basically, it's not defined as of yet, whether the next step is to *put this algorithm in the queue* (to use the spec's terms), or to just *do* it, jumping the queue entirely for lookups, basically.
<ELLIOTTCABLE>
so, in your head, insert a maybe-step: wrap all this logic up into an Execution, put it last in the queue, and then We're Done. for now.
<ELLIOTTCABLE>
but, we're going to assume that that's not the case (or, alternatively, that it was the case, but we're now fast-forwared to the point where that receiver-Execution has become the next evaluable thing), and proceed with the lookup.
<ELLIOTTCABLE>
• this handler has three pieces of data made available to it now: the Execution during which the combination was constructed (the ‘caller’ of the receiver),
<ELLIOTTCABLE>
• this handler has three pieces of data made available to it now: the Execution during which the combination was constructed (the ‘caller’ of the receiver), the subject, and the message.
<ELLIOTTCABLE>
for us, those will now be: the Execution created at the very start of running the program; the <locals> object of that Execution; and a newly-created Label (saying 'foo', but that's irrelevant.)
<ELLIOTTCABLE>
• starting with the ordered-last element of that subject Object, each element in turn will be checked to see if it looks like a pair, with a matching Label as its ‘key’:
<ELLIOTTCABLE>
• each element will have its *ordered-second* element ‘compared’ with the message-value we have.
<ELLIOTTCABLE>
• that comparison is different based on whether the message is a Label, or anything else (just like the default-receiver is different. presumably, some form of inheritance, with overrides in these situations for Execution or Label, respectively). If it is anything else, they are compared by object-identity.
<ELLIOTTCABLE>
a note on obj-identity: presumably, a fast implementation will somehow map that directly to memory-location, so it's a pointer comparison … but that won't **always** be possible, 'cuz federation. You can receive objects from other places, and then have to compare them by UUID.
<ELLIOTTCABLE>
• but this is a Label, so instead, we will compare by content-equivalency. (As discussed in the wave, that will probably be some normalized-form Unicode codepoint-comparison. Will have to leave it undefined for now.)
<whitequark>
(usually this is done by performing NFC right before creating a Symbol (Label?..) and then performing bytewise comparison.)
<ELLIOTTCABLE>
(kk)
<ELLIOTTCABLE>
• so. Since the locals are empty but for one pair, which *isn't* a match. The receiver does nothing more.
<whitequark>
what's in the locals?
<ELLIOTTCABLE>
(of note, the ‘caller’ is not added to the queue again, and he's not already in the queue, either, which means he never generates another combination.)
<ELLIOTTCABLE>
• now, the queue is completely empty, and given that there's no wait() or similarly-temporarly-asynchronous operations in our hypothetical implementation, the program can terminate.
<ELLIOTTCABLE>
I realized like, three sentences into this conversation that I completely left locals out of the spec, which is trivial to add. I'll add a note for now, hold on.
<ELLIOTTCABLE>
okay.
<ELLIOTTCABLE>
an execution, *libside*, looks like this (that is, the object-data, ignoring the opaque code-data behind it):
<ELLIOTTCABLE>
*in addition* to that, the execution itself must know about its locals.
<ELLIOTTCABLE>
(translation: execution type has a `locals` member, referencing it.)
eligrey has quit [Ping timeout: 265 seconds]
<ELLIOTTCABLE>
actually, I think we decided to remove the 'locals' reference from the Execution-object's lib side data. Ignore me completely.
<ELLIOTTCABLE>
aouwtailuatioarauirwur starting over, Execution has a member, `locals`, in which is stored an Object;
<whitequark>
yeah, that sounds very good
<ELLIOTTCABLE>
that Object starts out empty save a reference to itself, in one of those pseudo-pairs.
<ELLIOTTCABLE>
so.
<whitequark>
it means you can actually do implementation-hiding. that's how CL builds OOP on top of FP.
<ELLIOTTCABLE>
hm?
<ELLIOTTCABLE>
the locals will still be accessible; it's just one of the things we decided to make a routine for instead of trying to *actually store it* in the data-graph.
<whitequark>
well basically, there's a certain way to build (Smalltalk-style) OOP on top of (impure) FP;
<ELLIOTTCABLE>
i.e. set_locals(xec, something) instead of xec.locals = something
<whitequark>
function newpoint(x, y) { return function(msg) { var args = Array.prototype.slice(arguments, 1); switch(msg) { case "x"; return x; case "setx"; x = args[0]; ... } }
<ELLIOTTCABLE>
yah
<ELLIOTTCABLE>
familiar, that's how inimino wanted me to do paws
<whitequark>
I want it too :p
<ELLIOTTCABLE>
lol
<purr>
lol
<ELLIOTTCABLE>
I like my object system lots. go away. >,>
<ELLIOTTCABLE>
OKAY
<ELLIOTTCABLE>
SO
<ELLIOTTCABLE>
NEXT QUESTION?
<ELLIOTTCABLE>
and tell me how much I can skip, or which parts you're curious about, so I don't have to say all that over again :P
<whitequark>
hmmm
<whitequark>
what if <locals> contained (,'foo', err something) ?
<whitequark>
you don't have to retell anything you've told.
<whitequark>
just say which parts have changed.
<ELLIOTTCABLE>
foo err something?
<ELLIOTTCABLE>
there's no error type …?
<whitequark>
no, "err something" is just some datatype
<ELLIOTTCABLE>
oh lol k
<whitequark>
I mean, the spec doesn't mention any datatypes except symbol and object really
<whitequark>
say, integer
<whitequark>
whatever that is
<whitequark>
42
<ELLIOTTCABLE>
no integer types. I'll go with the L'42', base-ten / hindu-arabic representation, because that's what indexing uses.
<ELLIOTTCABLE>
anyway. irrelevant.
<ELLIOTTCABLE>
okay:
<ELLIOTTCABLE>
following.
<ELLIOTTCABLE>
• but this is a Label, so instead, we will compare by content-equivalency. (As discussed in the wave, that will probably be some normalized-form Unicode codepoint-comparison. Will have to leave it undefined for now.)
<ELLIOTTCABLE>
we then find, ordered-second matches L'foo',
eligrey has joined #elliottcable
<ELLIOTTCABLE>
• then we queue the ‘caller’ we still have handy, with whatever value is ordered as *third* in the current ‘pair-ish’ thing we're looking at, as the resumption-value.
<ELLIOTTCABLE>
(so, the value in the key-value pair)
<ELLIOTTCABLE>
and we're done with that receiver.
<ELLIOTTCABLE>
• next flagged-for-evaluation, is still only a single thing, so still no concerns about ordering,
<ELLIOTTCABLE>
• we have a resumption-value available to the algorithm, now, so it would work slightly differently …
<ELLIOTTCABLE>
• but there's nothing more in the expression we're in,
<ELLIOTTCABLE>
• and there's no parent expression to move outwards to,
<ELLIOTTCABLE>
so we terminate without ever using that resumption value.
<whitequark>
ok. gotcha. now... I want to print the value of foo, what do I write?
<whitequark>
assuming there's a primitive "print" defined somehow.
<ELLIOTTCABLE>
given the spec? nothing.
<ELLIOTTCABLE>
oh, there ya go
<ELLIOTTCABLE>
okay, so, I'm not going to break it down (at least, not yet, or until you ask me to), but I want to give some notes / rationale, here:
<ELLIOTTCABLE>
> print foo
<ELLIOTTCABLE>
observations:
<ELLIOTTCABLE>
- `foo` is a label literal. no need for quotes, but it means exactly the same thing if you *did* put them. (but you know this.)
<ELLIOTTCABLE>
- as mentioned earlier, the *common* parameterization pattern looks a little like this: `foo()(a)(b)(c)`, which doesn't look much like this. Why?
<ELLIOTTCABLE>
two reasons:
<ELLIOTTCABLE>
1. first off, parenthesis with something in it like that, *boils down to* indirection.
<ELLIOTTCABLE>
basically, the difference between `foo () (a)` and `foo () a` is the difference between, if this were JavaScript, `foo( a )` and `foo( 'a' )`
<whitequark>
is there even any difference between
<whitequark>
> print foo
<whitequark>
> print (foo)
<ELLIOTTCABLE>
yes.
<whitequark>
ah, I'm starting to see
<ELLIOTTCABLE>
the latter would print NOTHING, because there's nothing associated with the key 'foo' on the locals.
<ELLIOTTCABLE>
yepyepyep
<ELLIOTTCABLE>
actually, there was a long discussion about exchanging () for [[
<ELLIOTTCABLE>
and there's a good chance I'll do so.
<whitequark>
it's really very similar to Lisp
<ELLIOTTCABLE>
decided not to do it before we talk about stuff.
<ELLIOTTCABLE>
but, it's misleading to people.
<ELLIOTTCABLE>
ANYWAY: one reason of two.
<ELLIOTTCABLE>
second:
<ELLIOTTCABLE>
okay, so we've described why it's not `print (foo)` instead of `print foo`.
<ELLIOTTCABLE>
but why isn't it `print () foo`?
<ELLIOTTCABLE>
this isn't a spec thing, it's a convention thing: but, by convention, Paws routines only return *at all*, if they *need to*. That is, if they have a value to be returning.
<ELLIOTTCABLE>
no `return undefined` or `return false`, in these parts, boy-o.
<ELLIOTTCABLE>
and since print never has a meaningful result to produce back to the caller, then it doesn't *need a handle to the caller* in the first place.
<whitequark>
"not returning a value" and "not returning at all" are very different things.
<glowcoil>
ELLIOTTCABLE: yeah seriously, completion versus infinite looping
<ELLIOTTCABLE>
yes.
<ELLIOTTCABLE>
I'm very aware.
<ELLIOTTCABLE>
and what glowcoil said is wrong.
<ELLIOTTCABLE>
There's actually "not returning a value" (traditional), "not returning at all" (paws), and "not completing at all" (also Paws, different meaning.)
<ELLIOTTCABLE>
which is yet another use of ownership: *Ownership* is how a caller can, if they have reason to need to, differentiate between eventual-completion and non-completion of something they're interested in.
<ELLIOTTCABLE>
the exact pattern boils down to something like this:
<ELLIOTTCABLE>
- create mutex object of some sort.
<ELLIOTTCABLE>
- take (uncontested, because we just created it) ownership of that.
<ELLIOTTCABLE>
- call something
<ELLIOTTCABLE>
- give ownership to that someone
<ELLIOTTCABLE>
- release own ownership
<ELLIOTTCABLE>
- immediately ask for ownership *again*. lock against it again, iow.
<ELLIOTTCABLE>
boom: we'll only ever resume execution *if the callee completes*. If it never completes, it will never give up the ownership of the object it wasn't aware it owned (durr), and our resumption will be frozen forever.
<whitequark>
that's horrible because of a multitude of things, but more on that much later
<ELLIOTTCABLE>
lolololol
<purr>
lolololol
<ELLIOTTCABLE>
multitude. okay. looking forward to it
<ELLIOTTCABLE>
so, yeah, that answers your questions about `print foo`?
<ELLIOTTCABLE>
next up?
<whitequark>
yeah. print foo, then bar.
<ELLIOTTCABLE>
wat
eligrey has quit [Ping timeout: 265 seconds]
<ELLIOTTCABLE>
oh, me, write code that does that
<whitequark>
yeah
<whitequark>
no prompt :p
<ELLIOTTCABLE>
void
<ELLIOTTCABLE>
( { print foo } derp )
<ELLIOTTCABLE>
( { print bar } derp )
<ELLIOTTCABLE>
er, that's three lines of one program, sorry
<whitequark>
derp ?
<ELLIOTTCABLE>
think about it. I'll explain if you can't figure it out, but I expect you can, easily.
<whitequark>
how do you ensure this doesn't print bar, then foo ?
<ELLIOTTCABLE>
(heads-up, girl on her way over here, so I'm gonna disappear soon. ugh.)
<whitequark>
I expect that "void" is a null combinator, essentially. void x returns x.
<ELLIOTTCABLE>
presumably, yes
<ELLIOTTCABLE>
create a value, lock it, share it with the first, release it, lock against it, then call the second.
<ELLIOTTCABLE>
or. far more realistically, because this is Paws,
<ELLIOTTCABLE>
write a generic procedure to do so, and then use it on `print foo`.
<whitequark>
"derp" is something that would schedule the execution it's got and then... return nothing?
<ELLIOTTCABLE>
(a tool for calling non-returning procedures, that you don't care about the result of, without stopping yourself, is one of the very first, most-basic, building-blocks of Paws code.)
<ELLIOTTCABLE>
derp is *literally anything*.
<ELLIOTTCABLE>
the first juxtaposition against a brand-new, pristine Execution, is semantically meaningless. Nothing *happens to* that value, because there's no ‘hole’ in the Script into which it can be placed, so to speak. (to use glowcoil's terms.)
<whitequark>
mmm
<ELLIOTTCABLE>
any routine you call, like print, or perhaps one you built yourself, is ‘primed’: it's had a meaningless value combined against it, to move that pristine execution forward once. That way, for the *second* combination, there's some where for that value to go.
<ELLIOTTCABLE>
sp.
<ELLIOTTCABLE>
so*.
<ELLIOTTCABLE>
let's talk about `print foo` in detail.
<ELLIOTTCABLE>
the forking point from the earlier explanation would be,
<ELLIOTTCABLE>
• if the object in question *has* no receiver, then we'll use a built-in algorithm, that will be different depending on whether the value is an Execution or not.
<ELLIOTTCABLE>
in this case,
<ELLIOTTCABLE>
• it is an Execution, so the built-in algorithm will proceed as follows:
<ELLIOTTCABLE>
• we *clone* the Execution acting as the subject,
<ELLIOTTCABLE>
(cover that in a sec)
<ELLIOTTCABLE>
• then we flag that new-clone, with the message-value as the resumption-value.
<ELLIOTTCABLE>
er
<ELLIOTTCABLE>
flag-for-evaluation*
<ELLIOTTCABLE>
dicksbuttsassholes
<ELLIOTTCABLE>
sorry, getting mildly inebriated. very very high-ABV beer, plus spec-work, do not mix.
<ELLIOTTCABLE>
so, cloning, there's a question in the air here.
<ELLIOTTCABLE>
need to put both of these on Issues for posterity, ick
<ELLIOTTCABLE>
as the issues says, it's currently undefined what happens to the `locals` member as a result of the cloning process, but that's irrelevant to the current discussion, so I'll gloss over it and move on.
<ELLIOTTCABLE>
• we copy the program-counter, and any other information the `Execution` needs to process its combination, to a *new*, unique Execution object.
<ELLIOTTCABLE>
(the exact semantics being: if the original is processed-for-combination with a given resumption-value, and then the clone is later processed-for-combination with the *same* resumption-value … *or* vice versa … the two combinations will have the same subject and message. barring any intervening modification of the receiver, or anything else that might
<ELLIOTTCABLE>
externally effect that.)
<ELLIOTTCABLE>
so, basically, duplicate the pc and stack. (sorry, I tried to avoid using those terms, but … :P)
<ELLIOTTCABLE>
okay. all that said, basically means,
<ELLIOTTCABLE>
“We have an Execution of a routine called #print, somewhere. We *clone* that pristine Execution, and then we complete the clone, by flagging it for evaluation. It takes a resumption value, does something opaque with it, and then is exhausted.”
<ELLIOTTCABLE>
“The original #print that everybody else has access to is unaffected by this, as we left the original alone, and only queued the clone we created for our own use.”
<ELLIOTTCABLE>
that's generally good-practice, unless you have a reason to be doing otherwise, in Paws. Hence why the default receiver for Execution does so by default.
<whitequark>
brb shower, then back with ideas
<ELLIOTTCABLE>
kk
<ELLIOTTCABLE>
hey, girl'll be here soon, so I'm off anyway.
<ELLIOTTCABLE>
anyway. whitequark, love you, but I'm off. Good night! Don't stay up too late! <3
eligrey has joined #elliottcable
<purr>
<purr> Factoid ‘sephr’: Popularity 0.
<ELLIOTTCABLE>
SwooshyCueb: you awake now? for a while? I might get on tonight.
<SwooshyCueb>
I'm up, yeah. Compiling wine again because I fucked something up, then I should be good to play for a bit~
<SwooshyCueb>
Trying to remember what google account is associated with this YouTube channel
prophile has quit [Quit: The Game]
<ELLIOTTCABLE>
SwooshyCueb: cool.
<ELLIOTTCABLE>
what world?
<ELLIOTTCABLE>
SwooshyCueb: -^
<SwooshyCueb>
Tarnished Coast!
<SwooshyCueb>
I need to make this thing beep at me when someone mentions me. It used to. Not quite sure why it doesn't any more.
<ELLIOTTCABLE>
errrr
<ELLIOTTCABLE>
SwooshyCueb: that's full. lol.
<purr>
lol
<ELLIOTTCABLE>
>:
<SwooshyCueb>
You can still guest
<SwooshyCueb>
I'll be on shortly
<ELLIOTTCABLE>
guest? idk how this shit works.
<SwooshyCueb>
Hang on
<SwooshyCueb>
Just click on the server, then hit guest
<SwooshyCueb>
What's your username?
<ELLIOTTCABLE>
uhhhhhh
<ELLIOTTCABLE>
.2537
<ELLIOTTCABLE>
ELLIOTTCABLE.2537
<SwooshyCueb>
Added!
<SwooshyCueb>
I'll be in mumble shortly
<ELLIOTTCABLE>
don't have headphones nearby, and there's a girl over, asleep
<ELLIOTTCABLE>
text for tonight?
<SwooshyCueb>
Sure, join the party so I don't have to keep tabbing out :p
<SwooshyCueb>
AH YOU ARE IN THE PARTY, GOOD
<SwooshyCueb>
Just a heads up, it takes me for ever to load when changing areas
jesusabdullah has quit [Read error: Operation timed out]
eligrey has quit [Quit: Leaving]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Ping timeout: 245 seconds]
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
jesusabdullah has joined #elliottcable
Sgeo has joined #elliottcable
Sgeo_ has quit [Ping timeout: 265 seconds]
jesusabdullah has quit [Ping timeout: 265 seconds]
jesusabdullah has joined #elliottcable
<SwooshyCueb>
Goddammit I crashed
<ELLIOTTCABLE>
SwooshyCueb: it's cool. I got fed up with that fight, and am taking a break, anyway
<SwooshyCueb>
Okedok
<SwooshyCueb>
I just got some hot pockets
<SwooshyCueb>
I wish they made turkey sandwich hot pockets
<ELLIOTTCABLE>
hot pockets. great idea. brb.
jesusabdullah has quit [Ping timeout: 255 seconds]
<SwooshyCueb>
lol
<purr>
lol
jesusabdullah has joined #elliottcable
<ELLIOTTCABLE>
SimCity time!
<SwooshyCueb>
Have fun!
jesusabdullah has quit [Ping timeout: 245 seconds]
jesusabdullah has joined #elliottcable
<purr>
<elliottcable> If you mention CoffeeScript, I'm going to slap you with my tornado.
jesusabdullah has quit [Read error: Operation timed out]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Ping timeout: 265 seconds]
jesusabdullah has joined #elliottcable
<whitequark>
ELLIOTTCABLE
prophile has joined #elliottcable
jesusabdullah has quit [Read error: Operation timed out]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Read error: Operation timed out]
<purr>
<glowcoil> so adding features is a crapshoot whether it fits right in or requires radical restructuring
jesusabdullah has joined #elliottcable
<ELLIOTTCABLE>
whitequark: sup
Rusky1 has joined #elliottcable
<whitequark>
ELLIOTTCABLE: hang on
<whitequark>
talking on skype now
Rusky has quit [Ping timeout: 255 seconds]
<whitequark>
back.
<whitequark>
ELLIOTTCABLE: so I've been thinking about your executions and shit
<whitequark>
first. your coproduction thing. "let's emulate multi-argument calls with several single-argument calls".
<whitequark>
I don't know whether the term coproduction does mean that (I bet it does not), but in general, it's called "currying".
<whitequark>
it's a decent idea for an IR (and cPaws/Paws Scripts are an IR.)
<whitequark>
second, I've been thinking about why do you even have pc and stack, and now I realize it.
<whitequark>
it's just the definition of internal semantics of a dumb AST-walking interpreter for expressions.
<whitequark>
indeed, defining the semantics of evaluation via term rewriting would be much cleaner for the spec, and *also* it would eliminate the ambiguous case of cyclic expressions (because that simply makes no sense with term rewriting).
<whitequark>
and/or you could make the expressions immutable, which would also naturally eliminate cycles.
<whitequark>
ELLIOTTCABLE: poke
<ELLIOTTCABLE>
reading
<ELLIOTTCABLE>
nonono not currying. suuuuuuuuper-fucking-different thing.
<whitequark>
well, I don't see how it is not
<ELLIOTTCABLE>
It *looks* similar, but currying is substantially different, because currying means there's *wrapped routines*. i.e. at some point, it ‘returns’ *a different routine*. This is coroutine-style consumption of arguments.
<ELLIOTTCABLE>
and nobody says a coroutine ‘curries’ in arguments. That's bollocks. :P
<whitequark>
mhm
<whitequark>
yeah, right, this depends on mutation
<ELLIOTTCABLE>
as for the other thing: yep, sounds about right
<ELLIOTTCABLE>
I'm realllllly exhausted. Fucking around in SimCity, getting ready to crash, though, probably.
<ELLIOTTCABLE>
chat more tomorrow?
<whitequark>
grmbl
<whitequark>
maybe
<whitequark>
I still hate the way you define executions
<whitequark>
cloning, wtf, shouldn't be necessary.
<whitequark>
"priming", even more wtf, is not necessary.
<whitequark>
mutation of them, ugly, and probably should be reworked.
<whitequark>
the way "locals" are handled, UGH
<whitequark>
or rather, lack of any good decision on that part
yorick has joined #elliottcable
<whitequark>
ELLIOTTCABLE: how do you write ping-pong in paws?
<whitequark>
two executions exchanging messages forever.
jesusabdullah has quit [Ping timeout: 255 seconds]
jesusabdullah has joined #elliottcable
Rusky1 has quit [Quit: Leaving.]
Rusky has joined #elliottcable
jesusabdullah has quit [Ping timeout: 255 seconds]
jesusabdullah has joined #elliottcable
Sgeo has quit [Read error: Connection reset by peer]
jesusabdullah has quit [Ping timeout: 240 seconds]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Ping timeout: 268 seconds]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Ping timeout: 246 seconds]
jesusabdullah has quit [Read error: Operation timed out]
jesusabdullah has joined #elliottcable
<purr>
<Nuck> elliottcable: You train your dogs to bark at the sight of a buttplug or what?
eligrey has quit [Quit: Leaving]
eligrey has joined #elliottcable
jesusabdullah has quit [Ping timeout: 246 seconds]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Ping timeout: 255 seconds]
prophile has quit [Quit: The Game]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Read error: Operation timed out]
jesusabdullah has joined #elliottcable
<glowcoil>
whitequark: yeah those are basically the things i've been arguing about paws
<glowcoil>
whitequark: i don't like priming or cloning
<glowcoil>
whitequark: and the object/scope system seems like it could be improved
<glowcoil>
whitequark: though those things are *kind of* incidental to what makes paws good, i'd say
<whitequark>
incidental?
gozala has joined #elliottcable
<glowcoil>
whitequark: as in they're a mechanism upon which there was going to eventually be built a nice stdlib and shit that makes for a probably not unique, but still interesting and useful way of programming
<glowcoil>
whitequark: but they could be replaced with another way to achieve that way of programming
<whitequark>
well so far executions are a very awkward implementation of a CPS IR
<whitequark>
essentially
<glowcoil>
right
<glowcoil>
that's what i've been saying
<whitequark>
I don't have much more objections to the object system; the receiver thingy is great, and I'm pretty damn sure that index-0 can and should be replaced with multi-dimensional objects
<whitequark>
and ownership system is basically very similar to what Rust currently has
<whitequark>
and I would *expect* the mask-whatever system to be essentially isomorphic to the dynamic borrow checker of Rust
<whitequark>
I mean, for all the breathtaking incompetence in CS Elliott shows, the system is pretty fucking good
<whitequark>
now I wonder what could he invent if he didn't dismiss most of CS ourtright :
<whitequark>
p\
<glowcoil>
whitequark: i've been saying that for years re replacing index-0
<glowcoil>
cool, i didn't expect it to be that similar to rust
<glowcoil>
seems like a good system though
<glowcoil>
whitequark: so ownership is a Good Part, but also i feel like nothing has really made generators/continuations/cps/whatever as ubiquitous as paws
<glowcoil>
whitequark: part of that will depend on a good stdlib for it
<glowcoil>
but also encouraging it with the syntax
<whitequark>
I honestly don't give a single fuck about CPS in Paws
<whitequark>
because Paws Scripts are essentially an IR
<whitequark>
the form of IR has absolutely no relevance whatsoever to the form of surface language
<whitequark>
I mean, Guile uses a CPS IR and still presents a direct encoding
<glowcoil>
whitequark: what do you mean by cps ir?
<glowcoil>
whitequark: because paws is not written in cps
<glowcoil>
even on the cpaws level
<whitequark>
cPaws pretty much is
<glowcoil>
no
<glowcoil>
you say
<glowcoil>
f (g ())
<glowcoil>
and then, g can call you back multiple times
<glowcoil>
so one way to imeplemnt that is to make it *undergo* cps transformation
<whitequark>
hrmpf
<glowcoil>
like the remarkable thing about paws is that without being aware of cps transforms, elliott proposed one
<glowcoil>
lol
<purr>
lol
<glowcoil>
but basically he realized that the most awful thing about node was its syntax
<whitequark>
that's not really remarkable
<glowcoil>
and that a computer can do what humans have been doing
<glowcoil>
ok sure
<glowcoil>
just sayin
<whitequark>
no, the most awful thing about node is that it forces you to write in CPS
<glowcoil>
that's exactly what is aid
<glowcoil>
come on
<whitequark>
that's a semantics question really
<glowcoil>
i wasn't complaining about regex syntax, since we were speaking in the context of fucking cps
<glowcoil>
so, node's synatx, IN THE CONTEXT OF cps
<glowcoil>
is what i was saying is its most awful thing
<glowcoil>
and paws represents a more fundamental fix to that than say
<glowcoil>
async {}
<glowcoil>
since everything in the language works like a python generator or something
<whitequark>
no difference I can see
<glowcoil>
with nice comprehensions
<glowcoil>
etc.
<glowcoil>
as well as having the ownership system to help you deal with it
<glowcoil>
which is actually a bit similar to clojure's persistent data structures i think
<whitequark>
I mean, there is a difference about the style in which you implement the stdlib, maybe
<glowcoil>
ok you don't write
<whitequark>
but there is no fundamental difference to, say, Ruby-as-a-language
<glowcoil>
print(some_list.each())
<glowcoil>
in fucking async() blocks, do you?
<whitequark>
wat?
<glowcoil>
see, you haven't even fucking learned the interseting part of paws before you're dismissing it
* whitequark
sighs
* glowcoil
sighs
<whitequark>
I'm not dismissing... Paws
<whitequark>
I'm dismissing cPaws being fundamentally important, because it's just an IR which explicitly has no relationship to the surface language
<whitequark>
talking about whether it's CPS or not, well, I'd still say it is CPS
<whitequark>
elaborating
<glowcoil>
what do you mean by cps
<glowcoil>
do you mean, written in cps
<glowcoil>
or
<glowcoil>
undergoes cps trasnformation before running
<glowcoil>
because the latter is one possibility for running it, that *i have written before on cPaws*
<glowcoil>
and the former is *not true*
<whitequark>
how is it not true?
<glowcoil>
ok, tell me
<glowcoil>
where do you write in cps
<glowcoil>
in fucking cpaws
<glowcoil>
ok i guess the dumb () passing to prime/coproduce
<whitequark>
all control flow happens via cps
<glowcoil>
is technically cps
<whitequark>
yes
<glowcoil>
ok but you can eventually make a (very thin) standard library, *in cpaws*, in whcih you write no cps
<whitequark>
the expressions are mostly in direct style, sure, but that's not the interesting part
<glowcoil>
that's not possible if you're just writing in cps normally
<glowcoil>
so there's something there
<glowcoil>
also i don't like cpaws anyway
<glowcoil>
and wish it weren't elevated to such a high level of namedness/importance
<whitequark>
well the VM will still only know about CPS part
<glowcoil>
that's why i wanted to make hands
<glowcoil>
ok i'm going to go
<glowcoil>
*write hands*
<glowcoil>
and maybe that will convince you
<glowcoil>
because cpaws should not be the level exposed to pedantic people like you
<whitequark>
oh fuck off
<whitequark>
you can't implement a good language unless you're pedantic anyway
<whitequark>
you get shite like PHP and JS.
<glowcoil>
i guess elliott and i are defending somewhat different things
<whitequark>
it's likely that I don't care about either. I see a runtime with an interesting error handling strategy, with a federation strategy not entirely unlike the one I wanted to do myself, and a few other curious properties unlike anything else I've seen
<glowcoil>
ok
<ELLIOTTCABLE>
cPaws is shite, and we all know it.
<whitequark>
ELLIOTTCABLE: so
<ELLIOTTCABLE>
But something *like* cPaws need exist, and thus, it might as well be cPaws.
<glowcoil>
ELLIOTTCABLE: i disagree vehemently a gain
<glowcoil>
again*
<glowcoil>
i really don't think it needs to exist, especially at such a level of officiality
<whitequark>
I kinda agree with ELLIOTTCABLE here
<ELLIOTTCABLE>
And I'd rather spend every moment involved in improving nuclear shit, improving more important parts than cPaws, which means it's fairly raw, unimproved, and shitty, and I'm okay with that
<ELLIOTTCABLE>
no, I agree with glowcoil, 9999%
<ELLIOTTCABLE>
(Hee)
<whitequark>
though I won't be involved with cPaws unless it 100% satisfies my standards of elegance
<whitequark>
so there's that
<ELLIOTTCABLE>
The only reason it exists, even though it generally isn't important to the semantics,
<ELLIOTTCABLE>
Is to INFORM DISCUSSIONS.
<glowcoil>
like i don't even get why we can't have scope
<glowcoil>
etc.
<ELLIOTTCABLE>
Look up above how you tried to use print(a.list each) as an example.
<ELLIOTTCABLE>
cPaws exists for *exactly that*, 80%,
<whitequark>
anyway I finished the parser.
<whitequark>
$ ./oPaws.native "foo ((bar)"
<whitequark>
Syntax error at line 1, column 5: unterminated `('
<whitequark>
foo ((bar) ^
<ELLIOTTCABLE>
and to help assuage people who're new to this whole mess, and still believe that the first thing you do when writing any programmin language implementation is write a goddamn boring parser.
<whitequark>
^ ← caret misplaced again.
<whitequark>
anyway.
<whitequark>
ELLIOTTCABLE: now I need more stuff to continue implementing
<ELLIOTTCABLE>
sorry for replies I am not really here. did not sleep last night. Going back to sleep.
<whitequark>
fuck.
<ELLIOTTCABLE>
whitequark: having any trouble with the rest of the spec, and the rest of what we talked about?
<whitequark>
ELLIOTTCABLE: I need descriptions of mutation semantics
<whitequark>
and, linked to it, descriptions of whatever code I can use to write unit tests in cPaws.
<ELLIOTTCABLE>
how so? what's dat been
<whitequark>
hm?
<ELLIOTTCABLE>
meen*
<whitequark>
well, you never actually mention in the spec how does one create an object or mutate it.
jesusabdullah has quit [Ping timeout: 265 seconds]
<whitequark>
that's kinda important for the VM.
<ELLIOTTCABLE>
Not sure what I need to specify, about that.
<ELLIOTTCABLE>
UGHHHHHH WAKE IP, SELF
<ELLIOTTCABLE>
Can't have these conversations on an exhausted brain ;_;
<whitequark>
well, how do I create an object in cPaws?
<whitequark>
that's not in spec, hence, I can't provide an API for it, hence, my VM is useless.
jesusabdullah has joined #elliottcable
<ELLIOTTCABLE>
Ohhhhhh the native calls like that
<ELLIOTTCABLE>
I didn't have time to include them in the spec; it seemed like a good "line in the sand" of where to stop.
<ELLIOTTCABLE>
For now, copy them from upaws.js; they're pretty straight-forward;
<ELLIOTTCABLE>
or ask Micah
<whitequark>
well, they definitely need to be in the spec
<whitequark>
glowcoil: ?
<glowcoil>
i don't know all the infrastructure things
<whitequark>
wow what the fuck is this mess
<whitequark>
ELLIOTTCABLE: upaws is completely incomprehensible to me
<whitequark>
and I'm not exactly excited by the task of essentially reverse-engineering a non-compliant implementation for an ambiguous spec
jesusabdullah has quit [Ping timeout: 240 seconds]
<whitequark>
ELLIOTTCABLE: more things about the spec.
<whitequark>
you *must* spec the behavior of List and Bool types, at the very least, because you refer to them.
jesusabdullah has joined #elliottcable
<whitequark>
and while you don't refer to numbers anywhere, I figure it that after you have a Bool type, it would make sense to at least provide a suggestion for a numeric type which is not "interned decimal literals"
audy has quit [Ping timeout: 245 seconds]
jesusabdullah has quit [Ping timeout: 264 seconds]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Ping timeout: 255 seconds]
jesusabdullah has joined #elliottcable
trolling has joined #elliottcable
trolling has quit [Quit: Lost terminal]
jesusabdullah has quit [Ping timeout: 255 seconds]
audy- has joined #elliottcable
<glowcoil>
hy
jesusabdullah has joined #elliottcable
<whitequark>
hm?
<joelteon>
i was an intern once
jesusabdullah has quit [Ping timeout: 240 seconds]
jesusabdullah has joined #elliottcable
<glowcoil>
POLAR COORDINATES PROVE YOU CAN BIJECT BETWEEN ANY FINITE OR INFINITE INTERVAL OF THE REALS
<purr>
<devyn> I'm high on cold medicine, so I don't give a fuck, yay
<ELLIOTTCABLE>
whitequark: there *are* no book or list types. Wat?
<whitequark>
ELLIOTTCABLE: but you refer them from the spec.
<whitequark>
isChild, relations, words, and so on and so on.
jesusabdullah has quit [Ping timeout: 264 seconds]
jesusabdullah has joined #elliottcable
PragCypher has quit [Quit: Leaving]
alexgordon has joined #elliottcable
jesusabdullah has quit [Ping timeout: 255 seconds]
Sorella has quit [Quit: Ex-Chat]
jesusabdullah has joined #elliottcable
jesusabdullah has quit [Ping timeout: 240 seconds]
jesusabdullah has joined #elliottcable
* SwooshyCueb
flails
<ELLIOTTCABLE>
whitequark: that's, like, built-in shit. you're telling me that my Paws spec, needs to define a C Boolean? /=
<ELLIOTTCABLE>
hello, all. I'm awake. Maybe. For a given, non-linear value of awake.
<glowcoil>
ELLIOTTCABLE: yeah a spec should definitely define booleans if they're userspace-accessible
<ELLIOTTCABLE>
No, they're not
<ELLIOTTCABLE>
he's talking about the "return types" of the chunks of functionality I reduced to APIs.
<alexgordon>
THEN FUCK YOU
* alexgordon
is trying to generate entropy in javascript
<ELLIOTTCABLE>
Anyway, all irrelevant, cuz all that interface crap is getting removed next time
<glowcoil>
ELLIOTTCABLE: are they returned to paws code?
<ELLIOTTCABLE>
lolgodsno
<purr>
lolgodsno
<glowcoil>
ok lol
jesusabdullah has quit [Ping timeout: 240 seconds]
<glowcoil>
so this shouldn't be in a spec becasue it's jury-rigged shit
<alexgordon>
ooh Date.parse()
<whitequark>
ELLIOTTCABLE: anyway, I think your refusal to include any primitive types in cPaws is shortsighted
<whitequark>
1) any practical implementation will include them anyway
<whitequark>
2) it allows you to do *something* while bootstrapping much easier
<whitequark>
etc
<whitequark>
ELLIOTTCABLE: if I read you correctly and you basically perform booleans by checking whether a function ever does return
<ELLIOTTCABLE>
nonnono
<whitequark>
and you perform sequencing by *locking*
<whitequark>
then this is awful and dumb
* ELLIOTTCABLE
shrugs
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE>
church numerals are awful and dumb, but they're useful in a certain context.
<whitequark>
it's okay if you do, say, formal verification and need the most simple kernel ever, because otherwise you do a lot of extra work
<whitequark>
exactly, and this is not it.
<whitequark>
you're definitely not doing formal proof verification based on cpaws.
<whitequark>
it's not fucking hoon/nook
<ELLIOTTCABLE>
disagree. straw-man, this isn't about formal verification, whatever even that is. /=
<whitequark>
what is this about then?
<ELLIOTTCABLE>
but, … arguments about what's sane, or insane, about paws, let's just hold off for a bit.
* whitequark
sighs
<ELLIOTTCABLE>
at the very least until its properly specified, so we all know *what* insane shit we're arguing about.
<whitequark>
I'm not interested working on a VM whose design is actively making it hard to implement and debug it
<whitequark>
no, not even that
<whitequark>
*philosophical decisions* about whose design actively make that hard
<ELLIOTTCABLE>
and probably until it's basically implemented a couple times, so we can be writing code and *verified* that something is horrible or not-horrible
<whitequark>
because I don't see any technical arguments.
<alexgordon>
yay figured it out
<ELLIOTTCABLE>
not including a boolean type is actively difficult for you to implement? o_O
<ELLIOTTCABLE>
I mean, I could see you arguing that *including* a type is not difficult for you to implement additionally, but,
<ELLIOTTCABLE>
the spec not dictating that you do so, makes it harder? how on earth.
* whitequark
sighs
<whitequark>
well, seems like I'm guessing the higher-level patterns of usage based on the spec, which is likely wron
<whitequark>
g
<whitequark>
anyway
<whitequark>
let's do it another way
<ELLIOTTCABLE>
yiss?
<whitequark>
I actually understand the spec well enough right now to implement a compliant cPaws VM for it
<whitequark>
I believe it, at least
<ELLIOTTCABLE>
current goals: write tests for (devilishly hard, I'm bad at testing), and then impl for, the reactor in Paws.js
<ELLIOTTCABLE>
get it basically executing code, a little
<whitequark>
the problem is that such a VM would be entirely useless, because what's in the spec is absolutely not enough to execute even a single combination
<ELLIOTTCABLE>
and then start talking distribution, get some plans in place for version 11.
<whitequark>
like, literally not even a single one.
<ELLIOTTCABLE>
whitequark: hm, how so? The only thing missing (besides accidental oversights) is the natives.
<whitequark>
how do you do *anything*, given only what's in the spec?
<whitequark>
anything at all.
<ELLIOTTCABLE>
the spec allows you *only* to preform combinations.
<whitequark>
ah, well, Church numerals. I'm not even sure you can do that given just what's in the spec.
<whitequark>
I think you'd need at least one native for it.
<ELLIOTTCABLE>
you can't.
<ELLIOTTCABLE>
no append operation.
<whitequark>
ok
<ELLIOTTCABLE>
I FUCKING HATE,
<ELLIOTTCABLE>
THAT IRCCLOUD DOESN'T SAVE WHAT I TYPE, IF I HIT THE DOWN ARROW.
<whitequark>
lol
<purr>
lol
<whitequark>
so
<whitequark>
I guess it means I need something beyond spec.
<ELLIOTTCABLE>
one of my most-commonly-used features of irssi was to type something, a long message I'm working on, and then hit the down-arrow to “save it” in my entry history if I need to quickly reply to something.
<ELLIOTTCABLE>
whitequark: agreed.
<whitequark>
so far you didn't really tell me anything beyond it.
<ELLIOTTCABLE>
yeah
<whitequark>
and it pisses me off
<ELLIOTTCABLE>
this is all my fault, I'm aware.
<whitequark>
because I don't really understand anything
<ELLIOTTCABLE>
huh?
<whitequark>
and I'm trying to draw far-reaching conclusions
<whitequark>
because that's what I always do
<ELLIOTTCABLE>
you understand everything, except for some *really really really* simple natives.
<whitequark>
and fail hilariously
<whitequark>
and THAT pisses me off to no extent.
<whitequark>
anyway.
<ELLIOTTCABLE>
every single native I provide is basically one, two, or three composed operations, from the set of operations already used in that spec.
<ELLIOTTCABLE>
so, like I said, I can add them all in a matter of an hour or two, probably.
<whitequark>
that'd be pretty cool
<ELLIOTTCABLE>
but here's the problem:
<ELLIOTTCABLE>
when I do so, I want to specify them well,
<ELLIOTTCABLE>
and, straight-up, it seems like a colossal waste of effort to try Very Hard on *anything* related to the document you're using right now.
<whitequark>
agreed
<ELLIOTTCABLE>
It's succeeded at its goal (being enough that you, or more accurately alexgordon, can implement based on it),
<ELLIOTTCABLE>
well, not quite, I guess, since no natives, and you can't figure 'em out from mupaws,
<whitequark>
alexgordon? I was thinking I'm currently the only one writing a VM...
<whitequark>
hm
<whitequark>
well
<ELLIOTTCABLE>
… but it's *clearly* a clusterfuck, I'm very disappointed over it, and I don't really want to pour much more effort into this version.
<alexgordon>
whitequark: you're writing a paws VM?
<whitequark>
alexgordon: I already wrote like half of it
<ELLIOTTCABLE>
whitequark: yes, you are, but alexgordon's work is *crucial* to me.
<alexgordon>
lol
<purr>
lol
<ELLIOTTCABLE>
alexgordon brings something to the table, for me, that nobody else has, yet.
<alexgordon>
I'm the villiage idiot \o/
<whitequark>
yeah yeah I remember. whatever. gimme the natives or something.
<ELLIOTTCABLE>
okay
<whitequark>
by the way, another fault in your spec: while it talks about going to a "parent Node",
<ELLIOTTCABLE>
fuck this I'll just do it right here, right now, in text
<ELLIOTTCABLE>
and you can ask questions.
<whitequark>
it doesn't actually have a parent of a node specified
<ELLIOTTCABLE>
I might document them in a non-specific way in the v10 spec, just for completeness' sake.
<whitequark>
in the interface or whatever
<ELLIOTTCABLE>
whitequark: yeah. Again, failure of the "interface," not the actually spec, I believe.
<whitequark>
but that'll go away when you rewrite advance() in terms of term rewriting
<whitequark>
so whatever
<alexgordon>
ELLIOTTCABLE: so what exactly do I bring to the table?
<ELLIOTTCABLE>
that's an instance of me doing it the **right** way.
jesusabdullah has joined #elliottcable
<ELLIOTTCABLE>
i.e. leaving the details up to the imll.
<ELLIOTTCABLE>
the point is to say to the impl: "You need to design a way such that the reactor always has access to the parent expression."
<ELLIOTTCABLE>
i.e. extend the required design as described of nodes, expressions, etc,
<whitequark>
ELLIOTTCABLE: it's really not, because the semantics of "parent expression" are not clear in presence, of, say, mutability
<ELLIOTTCABLE>
with some sort of methodology of attaining the parent, when you're deep in an Expression.
<whitequark>
e.g. what if two Nodes share another Node?
<whitequark>
which of the Nodes is a parent?
<ELLIOTTCABLE>
Paws.js does it one way, Paws.c does it another way, mupaws did it a third (stupid) way.
<ELLIOTTCABLE>
Expressions should always, always be a tree. Anything that allows you to mutate that will be dictated to enforce that fact.
<whitequark>
saying that Nodes are immutable, represent a tree, and then specifying evaluation of term rewriting would preclude that question from ever appearing.
<whitequark>
*evaluation in terms of
<ELLIOTTCABLE>
Man. This shit is great. It's depressing, in a lot of ways, but we're plowing through more conceptual-holes and unspecified-shit in three days than we used to be able to in a month.
<ELLIOTTCABLE>
(like, discovering that it need be *specified* that expression are trees. :P )
<ELLIOTTCABLE>
yeah, term-rewriting is definitely happening.
<ELLIOTTCABLE>
it's going to be rather messy to describe, but at least it'll be messy in a *different way( than the current one.
<ELLIOTTCABLE>
the original problem with term-rewriting, which is why I never implemented it that way (nor spec'd it that way, consequently),
<ELLIOTTCABLE>
is that it doesn't play well with A) mutable Scripts that are B) shared between Executions.
<whitequark>
well, mutable shared state doesn't play well with *anything*
<ELLIOTTCABLE>
LOL
<purr>
LOL
<whitequark>
so that's a non-issue.
<devyn>
[, 12
<devyn>
oops
<ELLIOTTCABLE>
devyn, hello
<ELLIOTTCABLE>
okay, whitequark
<devyn>
ELLIOTTCABLE: sorry about not really being able to Paws lately
yorick has quit [Remote host closed the connection]
<ELLIOTTCABLE>
let's mofuckin do this, I guess
<devyn>
been crazy busy
<devyn>
lol
<ELLIOTTCABLE>
devyn: you don't need to apologize for not spending your life working on my nutty project :P
<devyn>
well
<devyn>
I'm Canadian
<devyn>
sorry
<ELLIOTTCABLE>
but I also ain't gonna shut up about it ;)
<ELLIOTTCABLE>
devyn: hey, come write a Paws real quick.
<ELLIOTTCABLE>
unimportant, but that'd traditionally be Paws.ml :P
<ELLIOTTCABLE>
my eyebrow hurts /=
<ELLIOTTCABLE>
okay.
<ELLIOTTCABLE>
natives.
<ELLIOTTCABLE>
just gonna open mupaws and walk through them, for now.
<devyn>
OCaml gets such a sexy color on GitHub
<devyn>
lime green
<ELLIOTTCABLE>
devyn: you have no idea how often I've wondered “If I don't get Paws finished fast enough, it will get registered on GitHub late, and get an ugly, left-over color!”
<ELLIOTTCABLE>
;)
<devyn>
hahahaha
<ELLIOTTCABLE>
Unfortunately, I never wrote anything down anywhere, and there's a good chance there's a few that weren't-yet-implemented in mupaws are now completely forgotten about on my part.
<ELLIOTTCABLE>
so don't assume this is everything that's necessary to write sane Paws code. (ugh.)
<ELLIOTTCABLE>
(devyn: because we ALL want puke-browngreen bars at the top of our Paws projects.)
<devyn>
oh totally
<devyn>
like #cccc00
<ELLIOTTCABLE>
whitequark: so I assume you took a gander at muPaws, even if you're allergic to elliott-code, yes?
<whitequark>
I did
<ELLIOTTCABLE>
well, as it said:
<ELLIOTTCABLE>
the semantics of the libside API are possibly one of the most still-mutable parts of the language.
<ELLIOTTCABLE>
because it's easier to change the nitty-gritty specifics of stage()'s rules, than it is to re-design, say, the reactor, or ownership, or the object-system.
<ELLIOTTCABLE>
and those things that are hard to change wholesale, are the ones I've put the most thought into, because I want them to be the most stable.
<ELLIOTTCABLE>
relevant notes from the top:
<ELLIOTTCABLE>
// - There's no number type; so I do some stupid shit with decimal-numeric labels. Very fragile, not intended to last.
<ELLIOTTCABLE>
(we'll see about that. I'm more compfortable with it than I used to be.)
<ELLIOTTCABLE>
// - Some of these aren't at all planned, I threw them in because I *needed* them when playing with things: `length`, everything under `number`. Again, not intended to last.
<ELLIOTTCABLE>
// - `branch`, `stage`, and `unstage` need to be re-thought-out in light of the *actual implementation design* that we've arrived at. Thoroughly.
<ELLIOTTCABLE>
those last three are extremely crucial to Paws, clearly. They're the equivalent of, idk, `yield` or a function-call, shit that is extremely tightly tied to the execution model and how you exercise the power of that model.
<whitequark>
you do realize that all numbers that come into existence will be interned and therefore will remain in memory forever?
<whitequark>
all decimal-shit-numbers.
<ELLIOTTCABLE>
hm?
<whitequark>
well, if you can do L'1' + L'2' and get L'3'
<whitequark>
then L'3' gets interned and remains in memory forever, because symbols are not in general GC'd.
<ELLIOTTCABLE>
that's probably fine, when the numbers you're interning are just *indices*.
<ELLIOTTCABLE>
can argue it more later, I'm sure.
<whitequark>
I'm honestly not even going to discuss lack of numbers in absence of technical arguments, I'll just implement it as I seem correct.
<ELLIOTTCABLE>
I'm not dead-set on numberlessness.
<whitequark>
*shrug*
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE>
I'm just convinced, for the moment, that it's possible and beneficiary to explore it.
<ELLIOTTCABLE>
lolol
<purr>
lolol
<ELLIOTTCABLE>
empty: function(){ return new Thing }
<ELLIOTTCABLE>
okay. back up. the basics.
<ELLIOTTCABLE>
All data/code *required by the specification*, gets into program on a single object, created at start-time, and injected into the `locals` of the first Execution created for the root Script.
<ELLIOTTCABLE>
that object is called `infrastructure`, often just called infra, and is assigned to that key on aforementioned locals.
<ELLIOTTCABLE>
so.
<ELLIOTTCABLE>
native ‘routines’
<ELLIOTTCABLE>
another side-note:
<ELLIOTTCABLE>
remember, the *minimum calling-pattern necessary* for a given operation will be applied. Some of these will be different for some routines than for others. I'll explain the reasoning for each kind, the first time we see it.
<whitequark>
minimum calling-pattern necessary?
<whitequark>
wtf?
<ELLIOTTCABLE>
what we saw with the print-example.
<ELLIOTTCABLE>
print didn't *need* a caller to re-stage, since it was incapable of ever producing a result; thus, it looks like `print foo` instead of `print() foo`
<ELLIOTTCABLE>
lots of similar examples, and also very different ones, here.
Sgeo has joined #elliottcable
<ELLIOTTCABLE>
`infra empty void`: creates a new (obviously, empty) Object, and resumes the caller with it.
<whitequark>
by the way, I'm pretty convinced that sequencing should happen through every function getting a completion argument even if it returns nothing, not through that weird locking thing you have.
<whitequark>
explicit "infra" ?
<ELLIOTTCABLE>
(more usually called as `empty()`, but I want to differentiate, here, between ones that *need* the caller to be passed in with (), and ones that only need to be staged, for which the value is irrelevant. using void for that purpose, at the moment.)
<ELLIOTTCABLE>
nah, sorry,
<ELLIOTTCABLE>
`infrastructure empty` would be where this one would be stored. That, basically, is its' “name.”
<whitequark>
name?
<whitequark>
what?
<ELLIOTTCABLE>
… as in, how you get it.
<ELLIOTTCABLE>
and what we call it when we talk about it.
<ELLIOTTCABLE>
“`infra empty` is a routine that produces a new Object.”
<whitequark>
ok
<ELLIOTTCABLE>
next:
<ELLIOTTCABLE>
since you're not going to implement indices the same way, for now, I'm just going to leave the specifics of that undefined,
<ELLIOTTCABLE>
but,
<whitequark>
not going to implement indices? hang on, what about them?
<ELLIOTTCABLE>
you said you weren't going to do indices-as-symbols, and were going to do things your own way
<ELLIOTTCABLE>
and I'm about to describe something that uses indices-as-symbols
<whitequark>
ah. yes. definitely not. I'll introduce a numeric type.
<whitequark>
that being said, I'm not opposed to Church *booleans*. fwiw, even Smalltalk has them
<ELLIOTTCABLE>
`infra get() (thing) (num)`: obtaining an integer from the second parameter, however you please, the caller is resumed with the value at that index on the first param. If the object isn't long enough, or the index is empty, then this never re-stages the caller.
<ELLIOTTCABLE>
yes, but we're not *functional*.
<ELLIOTTCABLE>
What I have for booleans **IS** our equivalent of a Church boolean.
<ELLIOTTCABLE>
Church booleans are function-oriented languages implementing booleans, in terms of only functions.
<ELLIOTTCABLE>
a Paws boolean is an asynch-oriented language implementing booleans in terms of asynchronous operations.
<ELLIOTTCABLE>
anyway, argument for later, back on your heads:
* whitequark
shrugs
<purr>
¯\(º_o)/¯
<whitequark>
then a proper boolean type it is.
<purr>
<micahjohnston> I don't enjoy plumbing on a coputer
<ELLIOTTCABLE>
you realize it's clearly unhelpful to implement it ‘wrong’ now, when I still need to have an in-depth discussion of the topic before making a decision, right? :P
<whitequark>
well, I implement what makes sense to me ;)
<ELLIOTTCABLE>
`infra find()(thing)(key)`: preforms the exact operation that the built-in default-Object-receiver does (what we call a look-up), over and over until no further matching entries are found; and then resumes the caller with a list constructed from those matching entries.
<ELLIOTTCABLE>
if no matches are found, does not resume the caller.
<whitequark>
I assume error handling is "postponed"?
<whitequark>
time travel etc
<ELLIOTTCABLE>
mmhmm
<ELLIOTTCABLE>
insanity, actually, in this case
<whitequark>
well, whatever it is, as long as it exists and doesn't silently eat errors.
<whitequark>
exists in future, perhaps
<ELLIOTTCABLE>
lol that's exactly what it does.
<purr>
lol
<ELLIOTTCABLE>
well, not silently.
<ELLIOTTCABLE>
insanity is our counter to Erlang, I suppose: “Let's build a system that, instead of crashing and doing nothing of any value to anyone except spitting out cryptic messages … does *as much as it can* with the data, and environment, it does have, before giving up.”
<ELLIOTTCABLE>
it's half a philosophy, and half a part of the programming language.
<ELLIOTTCABLE>
basically, it's object-tainting. I'm sure you're familiar with something with a specific CS name that's basically the same thing.
<whitequark>
object-tainting?
<ELLIOTTCABLE>
when some part of the object-graph (and by extension, because in-progress execution exists *inside* the object-graph by way of Execution objects) is discovered to be erroneous to some extent, that part is ‘tainted.’
<ELLIOTTCABLE>
Nominally, I believe, originally, with an integer; but we were definitely talking about designing it in such a way that you could taint it with *any* object (thus allowing for complex error-metadata objects to be used instead, if the lib side abstraction wished to do so.)
<ELLIOTTCABLE>
that taint ‘infects’ (is shared with) anything it touches, either by way of data, or by way of code. the taint can never be removed (although glowcoil disagreed with that), except by way of time-travel.
<ELLIOTTCABLE>
(i.e. rolling back the entire transaction.)
<whitequark>
mhmmm
<ELLIOTTCABLE>
that said, the entire program can continue running ad infinitum, if no part of it is *bothered* by that taint.
<whitequark>
so, lazy exceptions, kinda like in haskell
<ELLIOTTCABLE>
so, for instance, if a bit of logging-code tries to print out a serialization of a value to the log file, and the value can't be serialized … the program continues running, but *is insane*. Anything that's called by, or interacts with that section, is also insane. However, A) it won't propagate to most of the program, because it's just some obscure little
<ELLIOTTCABLE>
logging corner, and B) even the parts it does propagate to, probably won't care.
<ELLIOTTCABLE>
yissss kinda
<whitequark>
that's actually pretty bad
<ELLIOTTCABLE>
pafff
<whitequark>
because it silently chews up logs
<ELLIOTTCABLE>
mmhmm, agreed
<ELLIOTTCABLE>
broken code is definitely bad
<whitequark>
like, it's almost malicious
<ELLIOTTCABLE>
but which is worse: a situation where that would neither A) write the log, nor B) respond to the user's urgent banking request,
<ELLIOTTCABLE>
or a situation where A) it doesn't write the log, but B) the user's banking request, which wasn't affected by the bag logging code, goes through?
<whitequark>
first is definitely better.
<ELLIOTTCABLE>
disagree entirely.
<ELLIOTTCABLE>
that makes absolutely no sense at all.
<whitequark>
in your very specific situation.
<whitequark>
those logs are used to prevent banking fraud.
* ELLIOTTCABLE
eyebrows
<ELLIOTTCABLE>
uh, not what I meant by log.
<whitequark>
if they *somehow* suddenly stop working and you don't know about it...
<ELLIOTTCABLE>
clearly, “not saving accounting information” is a much, much more serious form of insanity than “not saving debugging information about the web-request.”
<ELLIOTTCABLE>
as for not knowing about it, *also* incidental and irrelevant:
<ELLIOTTCABLE>
ignoring insanities for a moment,
<whitequark>
well, in my experience, only a tiny minority of exceptions in a program should ever be ignored.
<ELLIOTTCABLE>
either A) the framework/system has written/created some sort of method whereby errors or exceptions are printed out/reported for the programmer's benefit, or B) they haven't.
<whitequark>
mainly those relating to a transient failure, for which, and this is important,
<whitequark>
there is a mechanism which would restart the task.
<ELLIOTTCABLE>
and insanity doesn't affect that: just because *the rest of the program* can continue to do things that are crucial-enough, and not-affected-enough, doesn't mean that exact same reporting/printing/whatever mechanism can't exist and operate.
<whitequark>
(framework/system) yeah, that usually works, because almost all software fails safely--in fact, just aborts.
<whitequark>
so if something *entirely unexpected* happened, you learn about it very quickly.
<ELLIOTTCABLE>
and no reason the same thing can't happen here.
<ELLIOTTCABLE>
It's still trivial to shut down the program on insanity, if you're really that terrified of the unexpected (for instance, security-related software)
<whitequark>
no, I'm not "really that terrified of unexpected".
<ELLIOTTCABLE>
the point is, is that it's a *gradient* from IGNORE EVERYTHING AND DO EVERYTHING YOU CAN TO CONTINUE TO EXECUTE, to CRASH ON ANYTHING UNEXPECTED BECAUSE THIS OPERATION MUST BE PERFECT.
<ELLIOTTCABLE>
and insanities delineate that gradient and allow you to act on it, instead of at either extreme.
<whitequark>
a program must do all the things which I had in mind and precisely nothing else, or it is invalid.
<ELLIOTTCABLE>
and, with that statement, every single program ever written, being written, and currently running, are invalid.
<ELLIOTTCABLE>
Because every single one has bugs, and has as-of-yet-unimplemented features.
<whitequark>
well, not every single one
<ELLIOTTCABLE>
The only difference in question is whether an un-handled bug in an unrelated part of the program, takes *the entire thing down* with it.
* ELLIOTTCABLE
eyebrows
<whitequark>
there are formally verified programs. e.g. an ECMAScript interpreter that is known to be bugless, if you want something practical.
<ELLIOTTCABLE>
you posit that there exist in the universe programs which are both A) feature-complete for the possible tasks associated with them (so not just `hello world`), and B) *completely* bug-less?
<whitequark>
yes.
<ELLIOTTCABLE>
how is that even a sane statement
<ELLIOTTCABLE>
wat
<whitequark>
formal verification of software is a thing.
<whitequark>
you describe a specification in, usually, Coq. then you write code, and a formal verification tool checks that in any possible case, the program does exactly what is in spec and nothing else.
<whitequark>
it's very time-consuming, but there is nontrivial software, sometimes *very* practical, written using this.
<whitequark>
listing examples:
<whitequark>
1) aforementioned ECMAScript impl.
<whitequark>
2) CompCert, a mildly optimizing C compiler.
<whitequark>
3) a web browser core. not the *entire* webkit+v8+etc stack, just a tiny component which mediates keyboard/mouse and cookie access to the former, thus making stealing cookies impossible, assuming an impenetrable OS sandbox.
<whitequark>
4) I believe a verified variant of L4 exists, so, an OS kernel.
<whitequark>
5) a Java runtime for smart (think credit) cards.
<ELLIOTTCABLE>
interesting.
<whitequark>
I'm sure more examples exist.
<ELLIOTTCABLE>
the smart-card runtime is verified?
<whitequark>
not all of them, just one of.
<ELLIOTTCABLE>
(relevant, was just playing with that crap)
<ELLIOTTCABLE>
oh, okay.
<whitequark>
it also costs like seven figures to license, so...
<whitequark>
your one probably is not. :p
<whitequark>
banks don't know shit about security and don't want to.
<ELLIOTTCABLE>
sorry, reading something
<whitequark>
ELLIOTTCABLE: anyway, I'm not in general opposed to idea that there is a spectrum of error-handling-urgency
<whitequark>
that actually sounds interesting
<whitequark>
I'm however definitely opposed to just silently swallowing everything *by default*.
<whitequark>
silent swallowing must be opt-in.
<ELLIOTTCABLE>
see, that's the problem, though.
<ELLIOTTCABLE>
sorry.
<ELLIOTTCABLE>
just had a very short, and unreasonably depressing, conversation.
<ELLIOTTCABLE>
just, whatever.
<ELLIOTTCABLE>
topic for discussion at a later date.
<whitequark>
it's just that you basically have PHP
<whitequark>
it's a source of bugs much more than anything else
<whitequark>
*shrug*
<purr>
¯\(º_o)/¯
<whitequark>
glowcoil: by the way, I actually realized where the idea of putting Executions directly in the AST comes from
<whitequark>
I mean, this way serialized code and loaded code don't really differ
<whitequark>
and that's pretty good
<ELLIOTTCABLE>
`infra set()(thing)(num)(to)`: obtaining an integer from the second parameter, however you please, the slot on `thing` at `num` is obtained (created, if necessary), and set to `to`.
<whitequark>
that's actually a very important thing about Paws, the way it must (in theory) be able to serialize code at middle points of computation
<whitequark>
I realized it really must change my opinion on quite a big part of the design
<ELLIOTTCABLE>
yes, freezing is a huge deal.
<ELLIOTTCABLE>
I want to do some high-minded Spaceship Preaching,
<ELLIOTTCABLE>
after we finish talking about these.
<whitequark>
ELLIOTTCABLE: also, a reason why implementation details of Execution must be present in the Nucleus spec
<ELLIOTTCABLE>
you're the only person in this room who *doesn't* know about the bigger-picture of Paws. Which in some ways, is good.
<glowcoil>
whitequark: yeah! :)
<ELLIOTTCABLE>
it allows us to have specific, low-level discussions that we couldn't otherwise have
<whitequark>
because different nodes in a federated system must be able to serialize and deserialize Executions of each other
<ELLIOTTCABLE>
yep.
<ELLIOTTCABLE>
that's JUST THE POINT, though
<whitequark>
hence, the way it is specified is not as irrelevant as I earlier thought.
<ELLIOTTCABLE>
you've stumbled across the bane of my existence:
<ELLIOTTCABLE>
the balancing of A) “I don't want to specify things tightly, because I clearly don't know what I'm doing, and every single decision I make constrains some much-smarter implementer at a later date, probably ruining the safety, stability, and performance characteristics of Paws AS A WHOLE.” …
jesusabdullah has quit [Ping timeout: 264 seconds]
<whitequark>
yeah yeah. that can only be solved by iteration
<ELLIOTTCABLE>
… versus B) “I have to specify things *enough* that implementations can meaningfully share state.”
<ELLIOTTCABLE>
incase it's in obvious,
<ELLIOTTCABLE>
that's a hugehugehugehugehugehugehugehugehugehugehugehugehugehugehugehuge motivation to keep the core language as motherfucking unreasonably, insanely, unbelievably ‘small’ as possible.
<ELLIOTTCABLE>
beyond the fact that I just really like simplicity and requiring-abstraction.
<ELLIOTTCABLE>
ugh anyway
<ELLIOTTCABLE>
can't, do, big, discussions right now
<ELLIOTTCABLE>
want to go jump off a ledge |=
<whitequark>
well
<ELLIOTTCABLE>
`infra set()(thing)(num)(to)`: obtaining an integer from the second parameter, however you please, the slot on `thing` at `num` is obtained (created, if necessary), and set to `to`.
<whitequark>
let me be entirely honest
<ELLIOTTCABLE>
thatthatthatthat
* ELLIOTTCABLE
shrugs
<purr>
¯\(º_o)/¯
<purr>
<alexgordon> micahjohnston is such a rebel, bitches love rebels
<ELLIOTTCABLE>
honesty is always welcome. not always happy-making, but always welcome.
<ELLIOTTCABLE>
-find bitches
<purr>
ELLIOTTCABLE: Found: there, are you happy now?
<whitequark>
I really like the Federation and Time-travel parts of Paws
<ELLIOTTCABLE>
-learn rebel = <alexgordon> glowcoil is such a rebel, bitches love rebels
<purr>
ELLIOTTCABLE: Learned `rebel`.
<ELLIOTTCABLE>
to be frank: you probably won't like them when I'm done with them :P
<whitequark>
like it enough that despite there being a 99.999% chance that we will not agree on some minor Paws impl detail shit and I ragequit it (95% if you incorporate my input to make it more elegant)
<ELLIOTTCABLE>
I have good ideas, but design bad programming languages. jut ask glowcoil.
<whitequark>
I'm still willing to work through all that looks entire bullshit to me.
<ELLIOTTCABLE>
hence hands.
<glowcoil>
-rebel
<purr>
glowcoil: <alexgordon> glowcoil is such a rebel, bitches love rebels
<ELLIOTTCABLE>
d'awww that's nice, love you lots
<glowcoil>
ELLIOTTCABLE: "happy-making" <3
<whitequark>
ELLIOTTCABLE: so far I'm not convinced on "bad PL" part
<whitequark>
like quite a few of your features look decent enough
<ELLIOTTCABLE>
I don't know.
<whitequark>
but your insistence on pointless crap like async-Church-encoding makes me fucking enraged.
<ELLIOTTCABLE>
how to words this.
<whitequark>
that is all
<ELLIOTTCABLE>
Paws is … a programming language.
<ELLIOTTCABLE>
like Hands.
<ELLIOTTCABLE>
but it's also *more*. It's more, to me, than simply a language that's a bag of cool ideas I had.
<whitequark>
that "quite a few" actually translates to "a fucking-huge-ton", considering your lack of PLT context
<whitequark>
so I do think you have quite some skills in designing good PLs
<ELLIOTTCABLE>
It's also a philosophy, and that's what you're running into that's causing so much discontent. glowcoil, too.
<whitequark>
perhaps misapplied.
<ELLIOTTCABLE>
The easiest way to understand this entire project, or perhaps to understand *me*,
<ELLIOTTCABLE>
is to think of me as Brendan Eich (lolpopculturereference),
<purr>
lolpopculturereference
<ELLIOTTCABLE>
or perhaps one of the too-many-to-name, *super-*libertarian, Randian, programmers.
<whitequark>
well, at the end of the day it depends on how much philosophy you will be able to give up
<ELLIOTTCABLE>
My philosophy-of-Paws infects the *language*-of-Paws, intentionally.
<whitequark>
because I sure as hell aren't picking any (not even if I wanted; this was checked too much times to be even slightly interesting.)
* whitequark
shrugs
<purr>
¯\(º_o)/¯
<whitequark>
Brendan Eich?
<ELLIOTTCABLE>
picking any what?
<whitequark>
what about him?
<whitequark>
picking any philosophy.
<ELLIOTTCABLE>
er, re-phrase
<ELLIOTTCABLE>
‘picking?’
<whitequark>
picking up? a PL, to me, is as incredibly utilitary as it ever gets.
<whitequark>
it is the ultimate tool.
<whitequark>
you know what I do with my tools (the burning printer, etc. :p)
<whitequark>
I mean, there are people quite philosophical about, say, type systems
<whitequark>
cue "static typing is the only one possible solution" zealots
<whitequark>
well, I used to think like that... for very little time. then it just became "does it eliminate a huge class of errors without imposing too much cognitive cost? use it."
<whitequark>
it can look funny at first that I work on Paws despite being pretty sure that most things could use a good static type system...
<whitequark>
until you realize that Paws actually hits one of the *very* few domains where current state of the art in static typing is woefully painful to apply.
<whitequark>
(another/linked one is e.g. exploratory programming.)
<ELLIOTTCABLE>
sorry multiple conversations
<whitequark>
like, I'm not really aware of any remotely well-tested TS where you can extend a variant type with another variant, and retain even most of the benefits of typechecking variant types.
<ELLIOTTCABLE>
you're missing my point
<whitequark>
hm?
<ELLIOTTCABLE>
I'm not talking about philosophy-of-type-system or anything. I mean, more meta than that.
<ELLIOTTCABLE>
Just, gimmie a sec, gotta deal with something
<whitequark>
no, I got that. I was just using a less meta example, which was easier to relate.
<glowcoil>
11:10:01 <+whitequark> but your insistence on pointless crap like async-Church-encoding makes me fucking enraged.
<glowcoil>
whoops
<glowcoil>
11:17:14 <+whitequark> like, I'm not really aware of any remotely well-tested TS where you can extend a variant type
<glowcoil>
with another variant, and retain even most of the benefits of typechecking variant types.
<glowcoil>
ya that
<glowcoil>
whitequark: i'm glad you've said that to me before
<whitequark>
ELLIOTTCABLE: it's just that I'm physiologically unable to give a shit about philosophy, whether I (or you) like it or not.
<whitequark>
glowcoil: I did? you're glad? I don't follow why
<glowcoil>
whitequark: idk i was being utopian about my solution to the expression problem
<glowcoil>
whitequark: and that's the problem with it
<glowcoil>
lol
<purr>
lol
<whitequark>
glowcoil: can you elaborate?
<glowcoil>
whitequark: i wanted to have like
<glowcoil>
free adding of constructors like oo and free adding of functions like adts
<glowcoil>
and you made me realize it gets all gross-subtypey
<ELLIOTTCABLE>
so,
<ELLIOTTCABLE>
this just happened.
<whitequark>
glowcoil: ah, right, I remember
<ELLIOTTCABLE>
I think it's the first time I've really understood myself, as a programmer.
<ELLIOTTCABLE>
Talking elsewhere, I finally came down to explaining *myself* (and tertiarily, Paws), thus:
<ELLIOTTCABLE>
“I mean, that’s *how I made my goddamn name*. It’s the only reason I’m remotely well-known.”
<ELLIOTTCABLE>
“It doesn’t *matter* if ten thousand people think it’s a terrible, terrible idea to override some core thing, and hack it into some other completely different thing. I do it anyway. And then get ridiculed, and praised, and all sorts of other noise, none of which changes the fact that my code worked, and works, and I consider it beautiful,”
<ELLIOTTCABLE>
“and after a while I stop listening to *any* of the noise and just do my own thing. And that after-a-while was a long time ago.”
<ELLIOTTCABLE>
I'm really self-centered when it comes to code.
<ELLIOTTCABLE>
ugh. anyway. let's just do this thing with the natives and move on.
<ELLIOTTCABLE>
oh. wanted to say something about the philosophies powering Paws.
<ELLIOTTCABLE>
I talk a lot about the theories I have at the code-level, why I do this, why I do that … what I think they'll interact to produce, UX-wise … but there's a couple deeper theories powering *the whole thing*, that probably produce unexpected results at the higher levels of though, that are disconcerting to the rest of you.
<ELLIOTTCABLE>
and probably make me look insane.
<ELLIOTTCABLE>
Right off the top of my head, there's two really, really big ones. (I'm pretty sure glowcoil, at least, already knows this):
<ELLIOTTCABLE>
1. I believe in people.
<ELLIOTTCABLE>
as a whole.
<ELLIOTTCABLE>
specifically, programmers.
<ELLIOTTCABLE>
Everybody, everywhere, seems so *down* on, well, programmers. That you have to coddle them and treat them like incompetent fools.
<ELLIOTTCABLE>
and, I mean, it's a successful approach. Look at Java.
<ELLIOTTCABLE>
now, that doesn't mean I'm down on powerful tools *that keep you safe*; safety in and of itself, isn't bad. I'm all for static verification and other similar tools, in principle.
<ELLIOTTCABLE>
but, at some deep level I don't know how to express, I find it easy to *believe* that my users will do the right thing, for themselves.
<whitequark>
ELLIOTTCABLE: one nitpick: that imples that the success of Java is correlated to its dumbness.
<ELLIOTTCABLE>
I really, really think it is.
<whitequark>
I'm fairly sure that the success of Java is correlated with the budget Sun had for it, and some random chance.
<ELLIOTTCABLE>
Java lends itself to insanely large projects, because it's one of the only toolsets where you can literally put monkeys in cubicles and put them at keyboards and they can meaningfully contribute to the completion of that project.
<ELLIOTTCABLE>
disagree.
<whitequark>
fun fact: I literally said the thing of the above.
<ELLIOTTCABLE>
Java is mob-mentality, leveraged.
<whitequark>
*the thing above.
<whitequark>
well.
<ELLIOTTCABLE>
The average I.Q. of a mob is the lowest common denominator, and all that …
<ELLIOTTCABLE>
… well, Java is the only language with such a low-I.Q.-requirement-for-usage, that it allows for larger *mobs* than any other environment, anywhere.
<ELLIOTTCABLE>
And that's cool.
<ELLIOTTCABLE>
I *like* Java, as a thing, that exists. It allows cool things to exist that otherwise wouldn't.
<whitequark>
I disagree about the low-I.Q. thing.
<ELLIOTTCABLE>
“Giant” software isn't, IMHO, a very important field *overall* (I'm not a fan of the existence of ‘the Enterprise.’) … but it's an interesting niche, and one worth having explored and exploited in our history.
<ELLIOTTCABLE>
anyway. irrelevant.
<whitequark>
you can copy-paste predefined patterns in pretty much any language. if Rails code I've seen says something... yeah.
<ELLIOTTCABLE>
long story short about what I was saying up there?
<ELLIOTTCABLE>
I will *always* give the programmer more rope.
<ELLIOTTCABLE>
Always.
<ELLIOTTCABLE>
because I believe in rope-spaceships and rope-castles and rope-sentient-servile-machinery and rope-teleporters,
<ELLIOTTCABLE>
and I believe people need a goddamn lot of rope to build all those things.
<whitequark>
rope? wtf?
<ELLIOTTCABLE>
er, American idiom.
<ELLIOTTCABLE>
“Give them enough rope to hang themselves”, is used especially often (that I've seen) in programming-language discussions, about toolsets that don't restrict the user for their own safety. Toolsets that give them too much flexibility and power.
<whitequark>
ooh, one of my favorite points.
<ELLIOTTCABLE>
anyway.
<whitequark>
there's two sides to this discussion, and I really want to lay them out right now...
<whitequark>
because it's something I only recently crystallized for myself.
<whitequark>
one side, the one which you usually see in various holy wars, is that "if you give programmers too much flexibility, they'll shoot themselves in foot", or exactly what you said.
<whitequark>
it's actually simply wrong, because if you don't, they will find their way around your arbitrary safety-net restrictions and it will be even more horrible. the examples are so aplenty it's not even funny.
<whitequark>
the other side, is that sometimes you need to take things away in one place to get them in another one. neither people nor machines are good at analysing systems where everything by definition can be coupled with anything. often, you can take away a little flexibility, but make reasoning about behavior (most importantly, by people) incredibly easier.
<ELLIOTTCABLE>
completely valid point
prophile has joined #elliottcable
<ELLIOTTCABLE>
but not exactly what I was talking about
<ELLIOTTCABLE>
you're reading it in the context of, oh, I dunno, type systems, or something.
<ELLIOTTCABLE>
low-level.
<whitequark>
yes, not exactly. but I was responding to "always more rope".
<ELLIOTTCABLE>
I'm speaking very high-level.
<whitequark>
I'm not sure if any restrictions exist on very high level.
<ELLIOTTCABLE>
Specifically, it's … probably the single biggest concern about Paws, as a whole:
<ELLIOTTCABLE>
oh, absolutely.
<ELLIOTTCABLE>
“Use this classist type system.”
<whitequark>
at the highest level, you're only ever limited by your imagination, in any language capable of sound abstraction.
<whitequark>
Java? look at, idk, Scala.
<ELLIOTTCABLE>
“You'll invoke code as ‘methods,’ with exactly one `this` object.”
<ELLIOTTCABLE>
no, disagree
<whitequark>
or Clojure or Kotlin or ...
<ELLIOTTCABLE>
your *results* are only limited by imagination
<whitequark>
yep
<ELLIOTTCABLE>
but your *methods* to get to those results, are very much limited
<ELLIOTTCABLE>
ugh anyway dunno why I got on this side-track
<whitequark>
methods... *shrug*. you're writing this on a descendant of 8086. methods are irrelevant.
<purr>
¯\(º_o)/¯
<whitequark>
unfortunately.
<whitequark>
like, I'd be hugely happy if they *were* relevant, because that'd mean that a lot of shitty, inelegant, horrible solutions would die outright.
<whitequark>
but they aren't
<whitequark>
anyway, I'm done, go on with natives.
<ELLIOTTCABLE>
okies
<ELLIOTTCABLE>
idk, might be rather unresponsive.
<ELLIOTTCABLE>
want to go shoot things.
<whitequark>
huh.
<whitequark>
NO PENIS SHAPED FOOD
<ELLIOTTCABLE>
just, gughghtughtughtugh
<ELLIOTTCABLE>
don't want to be here, don't want to be doing this
<ELLIOTTCABLE>
so depressed.
jesusabdullah has joined #elliottcable
<whitequark>
do something else then? idk
<whitequark>
I'm not forcing you to write paws details
<ELLIOTTCABLE>
infra cut()(thing)(num) … empties the slot at that number …
<ELLIOTTCABLE>
nah, I want to get through them, I guess.
<ELLIOTTCABLE>
will only take me a moment to get to the interesting ones,
<ELLIOTTCABLE>
and then I'mma jet and, idk, play simcity, or watch tv, or take a shit. because Lyfe™.
<whitequark>
Lyfe?
<ELLIOTTCABLE>
was wrong about `empty void` above, has to be `empty()`.
<ELLIOTTCABLE>
obviously. I'm just dumb.
<ELLIOTTCABLE>
needs the caller, so it can return the new value.
<ELLIOTTCABLE>
`infra affix()(thing)(val)`, pushes the value onto the end of the list,
<ELLIOTTCABLE>
`infra unaffix()(thing)`, removes, and returns, the value on the end,
<ELLIOTTCABLE>
`infra prefix()(thing)(val)`, pushes the value onto the start of the list,
<ELLIOTTCABLE>
`infra unprefix()(thing)`, removes, and returns, the value at the start,
<ELLIOTTCABLE>
er, for those last two, as with everything else, they ignore the noughty, if you're using a noughty in your implementation.
* ELLIOTTCABLE
shrugs
<purr>
¯\(º_o)/¯
<whitequark>
(fyi: I am, until further discussion)
<whitequark>
(it makes sense, even if it's too raw.)
<ELLIOTTCABLE>
`infra compare()(a)(b)`: resumes the caller only if the two are object-identitcal
<ELLIOTTCABLE>
well, glowcoil was dead-set on it being a property, not available via an index
<whitequark>
I think it's fine for the time being and can be painlessly removed afterwards
<ELLIOTTCABLE>
okies
<whitequark>
there's some elegance in the current solution, I just think it's bad in the long run
<whitequark>
like Forth :p
<ELLIOTTCABLE>
opinions on Forth?
<ELLIOTTCABLE>
tell me later, it's on my radar to learn
<whitequark>
sure
<whitequark>
Forth is even simpler than the Paws Nucleus
<whitequark>
about 4 times simpler.
<glowcoil>
yeah "learning" forth will take you shorter than prolog
<ELLIOTTCABLE>
`infra clone()(thing)`: create a new Thing, and (shallow-)copy the metadata of an existing Thing, to it. Maintaining ownership.
<whitequark>
metadata?
<glowcoil>
it's not a thing you Learn, that's Factor
<ELLIOTTCABLE>
I think “learning” a language by reading a tutorial or a manual is goddamn dumb.
<ELLIOTTCABLE>
I only bother, if I have time to *write a thing* in it.
<ELLIOTTCABLE>
otherwise you've learned nothing and will immediately forget it. Or, at least, you will, if you're me.
<ELLIOTTCABLE>
oh, sorry, Factor is what I meant. I always confuse them.
<whitequark>
well, it makes sense if the language is rutty enough
<ELLIOTTCABLE>
rutty
<ELLIOTTCABLE>
did you just
<ELLIOTTCABLE>
oh my god i died
<whitequark>
what?
<ELLIOTTCABLE>
were you even here for those discussions!?
<ELLIOTTCABLE>
I don't recall that at all, I thought that was before your itme
<ELLIOTTCABLE>
time*
<whitequark>
it was
<whitequark>
but someone was kind enough to explain
<whitequark>
what "stuck in a rut" means
<ELLIOTTCABLE>
ahhhh cool
* whitequark
shrugs
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE>
yeah, Oases as a whole are important to me. This idea that we're stuck.
<whitequark>
anyway, I basically learned OCaml by reading RWO.
<ELLIOTTCABLE>
Although, less-so than it was four years ago, or whatever.
<ELLIOTTCABLE>
'cuz nowadays there's a very real, and very big, push towards functional languages …
<whitequark>
there's a few more tricks to it, but the basics were already there.
<glowcoil>
11:47:30 <+ELLIOTTCABLE> oh my god i died
<whitequark>
it *may* have been important that I read like a dozen papers about ML before :D
<whitequark>
so in retrospect you're right anyway
<whitequark>
and I have a special case here
<ELLIOTTCABLE>
and while I still find pure-functional boring (and in some cases, confusing, 'cuz I can't fucking understand Haskell), it's better than being stuck in some imperative, OO hell.
<whitequark>
wow, didn't expect from you
<whitequark>
I mean, Paws is an imperative, mutable, OO hell
<whitequark>
:p
<glowcoil>
well it's the kind of controlled mutability like clojure
<ELLIOTTCABLE>
I'm firmly of the belief that Paws itself, at least at a low level, is far from that.
<glowcoil>
and the ideal for the oo is really nice it hink
<glowcoil>
and the imperative is much cooler thanks to generatory things imo
<whitequark>
glowcoil: I'm slowly coming to agree that OO is basically good for nothing
<ELLIOTTCABLE>
I have very serious intentions to *turn* high-level Paws into something extremely familiar and OO-y and ‘boring,’
<ELLIOTTCABLE>
U/X reasons, and marketing reasons, and desires to change the world reasons,
<ELLIOTTCABLE>
but at a low level? nah. Paws is very little like the Rut languages.
<ELLIOTTCABLE>
The object-system is so non-existent as to be very Rut, for sure, but that's it.
<glowcoil>
whitequark: i really really like the emphasis on formally defining the surface area between components
<glowcoil>
whitequark: and i believe that specifically the thing that's called oo enforces way more than just something cool like that
<whitequark>
glowcoil: so far I'm not sold that it will even work in practice
<ELLIOTTCABLE>
`infra adopt()(from)(to)`: wipe out the metadata of `to`, entirely; replace with shallow-copied metadata from `from`. does not return.
<whitequark>
the problem with OO is, well, mutable, interdependent state
<glowcoil>
whitequark: the point is that you make it *not* interdependent
<whitequark>
ELLIOTTCABLE: wait, clone. you said only metadata?
<whitequark>
so, only 0th index?
<whitequark>
or what?
<ELLIOTTCABLE>
er, sorry
<whitequark>
wtf is metadata.
<ELLIOTTCABLE>
sorry sorry sorry
<ELLIOTTCABLE>
distracted, so mixing up literally three different sets of terminology that Paws has had over the years
<ELLIOTTCABLE>
>':
<ELLIOTTCABLE>
“Object-data.”
<ELLIOTTCABLE>
i.e. the list entries.
<whitequark>
so, just a shallow copy.
<whitequark>
ok.
<ELLIOTTCABLE>
well, yes, but the purpose is that you can shallow-copy from one “type” to another.
<ELLIOTTCABLE>
i.e. replace the object-y data on an Execution with that from an Object
<ELLIOTTCABLE>
because clone() creates a new Object.
<ELLIOTTCABLE>
anyway.
<ELLIOTTCABLE>
re: metadata, FYI,
<ELLIOTTCABLE>
the, as we've been calling it, ‘silly terminology’ (user-facing naming) of Object is ‘Thing.’
<ELLIOTTCABLE>
Basically, all types of anything are Things. And “data” is the hidden stuff, that you can't manipulate from within Paws.
<whitequark>
what.
<ELLIOTTCABLE>
instead, Paws is designed to manipulate *metadata about data*. i.e. the object-y stuff.
<whitequark>
I didn't understood a single sentence from above
<ELLIOTTCABLE>
(or modify, or control) the data itself at any point.
<ELLIOTTCABLE>
you wrap data up in bundles (Things), such as wrapping code-data up in an Execution, or dog-data up in a Dog; and then you assign metadata to it and manipulate that metadata in the Paws-world. You use that metadata to reason *about* the data in question (the dog), and to conditionally pass it around, or to make decisions about it, but you don't actually see
<glowcoil>
whitequark: it's a weird distinction ELLIOTTCABLE is making
<ELLIOTTCABLE>
The only way you can modify data (as opposed to metadata) is through discrete, individual, pre-defined operations that a Paws implementation provides.
<glowcoil>
whitequark: say you can only access a string via like, get-charcter and concatenate methods, then the string is the "data" and you can't touch it except via provided methods
<glowcoil>
whitequark: so all of your own properties are "metadata"
<ELLIOTTCABLE>
For instance, a database exposing the results of a sequel query.
<glowcoil>
idk why it's necessary
<ELLIOTTCABLE>
it's not. I'm done. Sorry.
<whitequark>
hm?
<ELLIOTTCABLE>
whitequark: perhaps it answers your confusion if I tell you that the original name for what you've been seeing as the “data-graph,”
<ELLIOTTCABLE>
is the “metadata-graph.”
<ELLIOTTCABLE>
It's graph of metadata laid down over other data.
<whitequark>
ELLIOTTCABLE: well, okay, but I don't understand why natives must have more expressive power than paws
<whitequark>
that sounds counterproductive
<ELLIOTTCABLE>
it's not that they *must*.
<whitequark>
like, since you like abstraction so much
<whitequark>
and that's good
<whitequark>
you'd want to implement as much of paws as possible in paws
<ELLIOTTCABLE>
there's no reason something can't “shatter” some Big chunk of data, into lots of small chunks of data, and then embed those in multiple places in the data-graph,
<ELLIOTTCABLE>
thus moving some of the data's structure into *introspectable* structure,
<ELLIOTTCABLE>
but, still, always, *the only stuff that actually exists in an introspectable way*, is the structure itself. The relationships. That graph.
<ELLIOTTCABLE>
To put it another way,
<whitequark>
I'm even more confused now
<ELLIOTTCABLE>
I'm sorry.
<ELLIOTTCABLE>
done.
<ELLIOTTCABLE>
it's unimportant, as glowcoil said.
<whitequark>
ok
<ELLIOTTCABLE>
just some weird way that elliott thinks about things.