nimforum mirror - NimYAML approaching stable release

flyx (orginal) [2016-03-25T23:52:52+01:00] view original

Hi folks,

my YAML implementation is approaching a first stable release, and I'd like to have some comments on the interface before the release. You can find documentation and code examples over here.

Some issues I have not yet decided upon:

Using int and float is currently disallowed, as serialized YAML might not round-trip between 32bit and 64bit binaries. Instead, types with explicit size (e.g. int32) must be used. This causes many types of the standard library to not be automatically serializable, because they contain int or float. I am not quite happy with that.

NimYAML focuses on serializing native Nim types. There is a DOM API, but it's pretty basic. I wonder if people rather want to use native types or DOM. Native types have the slight disadvantage that they cannot really map to YAML objects containing heterogeneous data (a sequence with strings and integers, for example). It is possible to implement this in Nim, but it is impractical.

NimYAML supports serializing to and from JSON. This is nice for interoperability with other tools. However, features get lost when downgrading to JSON: Reference types get duplicated on each occurrence, cyclic structures lead to an infinite loop, and mappings with complex keys are also not available. I wonder if there is a demand for a more complete YAML-JSON mapping, which will make the JSON more complex, but can then support all features the YAML output has.

nil strings and sequences are not supported. It would be possible, but I am not sure if that is a „good“ feature.

Any comments would be appreciated.

Araq (orginal) [2016-03-26T09:13:52+01:00] view original

Nice!

I would allow int and float and treat them as int32 and float64. Float is always 64 bits for now and you can have runtime checks that the ints stay in the 32bit range.

Yeah, native Nim types are the way to go.

Well infinite loops should be avoided (raise an exception?) but I think the other restrictions are fine. JSON is inherently acyclic and that's one of its great advantages. Keep your data simple, all sort of tools can work with it then.

I think they should be dealt with properly.

flyx (orginal) [2016-06-08T21:42:47+02:00] view original

I just released 0.6.0. This is the first release that works on a released version of Nim (0.14.0) and which I consider at least somewhat stable.

As for the points I rambled about:

int, uint and float are now allowed and will be processed as int32, uint32 and float64 respectively.

Support for native types has been enhanced. Things that do not work properly are generic types and polymorphism. I might add this in the future.

JSON support remains as it is. If the structure allows to be written as JSON, it works; if it doesn't, an exception is thrown.

nil strings and seqs are properly supported.

Unless people file issues, I will now be primarily doing other things, so if you find a bug and want it to be fixed, be sure to report it!

Renesac (orginal) [2016-06-09T18:23:04+02:00] view original

What happens when you want to serialize an objet of int type but it has big values in it? It is not serializable? It will fail "randomly" w/o warning on run time?

flyx (orginal) [2016-06-09T18:33:45+02:00] view original

An OverflowError will be raised.

Mirror of forum.nim-lang.org

2157 :: NimYAML approaching stable release