Skip to content

Printer followup #9755

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
roberth merged 2 commits into from
Jan 16, 2024
Merged

Printer followup #9755

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2d96c7a
Remove outdated reference to `y` in `nix-instantiate` man page
9999years Jan 12, 2024
f73e501
Clarify ambiguity in `nix-instantiate` man page
9999years Jan 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 4 additions & 8 deletions doc/manual/src/command-ref/nix-instantiate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,9 +44,10 @@ standard input.

> **Warning**
>
> This option produces ambiguous output which is not suitable for machine
> consumption. For example, these two Nix expressions print the same result
> despite having different types:
> This option produces output which can be parsed as a Nix expression which
Copy link
Member

@roberth roberth Jan 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
> This option produces output which can be parsed as a Nix expression which
> This option may produce output which can be understood as a Nix expression which

Copy link
Contributor Author

@9999years 9999years Jan 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is that the output includes valid Nix syntax that does not parse as the value it's standing in for. It's specifically about the parsing. Humans will be able to look at <CODE> and understand it's a placeholder through context clues, machines will not.

Copy link
Member

@sternenseemann sternenseemann Jan 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it would be wrong to assume that you can obtain the value from the output somehow if you are not using --strict.

Copy link
Member

@roberth roberth Jan 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it doesn't output (general) expressions, no machine will be programmed to parse it as expressions.

The motivation for my suggestion is as follows:

  • Parsing by a human is better described as understanding.
  • may is only there because the output may also be unambiguous - such as when passing --strict.

I did make a mistake though. (also "to be" is a bit simpler)

Suggested change
> This option produces output which can be parsed as a Nix expression which
> This option may produce output which can be misunderstood to be a Nix expression which

Apart from this suggestion, it'd be helpful to mention --strict as a possible solution.

Copy link
Member

@lf- lf- Jan 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it doesn't output (general) expressions, no machine will be programmed to parse it as expressions.

This fails to consider machines that are bad :)
Imagine for a minute that someone calls nix-instantiate, likes the output, then immediately integrates it without thinking whatsoever.

This is a reason we need to make this obviously not for machine consumption. Perhaps we should print a warning to stderr if stdout is a pipe.

Copy link
Contributor Author

@9999years 9999years Jan 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--strict still includes «repeated» and «potential infinite recursion».

Because it doesn't output (general) expressions, no machine will be programmed to parse it as expressions.

This is a currently undocumented assumption.

Copy link
Member

@roberth roberth Jan 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it doesn't output (general) expressions, no machine will be programmed to parse it as expressions.

This is a currently undocumented assumption.

It is a personal assumption of mine, and I don't think it's relevant enough to document.

Nonetheless, if you think the warning or any other docs are still insufficient, feel free to open another PR. (And/or discuss here, etc)

> will produce a different result than the input expression when evaluated.
> For example, these two Nix expressions print the same result despite
> having different meaning:
>
> ```console
> $ nix-instantiate --eval --expr '{ a = {}; }'
Expand Down Expand Up @@ -179,12 +180,7 @@ $ nix-instantiate --eval --xml --expr '{ x = {}; }'
</attr>
</attrs>
</expr>
```

Note that `y` is left unevaluated (the XML representation doesn’t
attempt to show non-normal forms).

```console
$ nix-instantiate --eval --xml --strict --expr '{ x = {}; }'
<?xml version='1.0' encoding='utf-8'?>
<expr>
Expand Down