<jtojnar>
they use urls on IPFS for importing functions
<boxofrox>
ok. I think I'd need some new vim plugins to help with that function completion. I'm slow enough writing programs because I can't quite remember exact function names, let alone with hashes added.
<jtojnar>
I was also thinking about this few weeks ago, but just today I recalled dhall does this
<infinisil>
Yeah something like that
<infinisil>
This would of course be quiet unergonomic
<infinisil>
Which is why we need a proper AST editor for that
<infinisil>
Text isn't good enough
<jtojnar>
👍 you are reading my thoughts
<infinisil>
With text you get the problem of "I wanna use this and this and this function, but I'm too lazy to get the hashes, so I'll just use this library which has all functions in it"
<infinisil>
There isn't really anything that says functions need to stay together in a library, I don't need to import 100 functions just because I need one of them
<boxofrox>
And because a typical compiled language relies on dynamic libraries to provide those functions, tree shaking or some such is out. You'd have to statically compile to throw out unused functions, I think.
<infinisil>
Probably, I don't even wanna think about non-compiled languages though, ugh
<infinisil>
And I need myself static type checking, I've never had a good experience with a language that didn't have it
<jtojnar>
though with immutable dependency references, you have the same problems as with vendoring
<infinisil>
jtojnar: which are?
<jtojnar>
multiple versions of libraries on the system
<jtojnar>
and outdated references
<infinisil>
Why are multiple versions a problem?
<infinisil>
(I'm assuming you're talking about my idea)
<boxofrox>
given the hash in the function name, I'd expect multiple "versions" of same function to run in the same program space.
<infinisil>
Yeah, but with a hash identifying the function, there isn't any meaning to "the same function", there are no same functions
<boxofrox>
agreed
<infinisil>
But yeah there is the problem of wanting to update your functions
<jtojnar>
multiple versions will take a lot of space
<infinisil>
My "vision" of the *ultimate* programming language would solve this and another bunch of problems
<jtojnar>
imagine npm but without the ability to deduplicate the dependency tree (no version resolution)
<infinisil>
Hold on, I hope I can find this
<boxofrox>
One headache I can almost foresee (and maybe this remedied by tooling) is I have a set of functions that interact with a particular data structure. If that datastructure changes in a function that allocates an instance, then all functions using that datastructure need to update. Would user-defined data types also be hashed/versioned?
<infinisil>
Oh it got taken down, but it was something like a package using `isOdd` of the package isodd, which depended on like 10 more dependencies
<jtojnar>
boxofrox: yep, dhall supports that
<infinisil>
Yeah datatypes would have the same model as functions I'd say
<infinisil>
Then you could also create functions to convert from an old datatype to a new one
<boxofrox>
I'm intrigued.
<infinisil>
There's a whole bunch of stuff that would work well with this model
<jtojnar>
You can import types, too. For example, we can change our ./bar file to:
<jtojnar>
Dhall is very cool, it would be neat if Haskell and Dhall had a baby
<jtojnar>
infinisil: one possible way to avoid the need to specify exact dependencies would be having strong enough type system to be able to describe the function contracts precisely
<jtojnar>
but then you would have the same problem with function contracts
<infinisil>
Yes! That would be the follow up!
<jtojnar>
I think Dhall supports all this today
<infinisil>
You'd need a strong enough type system and universally used data definitions
<infinisil>
I'm thinking of formal proofs and stuff
<infinisil>
E.g. you say I need a function that takes a list and returns the first element
Lisanna has joined #nixos-chat
<jtojnar>
hmm, I thought Dhall had a little more advanced type system
<infinisil>
Aka `Vect (S k) a -> a` (but more precise even)
<infinisil>
Then the language looks for an implementation
<infinisil>
And you can optionally give your own implementation (and have to if there isn't one already)
<jtojnar>
but it would not really make sense, since it aims to be a configuration language
<infinisil>
Hmm I guess
jD91mZM2 has joined #nixos-chat
drakonis has joined #nixos-chat
jtojnar has quit [Remote host closed the connection]
Sonarpulse has quit [Ping timeout: 256 seconds]
jtojnar has joined #nixos-chat
Sonarpulse has joined #nixos-chat
jD91mZM2 has quit [Quit: WeeChat 2.0]
balsoft has joined #nixos-chat
MichaelRaskin has joined #nixos-chat
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-chat
drakonis has quit [Remote host closed the connection]
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
balsoft has quit [Quit: balsoft]
infinisil has joined #nixos-chat
balsoft has joined #nixos-chat
balsoft has quit [Quit: balsoft]
balsoft has joined #nixos-chat
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-chat
balsoft has quit [Read error: Connection reset by peer]
balsoft has joined #nixos-chat
balsoft has quit [Remote host closed the connection]
<infinisil>
sphalerit: The setting/unsetting of readonly is very simple and transparent
<sphalerite>
so would this tool only be for nixops state files, or..?
<infinisil>
Everytime you wanna switch from system A to B you'd tell it to update B's latest state to the one of A and make it writable
<infinisil>
Nah this would work for any files
<infinisil>
I'd use this for all my syncing
balsoft has joined #nixos-chat
<sphalerite>
completely unrelated, a pigeon found its way into the server room I take care of today
<sphalerite>
it wasn't very pleased about it, especially when I came in there and it couldn't find its way out
<infinisil>
Aw poor guy
<sphalerite>
managed to catch it and let it out the window in the end though