These are chat archives for unisonweb/unison

3rd
Oct 2016
Paul Chiusano
@pchiusano
Oct 03 2016 14:30
Paul Chiusano
@pchiusano
Oct 03 2016 17:52
just pushed fix for that interpreter performance bug… speed has improved from “I could execute this program on pen and paper faster than this” to merely “embarassingly slow for modern computers"
:)
sfultong
@sfultong
Oct 03 2016 17:53
ah, excellent
Paul Chiusano
@pchiusano
Oct 03 2016 17:53
am going to try writing the crawler and the search engine main now
Tim McIver
@tmciver
Oct 03 2016 18:24
@pchiusano That's great! Sorry I missed the scrum. I have a cold and slept the morning away.
Paul Chiusano
@pchiusano
Oct 03 2016 19:02
@tmciver np
Arya Irani
@aryairani
Oct 03 2016 19:45
@pchiusano So the definition names only matter during editing
Paul Chiusano
@pchiusano
Oct 03 2016 19:45
can you clarify what you mean by that
before i answer
@refried
Arya Irani
@aryairani
Oct 03 2016 19:46
Yes
eventually
So there's this choice "allow ambiguity — dependents will need to disambiguate via hash"
Paul Chiusano
@pchiusano
Oct 03 2016 19:49
yes
Arya Irani
@aryairani
Oct 03 2016 19:49
I may disambiguate via hash prefix today in a way that wouldn't necessarily disambiguate tomorrow (because some other hashes have been added)
Paul Chiusano
@pchiusano
Oct 03 2016 19:49
you mean if you just include the first few hash characters
like foo#f8asdfj
Arya Irani
@aryairani
Oct 03 2016 19:49
Yeah, some prefix.
Paul Chiusano
@pchiusano
Oct 03 2016 19:50
so, that will be used to disambiguate at the time you do unison add on some scratch file
Arya Irani
@aryairani
Oct 03 2016 19:50
Yeah
Paul Chiusano
@pchiusano
Oct 03 2016 19:50
after that, the code is slurped up into the codebase and the scratch file deleted
Arya Irani
@aryairani
Oct 03 2016 19:51
But if you edit that file again, it'll reference foo#f8asdfj still even though that might not be unambiguous anymore. But it's ok because you just have to disambiguate again when you unison add next.
Paul Chiusano
@pchiusano
Oct 03 2016 19:51
presumably if you do unison view, it should always produce a rendering of the code which could be passed to unison add and require no disambiguation (that is - it adds as many characters of the hash as are required to disambiguate names)
the scratch file is deleted after a unison add
Arya Irani
@aryairani
Oct 03 2016 19:52
sorry I mean if you edit that definition again
Paul Chiusano
@pchiusano
Oct 03 2016 19:53
yeah, if the hash prefix + name is no longer unique, you’ll just have to supply more of the hash
or else use a different name to refer to that hash - no real reason you can’t have multiple names for the same hash
i look forward to this eliminating pointless bikeshedding over names
:)
there’s no need to reach universal agreement on The One True Name for any definition
sfultong
@sfultong
Oct 03 2016 19:55
so will unison view make up random names for hashes?
Arya Irani
@aryairani
Oct 03 2016 19:55
So is that string "foo#f8asdfj" getting stored somewhere with the definition of its caller,
or does it store "foo" and #f8asdfjfullhash
or does it just store #f8asdfjfullhash
or "foo#f8asdfj" AND #f8asdfjfullhash
Paul Chiusano
@pchiusano
Oct 03 2016 19:56
@sfultong no, unison view will pick one of the names that is given for that hash - if the name isn’t unique (other things have that hash), it will show some prefix of the hash appended to the name
the only thing that is ever stored in the codebase is the hashes
separate from the hashes, we have some mapping from hash to name(s)
Arya Irani
@aryairani
Oct 03 2016 19:57
Yeah, where's that.
Paul Chiusano
@pchiusano
Oct 03 2016 19:57
in the codebase directory
sorry, I should have said, the only thing that is ever stored in the SYNTAX TREE
sfultong
@sfultong
Oct 03 2016 19:58
ok, that sounds pretty good
Arya Irani
@aryairani
Oct 03 2016 19:58
just checking: in the syntax tree or is the syntax tree
sfultong
@sfultong
Oct 03 2016 19:58
what if your codebase directory doesn't contain a name for a given hash?
Paul Chiusano
@pchiusano
Oct 03 2016 19:59
@refried in
Arya Irani
@aryairani
Oct 03 2016 19:59
ok
Paul Chiusano
@pchiusano
Oct 03 2016 19:59
what I am trying to say is: names never appear in the syntax tree
and the codebase stores representations of the syntax tree, so it does not store names
Arya Irani
@aryairani
Oct 03 2016 19:59
Right. So where all is that metadata like the name the author first used stored?
And does it get transferred from person to person?
Paul Chiusano
@pchiusano
Oct 03 2016 20:00
in the metadata directory
here’s what the codebase/ directory looks like
Arya Irani
@aryairani
Oct 03 2016 20:01
ok I just found the bit about .names files. So you can share that with people.
Arya Irani
@aryairani
Oct 03 2016 20:03
haha, do i have that?
Paul Chiusano
@pchiusano
Oct 03 2016 20:03
the metadata directory will have files like <hash>.json, as will the terms and other directories
in terms will be a bunch of <hash>.json files
that is not checked in I don’t think, but if you run the container it will be generated
Arya Irani
@aryairani
Oct 03 2016 20:04
How do I run the container?
Paul Chiusano
@pchiusano
Oct 03 2016 20:05
stack build unison-node, then stack exec container
that is the code that produces that directory structure
Arya Irani
@aryairani
Oct 03 2016 20:07
Ok thanks
Paul Chiusano
@pchiusano
Oct 03 2016 20:07
but the key thing is that we keep the names (and any other metadata) separate from the syntax tree itself
Arya Irani
@aryairani
Oct 03 2016 20:08
<nod>
Paul Chiusano
@pchiusano
Oct 03 2016 20:09
we also cache the type associated with each hash… so incremental typechecking comes free
Arya Irani
@aryairani
Oct 03 2016 20:09
That's one of my favorite things
Paul Chiusano
@pchiusano
Oct 03 2016 20:10
yeah, it’s pretty amazing… like sbt has how many man-years of effort to get nice incremental compilation, and we get it with zero extra effort!
Arya Irani
@aryairani
Oct 03 2016 20:10
Haha <nod>
I also like how you don't have to typecheck if the types don't change.
Above and beyond "if the definition doesn't change"
Paul Chiusano
@pchiusano
Oct 03 2016 20:10
yes, that is huge too
you can even go a bit further than that
if the types change, but the new type is a subtype of the old type
Arya Irani
@aryairani
Oct 03 2016 20:11
right
Paul Chiusano
@pchiusano
Oct 03 2016 20:11
like if you go from an Number -> Number to a forall a . a -> a
except, you still need to typecheck transitive dependents in that case, since they may get a more general type
but that can still be done without human intervention
Arya Irani
@aryairani
Oct 03 2016 20:13
they may get a more general type?
Paul Chiusano
@pchiusano
Oct 03 2016 20:13
yes
Arya Irani
@aryairani
Oct 03 2016 20:13
oh I see. If there were a type annotation on the call then it wouldn't go far
but if there's not, then it might change something
Paul Chiusano
@pchiusano
Oct 03 2016 20:14
yeah
Arya Irani
@aryairani
Oct 03 2016 20:14
Got it.
Paul Chiusano
@pchiusano
Oct 03 2016 20:14
you can imagine propagating it like this - typecheck dependents, but if any dependent gets the same type, no need to typecheck further, just propagate out as in the type-preserving case
Arya Irani
@aryairani
Oct 03 2016 20:15
Ah yeah.
Paul Chiusano
@pchiusano
Oct 03 2016 20:15
all automated though
so you can freely make functions more general, and not have a bunch of tedious work to do to propagate the changes in type signatures
whereas right now, if you realize “shit, I could have made this function parametric in X, without any code changes”, you might have to modify like 50 files to propagate that generality to dependents
Arya Irani
@aryairani
Oct 03 2016 20:34
Ah yeah that's cool!
Paul Chiusano
@pchiusano
Oct 03 2016 20:35
storing type signatures in the same place as the code is a mistake IMO
it’s convenient during editing, but there’s no reason to keep the type signatures in the same spot as the code
Arya Irani
@aryairani
Oct 03 2016 20:39
what are the pros and cons?
of having them together
Paul Chiusano
@pchiusano
Oct 03 2016 20:40
the pro is that it’s convenient during editing - it’s nice to be able to give type annotations in the same place as where you are writing the code
the con is that if you store the code naively as text, you have lots of redundant type signatures (signatures which the programmer used as an aid during editing, but which don’t actually constrain the type), and these signatures might require updating even if the terms don’t need updating
another good example - you change a type from Foo x to Foo x y
well 95% of the places you use Foo probably don’t care about how many type parameters Foo has
they are just calling Foo.blah or whatever
but with plain text, you gotta go update all those signatures!
i gotta run
Arya Irani
@aryairani
Oct 03 2016 21:53
Thanks!
Oh i see — this is in the context of propagating changes and so forth. You don't want to block a parent's generalization just because you wrote a typesig for the term. <nod>