haskell-nix / hnix

A Haskell re-implementation of the Nix expression language
https://hackage.haskell.org/package/hnix
BSD 3-Clause "New" or "Revised" License
762 stars 115 forks source link

Need another output token to represent thunks #179

Open jwiegley opened 6 years ago

jwiegley commented 6 years ago

Right now we re-use a lot of code by output thunks as if they were string objects containing the word "<thunk>", but really they should not be display as strings like that.

Anton-Latukha commented 3 years ago

& they should print out the normalized value/expression probably?

jwiegley commented 3 years ago

A thunk may not ever have a normalized value, since it's acceptable for an attrlist to contain invalid values so long as they are never evaluated.

layus commented 3 years ago

nix prints <thunk> while we print "<thunk>" because we indeed substitute thunk loops (and thunks) by a string before printing. A separate token would allow to keep the information that this is a thunk until we have to print them.

Anton-Latukha commented 3 years ago

Well. The more I listen to @layus & the more I think about it - the more I agree with @layus, that thunking type system should gain some type abstractions depending on computation done on them.

For me the https://github.com/haskell-nix/hnix/issues/179#issuecomment-865252362 contradicts the https://github.com/haskell-nix/hnix/issues/179#issue-314292570. We need to evaluate the thunks to print them, while they can be infinite & they can contain invalid values or (maybe) even gibberish - which means 1 of 2 things:

  1. Show instance for thunks should have complex behaviour: depending on the thunk the output mode would differ.
  2. Keep it <thunk>.
  3. Differentiate between thunks, aka had it normalized - it becomes value type (speaking vaguely here). In any case this report asks - the thunk printing needs to reify the thunk, it done on the computation low level, but that should be type system requirement.

(in other words, it needs to be formulated: current type system state needs to be criticized & different sides in its shortcommings shown) & then develop a solution, establish & thread newtypes into the typesystem, as that is always a first step & preserves all current computation efficiency. Raw thunk is the base type & the reified stuff builds ontop of it.

As in reality thunks can not be shown, if it is shown - what is shown is not (no longer a) thunk.