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

Reply via email to