Re: [Caml-list] Type Encoding Format Control

[Kenneth Adam Miller <kennethadammiller@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]

One of the things I had also thought about expressing also is about
automatically collapsing such a type instance as part of it's definition
with other annotations, but that's complicated and likely a different topic
so I didn't mention it.

On Thu, Aug 20, 2015 at 10:09 AM, Kenneth Adam Miller <
kennethadammiller@gmail.com> wrote:

> It expresses intuitively, "Something which is exactly a nothing", so
> naturally, I would categorize that as a nothing directly of course. And
> you've just done precisely that with your code; foo = Some None => set that
> field to NULL could only represent saying that field is just exactly
> nothing directly. So, it's just like I said-you have to deal with the
> instance because it comes up in practice, and pragmatically we have to
> represent such cases in machine code as has been discussed. But in
> practicality almost never would an author sensibly keep the expanded form
> of Some None directly, it shows up due to code combinations only to be
> reduced.
>
> On Thu, Aug 20, 2015 at 10:05 AM, David Allsopp <dra-news@metastack.com>
> wrote:
>
>> Kenneth Adam Miller wrote:
>> > In the case of 2), that's interesting because such a type of
>> > Some None is sort of antithetical to describing anything
>> > sensical. Not that it's not pragmatic or doesn't occur-I'm sure
>> > some functions get combined in ways that stuff like this crops
>> > up. But I think of the typing system as being badly exercised
>> > if something like this arises-
>>
>> One example that springs immediately to mind: NULLable field in a
>> database, so 'a option is a sensible type to represent it. Now consider a
>> function intended to generate SQL UPDATE statements for that field:
>>
>> val update_record : ?foo:int option -> ?bar:int option -> id:int ->
>> baz:string -> bool
>>
>> where omitting ~foo or ~bar means "don't change foo/bar in the UPDATE
>> statement". Within the code for update_record:
>>
>> foo = None => don't update that field
>> foo = Some None => set that field to NULL
>> foo = Some (Some i) => set that field's value to i
>>
>> and all three cases will need different code.
>>
>> See also https://github.com/ocaml/ocaml/blob/trunk/typing/env.ml#L391
>>
>> What's (to you) badly exercised or nonsensical in either of those
>> representations?
>>
>>
>> David
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3258 bytes --]