From: Adam Joseph <adam@westernsemico•com>
To: depot@tvl.su, sternenseemann <sternenseemann@systemli•org>
Subject: Re: [tvix] Value Location, Value Documentation
Date: Mon, 03 Jul 2023 02:36:12 -0700 [thread overview]
Message-ID: <168837697280.32752.4846062186663393258@localhost> (raw)
In-Reply-To: <5d2a7439-2a0a-791b-7b36-668427e296ef@systemli.org>
I know this message is a ~month old, but...
Quoting sternenseemann (2023-06-02 14:49:16)
> Currently we can relate specific VM instructions back to a source
> location that caused them to be emitted by the compiler.
> ...
> We may also need to or want to relate values back to source locations
It's important to keep in mind that adding metadata to values is much, much,
more expensive than adding metadata to instructions/opcodes.
> * builtins.unsafeGetAttrPos demands that we are able to return the
> source location where an attribute (given by its name) of a specific
> attribute set (given as a value) is defined.
Yes, unfortunately. Hopefully when tvix will allow disabling it at compile
time, so there is no memory overhead. I bet it's worth it for Hydra or
(especially) OfBorg, who have no need for `nix develop`.
> 1. To enhance runtime traces. Similarly to how C++ Nix is able to
> display the source locations of lambdas during evaluation.
Hrm, does this require adding metadata to *values*? You should be able to
recover a stack trace just by looking at VM::frames and extracting from those a
Chunk, which has a SourceSpan.
> 2. To retrieve documentation:
These seem low-cost if they're opt-in.
> hsjobeki has proposed a CL (<https://cl.tvl.fyi/8530>) for Tvix
> that implements a weird mix of both approaches:
I've been having trouble understanding what's going on in that CL; there doesn't
seem to be a "here's the big picture" overview in the commit message.
> Documentation comments' contents are attached to lambda values
Why not attach them to a Chunk instead? Every Lambda knows what Chunk it came
from, but Chunks are created only at compile time, not at runtime.
Since doc-comments can't be mutated at compile time it seems weird for them to
have a runtime representation. Especially when attached to functions, which
(unlike the other variants of Value) can already be associated back to a
SourceSpan.
- a
prev parent reply other threads:[~2023-07-03 9:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 21:49 sternenseemann
2023-07-03 9:36 ` Adam Joseph [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=168837697280.32752.4846062186663393258@localhost \
--to=adam@westernsemico$(echo .)com \
--cc=depot@tvl.su \
--cc=sternenseemann@systemli$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://code.tvl.fyi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).