[Nix-dev] Nix expression built-in type limitations

[Shea Levy]

Hello,

> On Apr 30, 2015, at 4:45 PM, Terrance Kennedy <terrancerkennedy at gmail.com> wrote:
> 
> Hi,
> 
> I'm working on a Python project to convert Python built-in types to Nix built-in types and it raised some quesions on the limitations of built-in Nix types. I've been able to gather some information using nix-repl and reading the Nix expression parser code, but am not sure on the following:
> 
> - Integer: Appear to be either 32 or 64 bit signed integer depending on the underlying architecture. Is this correct?

Integers are mapped to the C++ long type [1].

> - String: From what I can tell, since Nix strings are based on C++ std::string, they don't enforce or expect any kind of encoding. Is it recommended or tested to put non-ASCII data (in any encoding) into a Nix string? What about binary data?

Strings are stored as null-terminated char arrays[2]*. Any char besides 0 can 
safely be stored in them, but if you try to display them they will be treated as
ASCII.

> - Path: Are there any disallowed characters in a Nix path? How can one represent paths with whitespace?
> 

Path literals are determined by [3], but you can append a string to a path, so
e.g. (./. + "/filename with spaces.txt") will result in a path with spaces in
the name.

> Cheers,
> - Terrance
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

* They also have associated context, which is irrelevant for the purposes of this
  question.
[1]: https://github.com/NixOS/nix/blob/1.8/src/libexpr/value.hh#L38
[2]: https://github.com/NixOS/nix/blob/1.8/src/libexpr/value.hh#L115
[3]: https://github.com/NixOS/nix/blob/1.8/src/libexpr/lexer.l#L82