Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF

[Ulysse Carion <[e-mail]>]

How is such a thing supposed to work portably? What is the "length" of
a JSON string, and does this have any correspondence to the memory
representation of that string, post-parsing?

On Sun, Sep 1, 2019 at 4:14 PM John Cowan <[e-mail]> wrote:
>
> The argument for it is precisely in situations where static allocation is required along with static typing.  If you know the (maximum) length, you can safely allocate a fixed amount of memory for your internal representation, which you cannot do otherwise.   Languages with static types and garbage collection (allowing dynamic allocation) are just one particular kind of languages, and I think you need to accommodate all widely used kinds of languages.  I wouldn't object to skipping bounded arrays and strings in favor of just fixed-length ones.
>
> See < http://www.catb.org/esr/microjson/>, a JSON-subset parser written in C that imposes exactly this restriction so that it can run safely on embedded systems with only small amounts of RAM.
>
>
> On Sun, Sep 1, 2019 at 7:03 PM Ulysse Carion <[e-mail]> wrote:
>>
>> Sure -- but you could use the length validation as a hint to code
>> generators, and a warning to data producers that the application will,
>> post JDDF-level validation, do additional length checks.
>>
>> I'm not sure the need for length validation is strong enough to merit
>> its inclusion in this version of the spec.
>>
>> On Sun, Sep 1, 2019 at 3:42 PM John Cowan <[e-mail]> wrote:
>> >
>> > Section 2.3 says that extensions can't be validation-related, so a length limitation would most certainly be a matter of validation.
>> >
>> > On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion <[e-mail]> wrote:
>> >>
>> >> Fixed-length strings and arrays both sound like things one could
>> >> implement with extensions, no?
>> >>
>> >> Tuples are a very sensible suggestion. But I wonder if we can live
>> >> without them? I very much want to keep JDDF as small as possible.