Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[non-expansivity issue] Using 'match' prevents generalization [of values], even though using 'if' allows it #6056

Closed
vicuna opened this issue Jun 27, 2013 · 3 comments
Closed

[non-expansivity issue] Using 'match' prevents generalization [of values], even though using 'if' allows it #6056

vicuna opened this issue Jun 27, 2013 · 3 comments
Assignees
@garrigue
Labels
bug typing

Comments

@vicuna
Copy link

vicuna commented Jun 27, 2013

Original bug ID: 6056
Reporter: elnatan
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2015-12-11T18:20:02Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.00.1
Fixed in version: 4.01.0+dev
Category: typing
Related to: #6057
Monitored by: @gasche

Bug description

In the following two examples, using an 'if' statement allows the function to be generalized, but using 'match' prevents it.

let using_if b =
let f =
if b
then fun x -> x
else fun x -> x
in
f 0,f
;;
(* val using_if : bool -> int * ('a -> 'a) = *)

let using_match b =
let f =
match b with
| true -> fun x -> x
| false -> fun x -> x
in
f 0,f
;;
(* val using_match : bool -> int * (int -> int) = *)

Additional information

A colleague of mine suggests that this is due to the fact that 'match' statements are never considered to be nonexpansive.
@vicuna
Copy link
Author

vicuna commented Jun 28, 2013

Comment author: @garrigue

Actually, this is wrong: in "match e with p -> ...", e is generalized.
What is not generalized is the result of the match expression.
As you write, match expressions are never generalized,
whereas let expressions are generalized if subexpressions are non expansive.
So this should probably be done the same way.
Note that lazy patterns may cause side-effects, but this is already handled
by the typing of lazy values (i.e. a lazy value is not generalizable if forcing it
would cause side-effects)

@vicuna
Copy link
Author

vicuna commented Jun 28, 2013

Comment author: @garrigue

My bad. I thought this was done, but it is not.
Both 6056 and 6057 should be done soon.
Actually 6057 is the harder one (but not by a big difference).

@vicuna
Copy link
Author

vicuna commented Jun 28, 2013

Comment author: @garrigue

Fixed in trunk and 4.01 (before release).
Revisions 13845 and 13847.

This had to be fixed because let's that contain GADTs are automatically converted to match, so the difference in behavior could be observable.

@vicuna vicuna closed this as completed Dec 11, 2015
@vicuna vicuna added the typing label Mar 14, 2019
@vicuna vicuna mentioned this issue Mar 14, 2019
Closed
@vicuna vicuna added the bug label Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@garrigue garrigue

Labels
bug typing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@garrigue @vicuna