Configure-time option for float array optimization. by damiendoligez · Pull Request #1294 · ocaml/ocaml

damiendoligez · 2017-08-18T09:20:53Z

This PR introduces a configure-time option to remove the float array optimization. Removing this optimization makes float array operations slower, but all other polymorphic array operations slightly faster. It also removes some restrictions on let rec and especially on unboxed types.

This is only the minimal changes to the runtime and compiler to enable experimenting. What's missing is a new Floatarray module to give operations on the new floatarray type that represents flat-allocated arrays of unboxed float. Because it is user-visible, this new module will generate a lot of discussion on naming, which is not yet relevant: we should first run some benchmarks on this PR to decide if we want to shift the trade-off away from float array optimization.

See also #163 #1169

This PR hat two commits, you will need to bootstrap (make core && make coreboot) after applying the first commit.

The test suite passes on my machine, but I haven't tried OPAM packages yet and I don't know how many libraries with C bindings will be impacted.

There is one design decision that should be discussed: should the Obj.field and Obj.set_field functions remain ad hoc (i.e. work on both regular arrays and flat float arrays) or should they be low-level primitives that assume regular arrays (and then we need to introduce double_field and set_double_field) ? I've done the latter but this is open for discussion.

lpw25 · 2017-08-18T09:45:02Z

and then we need to introduce double_field and set_double_field)

double_field and set_double_field already exist in Obj.

I've done the latter but this is open for discussion.

I firmly believe that this is the right approach (and was planning to make a pull request that did just this change anyway).

damiendoligez · 2017-08-18T12:16:16Z

double_field and set_double_field already exist in Obj.

Oh yes that's right. I had to add them to the OBJ module type in toplevel, which also impacts the debugger.

bluddy · 2017-08-21T19:39:29Z

stdlib/array.ml

+  external create : int -> floatarray = "caml_floatarray_create"
+  external get : floatarray -> int -> float = "caml_floatarray_get"
+  external set : floatarray -> int -> float -> unit = "caml_floatarray_set"
+end


We'll need more functions here to handle this type (map, fold, etc), right?

Right. That's the user-facing part that I want to do in another PR because it will take longer to discuss and it's not really needed for benchmarking.

OK sounds good.

alainfrisch · 2017-08-23T07:40:16Z

byterun/alloc.c

 /* [size] is a [value] representing number of floats. */
 CAMLprim value caml_alloc_dummy_float (value size)
 {
+#ifdef FLAT_FLOAT_ARRAY


This does not look correct to me. caml_alloc_dummy_float is used to compile rec-bindings, in two cases: (i) unboxed float arrays; (ii) unboxed float records. AFAICT, (i) cannot happen any more (there are not Floatarray litterals) but (ii) can still happen. So I think caml_alloc_dummy_float should be left unchanged.

alainfrisch · 2017-08-23T07:41:18Z

byterun/alloc.c

  CAMLassert (tag < No_scan_tag || tag == Double_array_tag);

  Tag_val(dummy) = tag;
+#ifdef FLAT_FLOAT_ARRAY


Same as above. caml_update_dummy might still be called (for unboxed float record) on a Double_array_tag block, no?

alainfrisch · 2017-08-23T07:43:15Z

byterun/array.c

-  else
-    return caml_array_get_addr(array, index);
+#endif
+  CAMLassert (Tag_val(array) != Double_array_tag);


What about putting the assertion under a #elseif to avoid it in legacy mode? (But perhaps the C compilers are clever enough to avoid it.)

What's the point? The assertion is also true in legacy mode, and more assertions are always better. Assertions are only compiled in the debug runtime anyway.

alainfrisch · 2017-08-23T07:46:24Z

stdlib/array.ml


+module Floatarray = struct
+  external create : int -> floatarray = "caml_floatarray_create"
+  external get : floatarray -> int -> float = "caml_floatarray_get"


I know this is WIP, but do we agree that this should be a %-primitive instead?

It definitely should. Otherwise it will be very slow.

Yes of course.

alainfrisch · 2017-08-23T07:47:46Z

stdlib/array.ml

 external create_float: int -> float array = "caml_make_float_vect"
 let make_float = create_float

+module Floatarray = struct


In the naming side, I don't like Array.Floatarray. I'd prefer any of Array.FloatArray, Array.Float, Float.Array, or a toplevel FloatArray.

Of these I like Float.Array best, since it's easiest to extend to additional types later (e.g. a specialized Int64.Array or Bool.Array).

Of course, we'd need a Float module first.

@yallop Array.Float has my preference, and I'd say it's just as easy to extend.

@damiendoligez: I think type-specialized array representation is a bit like type-specialized compare in this respect. Rather than enumerating all the type-specialized compare functions in a single module, we've put each instance alongside its type: Int64.compare, Char.compare, etc.

Doing things that way has the advantage that it extends well to types outside the standard library, too.

Additionally, it would avoid awkward dependency cycles. Array is towards the start of the dependency chain right now. Adding Array.* for each base type of the stdlib would need to move it towards the end.

I think Float.Array is most satisfactory. It matches up with existing usage in the compiler of Foo.Map, Foo.Set, etc.

alainfrisch · 2017-08-23T07:48:54Z

byterun/array.c

+  return caml_array_get_addr(array, index);
+}
+
+CAMLprim value caml_floatarray_get(value array, value index)


As said in another note, I believe this should become a %-primitive and be handled directly by the compiler.

alainfrisch · 2017-08-23T07:49:17Z

byterun/array.c

+  return caml_array_set_addr(array, index, newval);
+}
+
+CAMLprim value caml_floatarray_set(value array, value index, value newval)


Same, this should be a %-primitive I think.

alainfrisch · 2017-08-23T07:55:14Z

byterun/caml/mlvalues.h

+  #define Double_field(v,i) Double_field_flat(v,i)
+  #define Store_double_field(v,i,d) Store_double_field_flat(v,i,d)
+#else
+  static inline double Double_field (value v, mlsize_t i) {


I assume the need for Double_field is only for the transition period, to allow C stubs to be compatible with both modes. In a world without the legacy mode, one would not need it, right?

I'm clarifying this part by adding comments, and I'm finding bugs and redundancies. Stay tuned for a new commit soon.

alainfrisch · 2017-08-23T07:56:13Z

byterun/interp.c

      accu = Atom(*pc++); Next;

-    Instruct(MAKEBLOCK): {
+    Instruct(MAKEBLOCK):


This stylistic change is at odds with other similar cases around.

alainfrisch · 2017-08-23T08:20:41Z

Firstly: hoorah!

See some inline comments (note: I haven't reviewed everything). Some other general points:

In the legacy mode, do we want to add a manifest from the new explicit floatarray currently-abstract type to float array? On the one hand, this might help people migrate their code base incrementally to using the explicit Floatarray module. On the other hand, it might makes it more difficult to identify which code needs to be adapted. Could this deserve a third "intermediate" mode?
We need to think about ways to help people migrate their code base. Contrary to e.g. the immutable string case, enabling the new mode would not break compilation, but can degrade performance significantly. How will people identify code that needs to be adapted? What about warning when one use generic arrays on the float type? There could be both a compile-time warning (when the type is known statically, using approach previously used to switch to specialized float-array primitives; or for any instantiation of the 'a array on float) and a (conditional) runtime one (when creating a statically-generic array which happens to hold floats). An alternative to the static warning would a tool parsing .cmt file to detect uses of float array, but a warning would be simpler to use (and could be applied after inlining). I believe thinking about a good migration path is critical to the success of the new mode.
For immutable strings, I think there is a consensus that the long-term goal is to get rid of the old mode -- we would do it right now if all community projects were ready for it. For the current PR, I was under the impression that @xavierleroy was still reluctant to getting rid of automagically unboxed float arrays. Has this changed? Do we have some hope of dropping the legacy mode at some point? Part of the benefit of the new mode is that it will remove quite a bit of complexity (and edge cases) from the compiler code base and runtime system. If we think that the legacy mode is here to stay, we won't benefit from these simplifications (e.g. the code for deciding if a GADT single-constructor sum type case be unboxed).
We might want some protection to avoid linking together code compiled with old and new modes, or using the wrong runtime system.
Let me quote a comment from @garrigue on https://www.lexifi.com/blog/about-unboxed-float-arrays. If course, this improvement can come later.

This is just a reminder that the special representation of float arrays is also the reason we cannot
have a Top type in OCaml. Recovering Top would allow to generalize not only covariant type
variables but also contravariant ones.

lpw25 · 2017-08-23T08:43:18Z

Recovering Top would allow to generalize not only covariant type variables but also contravariant ones.

Beyond that it would also allow generalizing all covariant type variables, rather than just "strongly covariant" ones.

bluddy · 2017-08-23T18:18:44Z

Recovering Top would allow to generalize not only covariant type variables but also contravariant ones.

Beyond that it would also allow generalizing all covariant type variables, rather than just "strongly covariant" ones.

I'd love some explanation of this for those of us not as well-versed in type theory.

First, @garrigue's comment: how does the float optimization prevent us from using top (the universal supertype)? Does it apply only to subtyping in OCaml ie. row types? Second, @lpw25's comment: what is the current limitation with regard to strong covariant types?

damiendoligez · 2017-08-31T16:27:59Z

New version with bugs removed and primitives added. @alainfrisch

alainfrisch · 2017-09-06T14:04:39Z

bytecomp/translcore.ml

    | (Parraysetu Pgenarray, p1 :: _) -> Parraysetu(array_type_kind env p1)
    | (Parrayrefs Pgenarray, p1 :: _) -> Parrayrefs(array_type_kind env p1)
    | (Parraysets Pgenarray, p1 :: _) -> Parraysets(array_type_kind env p1)
+    | (Parraylength Paddrarray, [p])


Why is this chunk needed?

As evidenced by testsuite/tests/translprim/array_spec.ml, without this code we lose some type specialization: without -no-flat-float-array, the compiler will specialize some accesses from gen to int, while with the option they are not gen but addr, and the compiler doesn't specialize them. This block of code recovers this optimization in the -no-flat-float-array case.

Where does this specialization from gen to int happen? Woudl'nt this be the place to change to make it happen from addr to int as well? (Sorry if I miss something obvious.)

Well... it happens right here in this pattern matching.

Ok, yes, sorry. I would find it easier to follow if the cases were merged:

| (Parraylength old_kind, [p]) -> Parraylength(cap_array_kind old_kind (array_type_kind env p))

mshinwell · 2017-09-14T11:22:57Z

asmrun/spacetime_snapshot.c

  v_time = allocate_outside_heap_with_tag(sizeof(double), Double_tag);
  Double_field(v_time, 0) = time;
+  /* CR doligez: either this will have to change for no-flat-float-array,
+     or the ML-side type will change to floatarray */


These are just supposed to be floats, not float arrays -- I think I may have used the wrong macro here. Could you fix it? (I think you can remove the CRs then.)

mshinwell · 2017-09-14T11:24:10Z

Makefile

 	    -e 's|%%WITH_PROFINFO%%|$(WITH_PROFINFO)|' \
 	    -e 's|%%WITH_SPACETIME%%|$(WITH_SPACETIME)|' \
 	    -e 's|%%WITH_SPACETIME_CALL_COUNTS%%|$(WITH_SPACETIME_CALL_COUNTS)|' \
+	    -e 's|%%FLAT_FLOAT_ARRAY%%|$(FLAT_FLOAT_ARRAY)|' \


I think it might be more descriptive and less potentially confusing, for the C defines and the variable in Config, to just use float_array_hack.

I didn't want to use "hack" because it has a negative connotation.

I would argue that the most important thing is to have a name that really won't be confused with anything else. There are various different concepts in the code now relating to various kinds of "float array"s and the risk of accidental confusion is I suspect quite high. The "float array hack" may not be the ideal term, but it is the standard terminology, and so seems the right thing to me.

@mshinwell: I do find the "hack" terminology offensive, and it is "standard" only in your mind. Do you still want to argue pointlessly?

The only other option I could think of was float array optimization, but then you need to contract it to float_array_opt or some such thing and it can be confused with option.

(The thinking is that maybe "unboxed" is a more common term for this kind of representation than "flat". I suppose if doing that it would make sense to rename "flat" to "unboxed" throughout the patch.)

Before I start renaming everything, @xavierleroy do you agree with unboxed?

MAGICALLY_UNBOXED_FLOAT_ARRAY? (It's not like we're getting rid of unboxed float arrays.)

The intention of UNBOXED_FLOAT_ARRAY (same for FLAT_FLOAT_ARRAY, I imagine, too) is that it means "unboxed float array" (as opposed to "unboxed floatarray"). As such I'm not sure any extra qualification is needed.

But they're both unboxed/flat, and that's where the confusion stems from. The difference is that one is demarcated by the type system, and one isn't.

mshinwell · 2017-09-14T11:24:55Z

bytecomp/symtable.ml

+      let res = Array.Floatarray.create (List.length fields) in
+      List.iteri (fun i f -> Array.Floatarray.set res i (float_of_string f))
+        fields;
+      Obj.repr res


Two things:

Can we change Array.Floatarray to Float.Array? (Then we can also add Float.pi which will close another GPR too.)

This is Float.Array.of_list, let's just move the code to the stdlib.

Not yet, because there is no Float module in the stdlib. But I agree this naming is temporary.

Is there a reason we can't introduce a Float module? Otherwise we'll be stuck with Array.Floatarray for evermore, no?

No, in this PR it contains only the minimum needed to patch the compiler and to experiment with the new type. No reason we can't move or duplicate it to a proper stdlib module when we decide the option should be the standard.

mshinwell · 2017-09-14T11:25:57Z

byterun/array.c

 #undef Restore_after_gc
  Store_double_val(res, d);
  return res;
+#else /* FLAT_FLOAT_ARRAY */


This comment is confusing -- it looks like the "else" branch is when the float array hack is enabled, which it's not.

(This has been addressed)

mshinwell · 2017-09-14T11:26:34Z

byterun/array.c

  return (Tag_val(array) == Double_array_tag);
 }

+/* [ 'a array -> int -> 'a ] where 'a != float */


I think this comment is wrong when the float array hack is disabled: in that case, 'a can be float. (At least one other occurrence of this below.)

These comments are intended to be true in both cases, as a guide to write C code that works with and without the option.

Could you perhaps clarify the comments along those lines? I think it's potentially misleading at the moment.

mshinwell · 2017-09-14T11:29:51Z

byterun/array.c

    }
  }
+#else
+  return init;


This might be worth a comment explicitly noting that a copy is not required, since the name of the function makes it sound like it should always copy. Or maybe you should change the name of the function, in fact.

(This has been addressed)

mshinwell · 2017-09-14T11:30:25Z

byterun/minor_gc.c

-        if (!vv || ft == Forward_tag || ft == Lazy_tag || ft == Double_tag){
+        if (!vv || ft == Forward_tag || ft == Lazy_tag
+#ifdef FLAT_FLOAT_ARRAY
+            || ft == Double_tag


You also need to update the comments in stdlib/lazy.ml.

(This has been addressed)

mshinwell · 2017-09-14T11:31:34Z

byterun/interp.c

    Instruct(GETFLOATFIELD): {
      double d = Double_field(accu, *pc);
+      /* CR doligez: change to Double_flat_field ? Need to check how the
+         compiler uses this instruction. */


I think these are only used for accesses to values known to have tag Double_array_tag. (So yes.)

mshinwell · 2017-09-14T11:32:42Z

byterun/caml/mlvalues.h

-#define Double_field(v,i) Double_val((value)((double *)(v) + (i)))
-#define Store_double_field(v,i,d) do{ \
+
+/* The [_flat_field] macros are for [floatarray] values and float-only records.


Somewhere there should be a note observing that record types "obviously of all floats" are still represented using tag Double_array_tag. There may otherwise be a misconception that this optimisation has also been removed.

(This has been addressed)

damiendoligez · 2017-09-14T15:19:38Z

@mshinwell @alainfrisch I have changed the code according to most of your comments and answered the others.

mshinwell · 2017-09-14T17:02:00Z

I will read the new diff first thing tomorrow, Friday.

mshinwell · 2017-09-15T09:07:44Z

byterun/interp.c

-      double d = Double_field(accu, *pc);
-      /* CR doligez: change to Double_flat_field ? Need to check how the
-         compiler uses this instruction. */
+      double d = Double_flat_field(accu, *pc);


I think you missed the SETFLOATFIELD case (below).

DemiMarie · 2017-09-15T14:53:17Z

I wonder if it would be possible to use a limited form of monomorphization to bring up the performance of polymorphic code, at least when the entire program is available. OCaml as a language does not allow full monomorphization, but in many cases I suspect that it should be possible.

damiendoligez · 2017-09-15T14:56:33Z

It's not just a question of performance, though. There is also typechecker complexity and runtime-system complexity. It also spills into the type system itself (see the remark about the top type) and in strange places like restrictions on let rec and [@@unboxed].

mshinwell · 2017-09-15T15:04:19Z

@damiendoligez For avoidance of doubt I'm happy with this now once you fix the SETFLOATFIELD case. I'd rather see the name change as discussed above, but that's up to you.

mshinwell

OK subject to SETFLOATFIELD fix as per other comment

bluddy · 2017-09-15T15:27:16Z

The gain versus using an explicit Float.Array or a functor over the Array signature (or using modular implicits over the Array signature) is fairly minimal, especially with flambda.

Not sure about this claim. I don't think it's practical in OCaml, but it's Rust's approach, and Rust is the fastest language out there right now. They have other tricks up their sleeves, but this is one of the big ones.

mshinwell · 2017-09-15T15:49:46Z

This all looks fine to me now.

alainfrisch · 2017-09-15T16:08:59Z

What are the next steps?

The current API for Array.Float is clearly not ready for prime time (many missing functions, and there is agreement on the name of the module). Should we start working to complete this part?
There hasn't been much discussion about possible migration strategies. But it seems critical to the success of the switch to offer tools to help with the migration: compilation/runtime warnings or external tools when generic arrays are used on floats; perhaps a mode where floatarray is an alias for float array?
One of the benefits of the change is to simplify some tricky parts in the compiler code base. This means planning for the actual removal of the original mode. This won't happen overnight, but before embarking on the journey, it would be good to hear about @xavierleroy's position on the matter. It could make sense to say that "we will try and see if the community switches", but if we don't send the signal that the goal is to get rid of the old mode, we remove some incentive for the community to switch.

lpw25 · 2017-09-15T16:12:07Z

They have other tricks up their sleeves, but this is one of the big ones.

I'm pretty sure unboxing floats in arrays is not the source of Rust's performance. In fact Rust doesn't do the suggested optimisation -- they monomorphise everything but they don't use that to optimise unboxing, the user indicates what data to unbox by hand themselves.

lpw25 · 2017-09-15T16:18:20Z

they monomorphise everything but they don't use that to optimise unboxing

This statement is probably confusing. I mean they do not take advantage of monomorphisation to optimise the layout of data in memory, a la Mlton. Instead the user has complete control over how data is represented.

damiendoligez · 2017-09-15T16:24:10Z

@alainfrisch The next step is benchmarking.

alainfrisch · 2017-09-15T16:30:53Z

Did you merge on prupose? At least we should say that Array.Float is experimental, no? Or are we confident that this module will only be extended but not be moved or renamed?

bluddy · 2017-09-15T16:33:43Z

Will we be ok with breaking software using Array.Float when the time comes to switch to Float.Array?

damiendoligez · 2017-09-18T16:27:48Z

We can keep Array.Floatarray with a [@@deprecated] flag when we add Float.Array.

alainfrisch · 2017-09-18T17:03:49Z

Ok, I missed that Array.Floatarray is explicitly excluded from the documentation, and should thus not be relied upon.

The next step is benchmarking.

Do you agree that benchmarking numerical code is rather useless (performance sensitive code bases make sure to avoid generic accesses, and will need to be rewritten to use floatarray and regain exactly the same performance as today)? It would indeed be interesting to get numbers from non-numerical code using arrays intensively to see the gains. Coq?

xavierleroy · 2017-09-18T17:41:37Z

Do you agree that benchmarking numerical code is rather useless

I disagree. I'd like to see numbers for OCaml code as it exists today in the wild, not for future rewrites of this code. That will help determining how much code needs rewriting, among other things.

It would indeed be interesting to get numbers from non-numerical code using arrays

I agree we need numbers both for numerical and symbolic code.

bluddy · 2017-09-18T18:05:17Z

As an aside, with floatarray code, it should be relatively easy to start generating vectorized instructions, which should significantly improve performance. Perhaps we want to create annotations for this purpose as a simple first measure.

xavierleroy · 2017-09-18T18:11:13Z

with floatarray code, it should be relatively easy to start generating vectorized instructions

No easier than today with float array.

DemiMarie · 2017-09-19T17:54:23Z

Correct. One of Rust’s biggest wins is that everything is (by default) a value type with move semantics. This includes mutable ones, which can avoid boxing. It would be much easier to write high-performance OCaml if it had monomorphization and value types. OCaml's type system doesn't allow full monomorphization, but I suspect that some would be possible if the entire program was available. (Rust has other tricks up its sleeve, too. For instance, every higher-order function that takes a closure generically - most do - has a fresh copy generated specialized to each closure passed to it. That, combined with no implicit boxing, means that higher order Rust often has zero performance penalty).

…

On Sep 15, 2017 12:20 PM, "Leo White" ***@***.***> wrote: they monomorphise everything but they don't use that to optimise unboxing This statement is probably confusing. I mean they do not take advantage of monomorphisation to optimise the layout of data in memory, a la Mlton. Instead the user has complete control over how data is represented. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1294 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB0HeFO9cJZQXGZdCa_7RaXvlghgeks5siqNSgaJpZM4O7Thf> .

ejgallego · 2017-11-18T00:57:48Z

@gasche suggested to try Coq with the -flat-float-array. Here are some preliminary results for building Coq's stdlib:

Time{4.06.0                   |master}: 237.319752
Time{4.06.0+flambda           |master}: 216.754369
Time{4.06.0+flat_float        |master}: 238.061874
Time{4.06.0+flambda+flat_float|master}: 218.273305

I guess Coq could also really benefit from some more [@@inline ...] annotations, I think @ppedrot wanted to add a few.

gasche · 2017-11-18T08:07:44Z

@ejgallego I should have given more information, sorry. I think that the -flat-float-array option corresponds to the default (float arrays are "flat" because they are unboxed), what you should measure is the -no-flat-float-array switch which performs the non-standard behavior of disabling unboxed float arrays.

(You can test either (4.06 -flat-float-array against 4.06 -no-flat-float-array) or (4.06 against 4.06 -no-flat-float-array).)

ejgallego · 2017-11-18T14:43:46Z

Indeed sorry, I got it right at first but then got confused when feeding my bench script. Relaunching.

ejgallego · 2017-11-18T16:23:18Z

No significative change in timing that I could observe when using -no-flat-float-array.

gasche · 2017-11-18T16:25:46Z

cc @ppedrot: this is a flag to disable the float-array optimization (and correspondingly speedup generic array creation and access), and it preliminary testing suggests that it does not seem to change Coq performances (on the stdlib). Do you think there is a test that would reveal a speedup for Coq users? Do you know which OCaml functions are critically more expensive this way (maybe those don't take the flag into account properly)? Do we need to revert some of your manual library-specialization work to see the difference?

ejgallego · 2017-11-18T16:30:02Z

@gasche I have added this particular flag to the main benchmark script so soon it will get tested against quite a few 3rd party developments, that should provide us with some more data as their performance profile is fairly diverse.

bobzhang · 2019-12-14T12:40:21Z

Is this configuration used in some production environment (heavily tested)?

bluddy reviewed Aug 21, 2017

View reviewed changes

alainfrisch added the work-in-progress label Aug 23, 2017

alainfrisch reviewed Aug 23, 2017

View reviewed changes

damiendoligez force-pushed the float-hack-option branch from 1eed20d to 485cd65 Compare August 31, 2017 16:27

alainfrisch reviewed Sep 6, 2017

View reviewed changes

lpw25 mentioned this pull request Sep 11, 2017

Remove float array optimisation #163

Closed

damiendoligez removed the work-in-progress label Sep 13, 2017

mshinwell requested changes Sep 14, 2017

View reviewed changes

mshinwell reviewed Sep 15, 2017

View reviewed changes

mshinwell added the consider-for-release label Sep 15, 2017

mshinwell approved these changes Sep 15, 2017

View reviewed changes

add bootstrap compilers

eb21925

damiendoligez force-pushed the float-hack-option branch from 950dd0b to eb21925 Compare September 15, 2017 15:54

damiendoligez merged commit c11d94c into ocaml:trunk Sep 15, 2017

damiendoligez deleted the float-hack-option branch September 22, 2017 11:56

yallop mentioned this pull request Feb 27, 2018

Add Stdlib.Float module #1638

Merged

This was referenced Mar 15, 2019

Syntax to specify that a custom type is never a float #5361

Closed

Adding an attribute for abstract types that are not float / lazy #7485

Closed

bobzhang mentioned this pull request Dec 14, 2019

Ideal unboxed support rescript-lang/rescript#4044

Closed

craigfe mentioned this pull request May 4, 2021

[API suggestion] Avoid ~dummy flag in favour of Obj.magic backtracking/vector#1

Open

Conversation

damiendoligez commented Aug 18, 2017

Uh oh!

lpw25 commented Aug 18, 2017

Uh oh!

damiendoligez commented Aug 18, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alainfrisch Aug 23, 2017 • edited by damiendoligez Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alainfrisch commented Aug 23, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lpw25 commented Aug 23, 2017

Uh oh!

bluddy commented Aug 23, 2017

Uh oh!

damiendoligez commented Aug 31, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alainfrisch Aug 23, 2017 •

edited by damiendoligez

Loading

alainfrisch commented Aug 23, 2017 •

edited

Loading

bluddy Sep 14, 2017 •

edited

Loading

damiendoligez Sep 15, 2017 •

edited

Loading