maybe you could pass the serializer as an argument? Intuitively, I take
those fancy format options as lookups to a serializer factory. So perhaps
you could specify your own:
[just making up a format "%<>" to represent custom serializer]
writef("%<>\n", mySerializer, myRecord);
or even fancier, maybe there's a way to set a serializer context for the
subsequent writef's:
with mySerializer {
writef("%<>\n", myRecord);
}
or also be able to set the global serializer program context via the IO.sys
module.
On Wed, May 27, 2015 at 8:43 AM, Michael Ferguson <[email protected]>
wrote:
> Hi Brian -
>
> We have support for that kind of JSON thing using writef.
>
> writef("%ht\n", myrecord);
>
> would print it out in a way you could paste into Chapel code
> and
>
> writef("%jt\n", myrecord);
>
>
> will print it out in JSON format.
>
> Note that both of these features don't work right in all cases yet
> (tuples, arrays, ...).
>
> I'd also like to create a serialization format that allows cycles,
> but JSON doesn't do that even...
>
> Another issue (right now) is that while you can supply your own
> readThis/writeThis/readWriteThis method for a custom record, you
> can't use readf/writef within it.
>
> Cheers,
>
> -michael
>
>
> On 5/27/15, 10:04 AM, "Brian Guarraci" <[email protected]> wrote:
>
> >Hi Michael,
> >
> >
> >This strategy seems to imply an implicit serialization schema. It may be
> >interesting to allow for a default schema as you suggest but also to
> >provide another way to specify the serialization / deserialization
> >methods? When I look at your example, my
> > mind translates it to JSON as:
> >
> >
> >{
> > a: "hello world",
> > b: "second string"
> >}
> >
> >
> >so I wonder if it makes sense to generalize the approach.
> >
> >On Wed, May 27, 2015 at 6:54 AM, Michael Ferguson
> ><[email protected]> wrote:
> >
> >Hi Chapel Developers -
> >
> >I'd like to be able to write and then read an array/record/whatever and
> >expect it to work, but there are problems if the object contains strings.
> >I'm proposing a change to the I/O behavior to fix this problem.
> >
> >How did we get here? If you do:
> >
> > writeln("hello world\n");
> >
> >you (naturally?) expect "hello world" to print without quotes:
> >
> > hello world
> >
> >but then if you were reading that input and you did this:
> >
> > var s: string;
> > readln(s);
> >
> >s would contain only "hello", because the default string reading rule
> >is to read one word only. Even if that were not the case, we wouldn't
> >know when we reached the end of the string since it is not delimited
> >in any way. (and making writeln print the quotes by default interferes
> >with things like writeln("a = ", a) ).
> >
> >When we get to a record, these choices are no longer reasonable.
> >
> >For example, if I have
> >
> > record R { a: string, b: string }
> > writeln(new R("hello world", "second string"));
> >
> >it will output
> >
> > (a = hello world, b = second string)
> >
> >and there's pretty much no way that the corresponding readln would work
> >(what if the string contains commas or parenthesis?). I believe that
> >the current code will only be able to read 1-word strings in records...
> >
> >So, I'd like to propose the following change in I/O behavior:
> >
> > - writeln(string) and readln(string) continue to work the way they do
> > - write/writeln/read/readln of any aggregate
> >(record/class/array/tuple/etc)
> > will switch the string formatting to double-quoted strings that would
> > work in Chapel source code, so the second record example above would
> > now output
> >
> > (a = "hello world", b = "second string")
> >
> >
> >Any objections?
> >
> >-michael
> >
> >
> >--------------------------------------------------------------------------
> >----
> >_______________________________________________
> >Chapel-developers mailing list
> >[email protected]
> >https://lists.sourceforge.net/lists/listinfo/chapel-developers
> >
> >
> >
> >
> >
> >
>
>
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
