Clarify string coercion errors

[layus]

No description provided.

[layus]

This deserves a proper discussion. It seems that in some places the code was relying on ToString instance to generate strings with no context.

This changes the error message to reflect that strings with context are accepted.

Now, if the code was really relying on that assumption, it is still broken.

[Anton-Latukha]

TString? Or string class hub ToString from relude. In the second case - so far I just worked on strings that already were spawned in a regular way.

If to preserve context, or not, - I have no idea.
If the context is beneficial - of course, it should be preserved.

If there are really literal creations of the strings and they better to have context - then lets do it.

Personally, I am bothered & occupied with that we have String, strings of text of different data types, Nix String as a type of expression, Expression, StringContext, NixString. It seems for me that some of those need to be renamed/abstracted better.

===

I'd asked maybe a straight literal stream of consciousness of what you were doing, checking, understood, and found out, and what is your decision on it.

===

Lets preserve context where it seems to be in place, it would be a bit more memory footprint, but we so far not made solid space profiling. We always can drop the context.

[Anton-Latukha]

TString? Or string class hub ToString from relude. In the second case - so far I just worked on strings that already were spawned in a regular way.

If to preserve context, or not, - I have no idea.
If the context is beneficial - of course, it should be preserved.

If there are really literal creations of the strings and they better to have context - then lets do it.

Personally, I am bothered & occupied with that we have String, strings of text of different data types, Nix String as a type of expression, Expression, StringContext, NixString. It seems for me that some of those need to be renamed/abstracted better.

===

I'd asked maybe a straight literal stream of consciousness of what you were doing, checking, understood, and found out, and what is your decision on it.

===

Lets preserve context where it seems to be in place, it would be a bit more memory footprint, but we so far not made solid space profiling. We always can drop the context.

[Anton-Latukha]

Maybe I did a tiny bad thing merging master into the branch.

Is it ready yet?

It seems a lot of discussion for the detail.

Generally - if there are errors - there is no way to control them if there are no tests for that.

Without the tests, the general good suggestion is to have a healthy sense of causality & things.

Generally, we need to go with a healthy sense & ramp-up the testing suite workflow.

[layus]

This PR is as much a question as an answer.

We use the FromValue stuff to cast string-like things to strings. It is used to extract antiquotations in attr selectors (foo.bar.${sthg}.etc). But we use the same FromValue mechanism in string antiquotations, where a context is allowed. And the code actually allowed contexts, and was used like so.

This PR is thus mergeable as-is. It moslty fixes the error message to make it consistent with the actual code. I think it can be merged, and yes, test would be a good thing :-)

[Anton-Latukha]

Convert module is one of the most obscure parts of the project.

Function instances need type signatures to "undiscombabulate" themselves.

I feel like it is again the same situation as you put previously. NValue* is a thunk & a value which seem hard to inspect.

Maybe: the conversion instances logic can be expanded to pattern match & account/filter cases to transfer the context, and where there would be no context.

What I know - is that I am pretty glad with the result of lifting up the VarName type boundary - what is VarName is a bit muddy still because it is a broad abstraction, thou it already revealed a lot of things in the type system to us & it is a great start. The same solution probably goes to the evaluation values, but so far I could not poke into the type boundary that is needed there. Probably we need to lift type boundaries nearby, where that is obvious (aliases always one of best places to find them) - & starting from that obvious typesystem would lead us to the solution with these (NValues).

[Anton-Latukha]

We use the FromValue stuff to cast string-like things to strings. It is used to extract antiquotations in attr selectors (foo.bar.${sthg}.etc). But we use the same FromValue mechanism in string antiquotations, where a context is allowed. And the code actually allowed contexts, and was used like so.

In these, where either solution is partial & may produce bugs, good practice is to leave a note, at least for oneself in the future. A note to arrive to.

[Anton-Latukha]

@layus

I've noticed the solution to the: #958 (comment)

It is in the #377 & so now #977.