[wg-camlp4] Improvements to the OCaml Parsetree

[Romain Bardou]

Le 16/04/2013 17:50, Alain Frisch a écrit :
> On 01/28/2013 04:43 PM, Romain Bardou wrote:
>> About assert false as a special node: I think it should stay like this.
>>
>> It may add a case to treat, but the treatment will usually be trivial.
>> If it is not, then it will probably be an instance of the assert case,
>> in which case you can just call the assert case with <<false>> as an
>> argument. Else it means that you have a very different treatment for
>> false and in this case, you’re glad that they are separate.
>>
>> Moreover, this case really is a special case as it is typed differently.
>> I think it is better if the parse tree reflects this, so that the
>> programmer is conscious of this when transforming assertions.
> 
> I've given it some thought, and I'm no longer convinced by the argument.
>  I can see two concrete reasons for treating "assert false" in the
> type-checker:
> 
>  - -ppx rewriters could very well produce an assert node with a "false"
> expression and it would behave differently from an "assert false" in the
> source code.  This would be quite puzzling, and round-tripping with the
> concrete syntax becomes impossible.

Sorry for the delay, I was not paying attention to the list at the time
(and the personal copy was sent to my list folder automatically as well…).

Not that I strongly object at all, but I would just point out that the
reverse is also true: one may not understand why some expression
sometimes has type 'a and sometimes has type, well, something else.

For instance, let's imagine a rewriter expands:

let check () =
  check_platform_is[@32]

into either:

let check () =
  assert false (* if on 64bits *)

or:

let check () =
  () (* if on 32bits *)

Now, imagine the programmer does not realize this, and puts the
following type in the .mli:

val check: 'a (* or anything except unit *)

If he does not actually call this function, the programmer will only see
the error when compiling for another platform, and he may be quite
puzzled as well.

Now, that's maybe not a strong enough argument against simplification
though. Just an interesting fact.

>  - It is not clear what to do with "assert (false[@foo])".

That's very true.

-- 
Romain Bardou