<purr\Paws>
primitives.js/Master 9367d58 elliottcable: (- meta doc) Fix a comment for the new bracket-syntax
Sgeo has quit [Ping timeout: 244 seconds]
Sgeo has joined #elliottcable
eligrey has joined #elliottcable
<devyn>
ELLIOTTCABLE: haha really?
<ELLIOTTCABLE>
"It was not too long ago (March 4th, 2012) that a public key security vulnerability at GitHub was exploited by a Russian man named Egor Homakov, allowing him to successfully commit to the master branch of the Ruby on Rails framework repository hosted on GitHub. Oops."
<devyn>
cloudhead: eh the only really big problem I've been having is with the compiler still thinking things are borrowed even after I drop() the borrowed references... it's rather annoying and leads to some unnecessary scope-encapsulation
<devyn>
cloudhead: other than that it's pretty nice to write
<Cheery>
feeling good.
<ELLIOTTCABLE>
Cheery: hi!
<devyn>
ELLIOTTCABLE: that's great hahaha
<Cheery>
hi ELLIOTTCABLE
<ELLIOTTCABLE>
Cheery: we don't know eachother very well, but you've been in here long enough that I think it's time. :0
<devyn>
ELLIOTTCABLE: I'm glad they left that commit in there; it's so funny
<ELLIOTTCABLE>
I forget, where'd you say you were from? south america?
<Cheery>
finland
<ELLIOTTCABLE>
devyn: I'm glad they left the commit in there, it'd be some sneaky revisionist shit to remove it.
<ELLIOTTCABLE>
devyn: pushing brackets in tee-minus-, uh, ten or so.
<ELLIOTTCABLE>
building gpg2. new computer and all that. ugh.
<devyn>
oh, right, so is () -> [] the only change?
<ELLIOTTCABLE>
you're gonna have to walk me through your API in rust-non-initiate terms soon, so I can try my hand at writing some really simple aliens (=
<ELLIOTTCABLE>
yep.
<devyn>
ok
<ELLIOTTCABLE>
Paws.js v4
<ELLIOTTCABLE>
officially spec-incompliant :P
<ELLIOTTCABLE>
not going to change the spec, mostly because I hate the spec so much.
<devyn>
haha
<ELLIOTTCABLE>
need to, need to, need to, need to write a new spec.
<devyn>
yes you do
<ELLIOTTCABLE>
but it was such a grueling operation last time … and I've no guarantee that I'll be any better this time around … ugh.
<devyn>
absolutely
<devyn>
it will be less grueling if you do it properly lol
<purr>
lol
<ELLIOTTCABLE>
I'm kinda putting it off until we nail down the unitary semantics.
<ELLIOTTCABLE>
well idk how to do it properly ಠ_ಠ
<ELLIOTTCABLE>
opsemantics are *not* going to be fun for Paws
<devyn>
okay there's one thing I want to nail down *right now*
<ELLIOTTCABLE>
because thats simply not the way *I* think about Paws. I may be the designer of the whole thing, but I still think as an implementer most of the time, which is really messy when you think about it
<ELLIOTTCABLE>
need to actually, well, write more goddamn paws, to be able to "think in paws" better. opsem is gonna be hard before then.
<devyn>
and I've brought it up before
<ELLIOTTCABLE>
but I definitely want to write from a user-point-of-view this time. ugh.
<devyn>
`implementation` and `infrastructure` really have to be able to create new aliens instead of just being plain old Empties
<ELLIOTTCABLE>
whyzat
<ELLIOTTCABLE>
sorry, yah, I never replied when you brought this up last time. completely forgot.
<ELLIOTTCABLE>
I'm not convinced that they're currently the way to do it at all *anyway*.
<devyn>
ELLIOTTCABLE: re: infra/impl., I feel like they should be specified such that the only defined behavior is through their receiver, so then we can create receivers that clone the aliens or even just bypass lookups altogether by not really having members at all
<devyn>
Cheery: neat!
<devyn>
Cheery: that's a cool way to set goals
<Cheery>
I had to.
<Cheery>
otherwise I'm starting to forget where I was planning to get this thing to.
<devyn>
haha
<Cheery>
I'll get more milestones later, but I'll try get this one through before introducing the others.
<Cheery>
zzz...
<ELLIOTTCABLE>
devyn: huh?
<ELLIOTTCABLE>
oh, mis-read
<ELLIOTTCABLE>
thought you were saying `infrastructure_get` instead of `infrastructure <combine> get`
<ELLIOTTCABLE>
I'm thinking of putting both below “system”, by the way.
<ELLIOTTCABLE>
`system infrastructure get` and etc...; `system implementation console print`
<ELLIOTTCABLE>
yes, I know, unabstracted code just got Even Longer™, but meh.
<ELLIOTTCABLE>
I like that, Cheery
<ELLIOTTCABLE>
I hate having particular tasks or ideas as targets for specific *versions*.
<ELLIOTTCABLE>
yet another reason I'm pro-programmatic-versioning.
<ELLIOTTCABLE>
all that is is *stifle* development progress.
<ELLIOTTCABLE>
"well, we need to complete v2.0 and get that out to users before we can worry about that"
<ELLIOTTCABLE>
then v2.0 takes literally ten years
<ELLIOTTCABLE>
and even then, only half the userbase switches over to it, because it's got some crap that changes how strings work in a way that somebody didn't like, and wrote a very convincing blog-post about.
<ELLIOTTCABLE>
really hard for some vitrolic user to convince half the userbase to stick to a previous version when it's "patch 2766".
<ELLIOTTCABLE>
won't get half the userbase sticking to "patch 2766" for years.
<ELLIOTTCABLE>
nice to, instead, talk about the goals in-and-of-themselves.
<ELLIOTTCABLE>
if Goal A turns out to be difficult to achieve, then v2.1 can achieve Goal B instead, and we can call Goal A v2.2
<ELLIOTTCABLE>
because we made no promises to anyone about v2.2 == Goal A being availabl .
<ELLIOTTCABLE>
</random rant>
<ELLIOTTCABLE>
devyn: yeah, that sounds completely reasonable.
<ELLIOTTCABLE>
this is one of those things where it doesn't sound remotely controversial, and is probably an issue of wording *at worst*.
<ELLIOTTCABLE>
so just implement it that way if it makes you happy, and this will be the perfect time to see how, if at all, that actually affects our code.
<ELLIOTTCABLE>
as long as those receivers are chained, so it's easy to do something like move `system infrastructure execution` into locals as `exe`,
<ELLIOTTCABLE>
meaning the bootstrapping abstraction code like those examples will actually be mildly readable,
<ELLIOTTCABLE>
then I'm happy.
<devyn>
yep, should be able to, but it does mean if you take `system infrastructure execution branch` it will be a specific instance of that and you won't be able to call it multiple times
<devyn>
so you'd have to take the container, or clone them yourself
<ELLIOTTCABLE>
wait
<ELLIOTTCABLE>
"won't be able to call it multiple times"
<ELLIOTTCABLE>
that's *always* how that works …
<devyn>
I know
<ELLIOTTCABLE>
unless you implemented the looping thing for aliens, which is probably a terrible idea, because completion is important
<devyn>
yes
<ELLIOTTCABLE>
unless I'm very confused, all you're suggesting is that the receiver for procedure-bags automatically clone
<ELLIOTTCABLE>
right?
<devyn>
and CallPatternRoutine-helper aliens do have completion
<devyn>
so it's all good
<devyn>
no, you're not confused
<ELLIOTTCABLE>
okay cool
<ELLIOTTCABLE>
yeah, that seems like an unarguable improvement
<ELLIOTTCABLE>
it doesn't complicate the language, and saves the earlier abstraction levels having to constantly clone aliens if they need to stage() instead of call-pattern
<ELLIOTTCABLE>
I will say this, though:
<ELLIOTTCABLE>
even if it's rarely used, I think you *should* implement a 'root' for all the clones. On the off-chance I ever add a semantic for retrieving the parents of clones.
<ELLIOTTCABLE>
at the moment, there's explicitly no re-winding of history (i.e. getting access to an earlier code-path that wasn't intentionally branched and saved at that point), because I want users exercising time-travel to do that (because that achieves the same goal, but also adds side-effect safety),
<ELLIOTTCABLE>
but I'm not dead-set against it
<devyn>
ELLIOTTCABLE: sure, I could just sent them up as plain-old Empties with members and everything, just with custom alien receivers … though, this does open the door for optimization and I *could* add a `namespace` nuketype or something that stores things in a far more efficient binary search tree or something
<ELLIOTTCABLE>
isn't it possible to do both ways?
<devyn>
yep yep
<ELLIOTTCABLE>
don't worry about the legacy way for now, just make sure your optimizations leave you open to doing so?
<ELLIOTTCABLE>
i.e. "Don't optimize in a way that precludes accessing the data through the Thing receiver."
<ELLIOTTCABLE>
by the way, it's really not pertinent to anything ever anywhere, but there's no 'empty' type in the spec :P
<ELLIOTTCABLE>
empty() is just a procedure for creating a Thing type
<devyn>
oh really? oops :p
<devyn>
I could rename that
<devyn>
to Thing
<cloudhead>
hello
<cloudhead>
ELLIOTTCABLE: ^
<devyn>
also BST-optimization while leaving things open to the Thing receiver could get slightly complicated, so maybe I'll just not do that for now
<devyn>
and leave them as Things with custom receivers attached
<ELLIOTTCABLE>
cloudhead: <3
<cloudhead>
<3*
<ELLIOTTCABLE>
devyn: there should be no code depending on them being Thing-ish anytime soon.
<cloudhead>
(shiny heart)
<cloudhead>
I went through Paws.rs
<ELLIOTTCABLE>
I'm just not convinced there's *no* use-cases where that's necessary, so I don't want to design/spec the system for it to be impossible.
<cloudhead>
pretty nice code
<ELLIOTTCABLE>
so, yes, go do it the fast way. <3
<ELLIOTTCABLE>
fun fact:
<ELLIOTTCABLE>
remember, this shit is going to be *frozen*.
<ELLIOTTCABLE>
that means real-life code isn't going to be running functions that do [combine <infrastructure>, "execution"] very often, if at all.
<ELLIOTTCABLE>
instead, the person writing the abstractions will be "compiling" the result by freezing it, which will ALMOST CERTAINLY re-assign the `execution` bag to a local
<ELLIOTTCABLE>
which means in every-day codes' data-space, it'll be a single combination to receive the execution (i.e. invoke your generative receiver)
<devyn>
cloudhead: thanks. this has been the absolute perfect way to learn Rust just because of how much dynamic/advanced things it requires haha
<cloudhead>
yea for sure
<ELLIOTTCABLE>
so, pretty sure my gpg keys are Gone™.
<ELLIOTTCABLE>
pretty pissed.
<cloudhead>
the stuff rust has the most trouble with in my experience is shared mutable node graphs
<cloudhead>
and that's pretty much what you're doing
<ELLIOTTCABLE>
my setup was to symlink my secring.gpg file on my USBkey, and share it between machines/environments that way
<cloudhead>
you have to wrap things in a lot of types
<ELLIOTTCABLE>
but it turns out, secring.gpg is apparently useless without the rest of the contents of ~/.gnupg
<cloudhead>
Rc<RefCell<Node>> / Arc<Mutex<Node>>
<cloudhead>
which is the rough part
<ELLIOTTCABLE>
the rest of which I did not save, as I assumed the public-keys could be re-generated from the private-keys, which I assumed were stored in secring
<devyn>
yep, but I created nice abstractions around those so it's not so bad
<cloudhead>
a lot of low-level leakage into domain logic
<ELLIOTTCABLE>
so idk how gnupg works, but I can't figure out a way to retreive my keys from this |=
<cloudhead>
yea I saw, in the object module
<cloudhead>
that's the way to go
<devyn>
I'm especially proud of TypedRefGuard -- it means you can write type-safe functions that require a certain type of object and offload the run-time typechecking off to the caller
<cloudhead>
I've had problems with stuff like returning a mutable reference out of a RefCell'ed Vec
<cloudhead>
like RefCell<Vec<Node>> - you can't return a mutable Node out of that
<cloudhead>
should be the same with Mutex<Vec<Node>>
<cloudhead>
ah I see
<devyn>
yep, and it makes sense because if you were able to do that it could break the immutable-borrow guarantee
<cloudhead>
you need to get your types right, and that's just the types of pointers
<cloudhead>
yea, it all makes sense in the end, I just find it fairly inflexible
<cloudhead>
or fairly heavy, cognitively
<cloudhead>
there's a lot more to think about
<cloudhead>
in that way it almost feels lower level than C
<devyn>
it's annoying, yes, but you get used to it; there's really no way around making sure that the RefCell has been borrowed from first
<cloudhead>
yea
<devyn>
and in the end this is better… it may be a pain, but it means your code is definitely safe
<devyn>
which is worth it IMO
<cloudhead>
yea for sure
<cloudhead>
but then you really have to need the performance
<cloudhead>
because I can write safe code in haskell too
<cloudhead>
so the tradeoff is in the time investment to get the types right
<devyn>
sure, yes, Rust is for when you need high performance, safe code
<cloudhead>
yea, exactly
<cloudhead>
which puts it in a unique position
<devyn>
well I think it could easily replace C++ just because safety is so hard to get right in that
<cloudhead>
yea, probably
<devyn>
it's also just way nicer to work with
<devyn>
and more regular
<devyn>
lol
<purr>
lol
<cloudhead>
it is
<cloudhead>
the problem is it forces safety on you from day 1
<devyn>
which isn't necessarily a problem :p
<cloudhead>
in C++ you can start to sketch things out and write unsafe code which "works"
<cloudhead>
ie doesn't segfault
<cloudhead>
but isn't compile-time verifyable
<cloudhead>
verifiable
<cloudhead>
and later on you can work on making the code safer
<cloudhead>
in rust you have to buy in
<devyn>
yeah, but then going back and making that code safe is a pain in the arse
<cloudhead>
which can slow you down initially
<cloudhead>
yea
<cloudhead>
for sure
<cloudhead>
it's kind of more of a #yolo style of development
<devyn>
and the compiler can't really help you very much with that
<cloudhead>
nope
<cloudhead>
but you can write working code
<cloudhead>
you may run into some segfaults on the way
<cloudhead>
;p
<devyn>
haha
<cloudhead>
for certain problem domains, safety is a priority
<cloudhead>
others not
<cloudhead>
for a language runtime, definitely
<cloudhead>
a game, maybe not
<cloudhead>
so yea, pick your tradeoffs
<devyn>
nah, I think it's good for any large project that needs performance, including games
<cloudhead>
but I think/hope rust will evolve and become easier to use as it reaches 1.0
<devyn>
lots of games have bugs related to safety and bounds checks and stuff
<cloudhead>
I don't know, it's a lot of work just to figure out the type of pointers/containers you will use
<cloudhead>
yea..
<cloudhead>
and fulfilling all the borrow rules
<cloudhead>
etc
<cloudhead>
it's very strict
<cloudhead>
I think next time I use it I'll explore a more functional approach
<devyn>
yes, but the memory management model is so much better for games since you really need explicit memory management there, and Rust makes explicit memory management more implicit
<cloudhead>
right
<cloudhead>
I don't know how much copying is acceptable in rust
<cloudhead>
I tried to share everything, like I'd do in C
<cloudhead>
but that makes things complicated
<cloudhead>
everything ends up in an Rc<RefCell<>>
<cloudhead>
and then you have
<cloudhead>
foo.borrow_mut() all over the place
<cloudhead>
which is pretty nasty
<cloudhead>
you can hide it in a Deref implementation
<cloudhead>
but then that's extra boilerplate
<cloudhead>
and typers
<cloudhead>
types
<cloudhead>
that are only there to circumvent
<devyn>
I don't think you can hide Rc<RefCell<>> with Deref
<cloudhead>
hm maybe not
<cloudhead>
I didn't try
<cloudhead>
just imagined it might be possible
<devyn>
I think I did try, haha
<cloudhead>
heh
<devyn>
but you can't for the same reason you can't with a Mutex
<devyn>
you have to hold the borrow somewhere
<cloudhead>
ah yes
<cloudhead>
it can't escape the scope
<cloudhead>
and you have Ref/MutexGuard
<cloudhead>
which means it's not fully transparent
<cloudhead>
it's interesting
<cloudhead>
maybe a more powerful type system would help here
<cloudhead>
I feel like it would benefit the language a lot
<cloudhead>
because it's so strict, like haskell
<cloudhead>
same goes for the try!() macro
<cloudhead>
it's not bad but..
<devyn>
well I think this particular case could actually be solved with some better lifetime tracking
<cloudhead>
hmm yes maybe
<devyn>
requiring that the Guard's lifetime goes along with what you borrow from it
<devyn>
somehow
<cloudhead>
that's one area which will improve for sure though
<cloudhead>
yea
<cloudhead>
it's an interesting language
<cloudhead>
I'm going to give it some more time before I dive into it again
<ELLIOTTCABLE>
recovered it!
<devyn>
not a bad idea
<ELLIOTTCABLE>
had to disassemble the packets of the gpg file.
<ELLIOTTCABLE>
that was a mess.
<ELLIOTTCABLE>
hi, all
<cloudhead>
hi hihi hihi
<devyn>
migrating 0.10 → 0.11 for me didn't take as much time as I thought it would though
<cloudhead>
hm
<cloudhead>
mainly
<devyn>
probably like a couple of hours
<cloudhead>
~ -> Box
<cloudhead>
yea
<devyn>
yeah, that and the removal of 'priv'
<ELLIOTTCABLE>
3:21 PM <+devyn> sure, yes, Rust is for when you need high performance, safe code
<cloudhead>
there's already a lot of line-noise in rust
<devyn>
yeah, that was one of the things I really didn't like about Rust when I first saw it
<cloudhead>
with the lifetime specifier
<cloudhead>
s
<devyn>
I didn't even touch it until after they removed @
<cloudhead>
hehe
<cloudhead>
ELLIOTTCABLE: hehe
<devyn>
lifetime specifiers aren't that noisy compared to ~ and @ IMO
<ELLIOTTCABLE>
that time, I realized that devyn could actually be building a *real* Paws implementation.
<ELLIOTTCABLE>
that's … terrifying
<cloudhead>
hahaha
<devyn>
haha
<cloudhead>
devyn: well, mainly in the function prototypes
<cloudhead>
they are noisy
<cloudhead>
function type decls
<ELLIOTTCABLE>
like, this could be a real thing, that real people could use. Every time I talk about Paws to somebody, and convince them to try my work out, they'll be installing Paws.rs, because it's fast and safe and a Real Thing, and then actually use my work.
<ELLIOTTCABLE>
or something. idk words. just, suddenly feels'd.
oldskirt has joined #elliottcable
<devyn>
cloudhead: yeah but they only show up there, and not every function needs them anyway. they're usually pretty clear once you know what they are, whereas ~ and @ are easy to miss and all over the place
<cloudhead>
true
<devyn>
ELLIOTTCABLE: <3 yes, I'm hoping Paws.rs will be the first non-toy Paws impl
<cloudhead>
ELLIOTTCABLE: yea, you're lucky you have someone doing the real work for you :D
<ELLIOTTCABLE>
cloudhead: oh die.
<ELLIOTTCABLE>
:P
<cloudhead>
while you sit in your ivory tower :D
<devyn>
ELLIOTTCABLE: I've been putting so much work into documentation for that reason :p
<ELLIOTTCABLE>
I LIKE MY IVORY TOWER
<devyn>
and unit testing
<cloudhead>
I like it too
<ELLIOTTCABLE>
still convinced that implementation is not the important part, or even *an* important part, for the first ten years† of a language's existence.
<ELLIOTTCABLE>
†: arbitrary number
<ELLIOTTCABLE>
I *will* say this: being familiar with, or even expert in, language implementation … is quickly turning out to be almost a requirement.
<ELLIOTTCABLE>
I'm extremely hindered, at the very least (and that's assuming that this succeeds, and thus I wasn't outright "completely incapable of"), by my lack of previous experience implementing real languages.
<ELLIOTTCABLE>
Cheery's got this right. If you don't know this shit, write stupid rut languages to learn about language implementation. It's *devilishly* hard to make the right decisions about language-design stuff in a vacuum of knowledge about how that will impact implementers in the future.
<ELLIOTTCABLE>
I *almost* wrote my own mostly-Ruby, a long, long time ago. Something like M.A.C.'s tinyruby.
<devyn>
yeah, but on the plus side, you've had glowcoil and I to make sure you think this all through properly
<ELLIOTTCABLE>
yeah.
<ELLIOTTCABLE>
fucking invaluable. /=
<ELLIOTTCABLE>
honestly, more alexgordon than anything.
<ELLIOTTCABLE>
glowcoil was far more useful inside my ivory tower,
<cloudhead>
you need *an* implementation though
<cloudhead>
or you'll never know if your ideas are usable
<alexgordon>
?
<alexgordon>
you rang?
<ELLIOTTCABLE>
but for years, alexgordon was the dude camping out down on my lawn, yelling cusswords up our arrowslits whenever we were designing something stupid.
<devyn>
well yeah alexgordon is making a real™ rut lang too
<ELLIOTTCABLE>
cloudhead: oh, yes, but the actual implementation should definitely be a naive, clean one.
<alexgordon>
devyn: fuck yeah
<ELLIOTTCABLE>
that's the lesson I learned after making the Paws.c and µpaws mistakes.
<alexgordon>
-best rut lang
<purr>
RUTLANG IS BESTLANG
<devyn>
-best alexgorden
<purr>
ALEXGORDEN IS BESTGORDEN
<devyn>
hahaha
<ELLIOTTCABLE>
A) don't try to make a preformant implementation out the door, and B) don't try and take it easy out the door, avoding documentation, correctness, code cleanliness …
<cloudhead>
yea
<ELLIOTTCABLE>
Lua-style implementations are perfect for during-langauge-design work.
<alexgordon>
devyn: gordOn
<cloudhead>
well, the main thing is you want to be able to "extend" it or experiment with changes easily
<ELLIOTTCABLE>
Well-documented, extremely simple code *built* to be read, with a clean and stable API built to be embedded
<alexgordon>
-best mast urbation
<ELLIOTTCABLE>
cloudhead: yes, exactly.
<alexgordon>
what gives purr ?
<purr>
MASTURBATION IS BESTURBATION
<alexgordon>
ah
<ELLIOTTCABLE>
that's my point: the "embeddable", simple implementation, with good documentation, is the easiest to come back and change for yourself.
<devyn>
-best alexgordin
<purr>
ALEXGORDIN IS BESTIN
<ELLIOTTCABLE>
or, to flip that on its head and nail the issue … it provides the *least* cognitive weight to every change you make.
<ELLIOTTCABLE>
because the very very very last thing you want is your own implementation subconsciously holding back your design. "Ugh, that'd be difficult to re-write, maybe I should just leave it as it is", instead of fixing that subtle design flaw that will hold back your language forever.
<cloudhead>
pretty much.
purr has quit [Remote host closed the connection]
purr has joined #elliottcable
<ELLIOTTCABLE>
-best alexgordon
<purr>
ALEXGORDON IS ALREADY BEST ALEXGORDON
<ELLIOTTCABLE>
<'3
<devyn>
haha
<devyn>
-best test
<purr>
TEST IS BESTTEST
<devyn>
-best alexgordon
<purr>
ALEXGORDON IS BESTGORDON
<devyn>
:)
<devyn>
-best alexgordon
<purr>
ALEXGORDON IS ALREADY BEST ALEXGORDON
<devyn>
-best alexgordon
<purr>
ALEXGORDON IS BESTGORDON
<alexgordon>
-best devyn iality
<purr>
DEVYNIALITY IS BESTIALITY
yorick has quit [Remote host closed the connection]