infinisil changed the topic of #nix-lang to: Channel for discussing Nix as a language - https://nixos.org/nix/manual/#chap-writing-nix-expressions - Logs: https://logs.nix.samueldr.com/nix-lang/
tilpner_ has joined #nix-lang
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
Graypup_ has joined #nix-lang
<infinisil> So I'm thinking that it might be possible to implement a faster builtins.typeOf
<infinisil> By Nix internally annotating each expression with their type
<infinisil> Nix doing type inference internally so to say
<infinisil> Or computation
<infinisil> So e.g. builtins.attrNames would have the type `Attrs -> List String`
<Graypup_> oh ya another thing that would (possibly) require interpreter support (assuming I can't grab the stack trace and just grab it from the source file myself) is grabbing doc comments for functions
<infinisil> And if Nix wants to get the type of `builtins.attrNames someset` it applies the type of `someset` to the function, erroring if it's not a set, and returning `List String` otherwise
<Graypup_> I want ipython's ? but for nix
<infinisil> With this, evaluating just the type of the expression won't require actually evaluating the expression itself
<infinisil> Hm, I'd probably rather have a builtin way to specify docs, instead of hacking comment strings
<infinisil> E.g. `builtins.withDocs <expression> <docstring>`, which would annotate the expression with docs, which you could later extract with e.g. `builtins.docsOf`
<Graypup_> that works too, I am so used to thinking in bikeshed avoidance that I didn't even think of adding syntax or such
<infinisil> Or maybe even `builtins.withAnnotation <expression> <key> <value>` for arbitrary key/value mappings for annotations
<infinisil> Or maybe just `builtins.setAnnotation <expression> <value>`, because the value could just be a set with a key/value mapping`
<Graypup_> thought: should these be loaded in other cases than in the repl?
<infinisil> Could be used to automatically generate docs for e.g. pkgs.lib
<Graypup_> hm. i guess we'd want to quantify the impact on memory/perf and decide from there
<infinisil> Something I haven't addressed is purity
<infinisil> Because I'm pretty sure what I suggested above is wholly impure
<infinisil> Unless no getter functions for annotations is implemented
<infinisil> And you need to use some nix-instantiate/nix eval flag to actually extract annotations
<infinisil> Wait maybe it's not impure after all
<infinisil> Yeah actually I think it's fine
<infinisil> builtins.withAnnotation <expression> <value>: Returns a <result> such that `builtins.getAnnotation <result> == <value>`, but otherwise <result> has the same eval behavior as <expression>
<infinisil> And it's pure because you can think of every expression as `{ expression = <expression>; value = <annotation>; }`. builtins.withAnnotation then is like `// { value = ...; }` and bulitins.getAnnotation is like `.value`
<Graypup_> what would the ergonomics of this be like though?
<infinisil> Haven't thought about that
<infinisil> Maybe in nix repl it could be `:doc <expression>`, which would display the doc annotation
<Graypup_> I was more thinking on the source side: if you have to wrap every library function, that would kind of suck
<Graypup_> also if the docs had to be below the function, that would be rather sad
<infinisil> That's just a low level function I thought of
<infinisil> You could define whatever wrapper you want on top of it
<infinisil> E.g. `lib.docs = docs: value: builtins.withAnnotation value { doc = docs; }`
<infinisil> Such that you can do `somevalue = lib.docs "this value is foo" "foo"
<Graypup_> yeah, that wouldn't necessarily be too bad, but it might make it hard to visually split out the docs while reading code (not sure if such sacrifices are considered acceptable in nix-land though!)
<Graypup_> e.g. with highlighting it a different colour because it's a comment
<infinisil> Hm I'm not very worried about that
<Graypup_> syntax e.g. ## or something like that could work, but not sure how to get it to stick to the correct function given the rather freeform nature of nix code
<infinisil> Oh yeah I guess Nix could automatically use builtins.withAnnotation from the comments, that's an interesting idea
<infinisil> I can see that working with some basic rules
<infinisil> Even with just normal comments
<infinisil> E.g. any comment like `{ foo = "foo"; /*<comment>*/ bar = "bar"; }` would transform into `{ foo = "foo"; bar = builtins.withAnnotation "bar" { comment = "<comment>; }; }`
<Graypup_> if it's too clever, it might accidentally turn non-doc comments into doc comments. We could also steal the JSDoc style of /** docs in here */ (note the second opening asterisk)
<infinisil> You could do that with post processing. E.g. when you `(builtins.getAnnotation <value>).comment`, you first check if the first character is "*"
<infinisil> For doc generation
ddellacosta has quit [Ping timeout: 258 seconds]
__monty__ has joined #nix-lang
tilpner_ has joined #nix-lang
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ has quit [Remote host closed the connection]
tilpner_ has joined #nix-lang
tilpner_ is now known as tilpner
__monty__ has quit [Quit: leaving]
ddellacosta has joined #nix-lang