Le Fri, 17 Jan 2014, Yaron Minsky a écrit :
> I also agree with Gabriel that an option-specific optimization is not
> clearly the right move.
> 
> But I wonder if a more general optimization that provided the
> possibility of minting "fast-path" variants.  i.e., one could have an
> annotation that marked a given branch of a variant as the
> "no-indirection" one, i.e., the one that doesn't lead to the
> allocation of an extra block:
> 
> type ('a,'b) result =
>      | Ok of 'a [@@no_indirection]
>      | Error of 'b
> 
> would lead to a type where [Ok x == x].  Some cleverness is required
> then for the representation of the [Error] branch.  In particular,
> you'd need some dynamic test you could run to see if you were using a
> value that was not the fast-path one.
> 
> The thing that I don't know if there's a solution for is the nesting
> problem.  i.e., can you effectively distinguish:
> 
>   Ok (Ok (Error x))
> 
> from
> 
>   Error x
> 
> since they would have the same physical representation.  I'm not sure
> if some variant of the counting trick used for options would work here
> or not.  But if you could get this, it would make it possible to avoid
> a large number of dirty Obj.magic hacks that people need to do to
> build efficient datastructures in practice.  The fact that the stdlib
> needs to use Obj.magic to get the necessary performance is, I think, a
> sign that something important is missing from the language.  I'm not
> sure if this is quite it, to be clear.

Maybe I'm stating the obvious, but wouldn't value types be the general
solution here? Assuming the optimizer can guarantee that the option
value will not outlive the current scope, the value can be allocated on
the stack or in registers. That's probably fast enough for most uses,
isn't it? I think rust deals with option values exactly this way.


-- 
Simon