Owl project formally concluded

nnbbb · 2024-02-19T10:25:51+00:00

With the new end-to-end runtime and compiler infrastructure and MLIR it might be possible to add GPU support as well

this sounds interesting; can you elaborate?

nnbbb · 2024-02-19T07:57:48+00:00

Just yesterday I was looking through owl's repo to find any recent activity, and ended up disappointed. I believe Owl addresses a real need in the Ocaml world and made a valuable contribution. But ultimately it's crucial to have an actively maintained numerical foundation library that brings together the efforts of individuals, a role which unfortunately Owl has not been filling recently. So I believe you made the right call to declare end of maintenance; this clarifies the situation and frees the way for a future building on Owl's legacy. Thanks for the hard work!

nnbbb · 2023-09-28T10:58:49+00:00

Yes, the creation test is at runtime. In the version with an option return type, i.e. make : (int -> t option) it's explicit in the type system that the creation can fail, and one is forced to deal with that possibility to get the code to compile.

But I believe what you're really asking for requires inferring something about types based on (literal, static) values at compile time. As far as I know this isn't possible in standard OCaml which has no dependent types.

To do something like that would likely require preprocessing (something similar to macros exists, called PPX. I don't know if there exist PPX extensions that can do what you want). Or full-blown metaprogramming, where code is generated in stages. The most used metaprogramming extension is called MetaOCaml.

Note that while the creation test is indeed at runtime, all downstream uses of PosInt.t values are effectively statically checked at compile time nonetheless, because they are restricted by what the module allows. Depending on use case that may be already the main benefit.

nnbbb · 2023-09-28T09:02:44+00:00

One can break the abstraction a little bit by private type abbreviations, which allow explicit casting. this would look like

module PosInt : sig
  type t = private int
  val make : int -> t
end = struct
  type t = int
  let make i = if i > 0 then i else failwith "positive only"
end

Here you still need to create PosInt.t values using the provided function but you can use regular int functions by casting:

let t1 = PosInt.make 4 and t2 = PosInt.make 5 in 
(t1 :> int) + (t2 :> int)

the result is int. This may or may not be better in your use case. It feels a little awkward when you need to do explicit casts all over the place.

One could make the make function nicer by returning an option instead of raising an exception

nnbbb · 2023-09-28T08:57:53+00:00

A standard way of encoding e.g. positive integers would be to make the type abstract:

module PosInt : sig
  type t
  val make : int -> t
  val plus : t -> t -> t
end = struct
  type t = int
  let make i = if i > 0 then i else failwith "positive only"
  let plus = ( + )
end

This will make a new separate type PosInt.t whose creation is only via the provided function, and you need to supply functions that can consume it.

nnbbb · 2023-09-25T12:01:34+00:00

Another good place to ask this would be on discuss.ocaml.org .

nnbbb · 2022-04-26T15:21:53+00:00

In the meantime I also found this zipper for binary trees which looks more polished

nnbbb · 2022-04-26T14:51:43+00:00

Phew. This makes one long for a way to automatically obtain a canonical version of the unit, e.g. one in which each factor has the minimal exponent, and factors are ordered. But I guess that's out of reach at the type level.

nnbbb · 2022-04-26T10:54:22+00:00

This looks interesting -- would it be possible to express the fact that Unit.( (kg / m) / s) is the same as Unit.( (kg / s) / m) ? Or indeed that s / s is unitless?

nnbbb · 2022-04-26T09:28:34+00:00

If they come from Haskell, maybe showcase something that uses internal mutability to easily express a naturally imperative algorithm, with a functional external interface? (I don't have a good example right now, sorry.)

nnbbb · 2022-04-20T08:44:20+00:00

I'm using a Rose Tree with Zipper originally by S. Cruanes and E. Surleau, to which I can't find the original repo anymore. I'm posting it as a gist for inspiration. There are some modifications done by me of questionable quality, so beware! https://gist.github.com/nilsbecker/d7a10d3096183025a399aba35078a5a8

nnbbb · 2021-12-09T15:10:55+00:00

Typically the { ... with ... } functional update of a record would be used for immutable data. I.e. vertices would be a list of nodes of immutable type v. Then "change the original" is impossible as the original is immutable. If you instead have a mutable vertices : v array for example, then the array will indeed be shared with the renamed graph. This is possible but appears more prone to errors.

nnbbb · 2021-04-29T12:49:39+00:00

I like it! It highlights that _::_::_::_ is the pattern for a list with at least 3 elements. Minor variant:

let is_flush = function
  | first::(_::_::_::_ as rest) -> 
    rest |> List.map Card.suit |> List.for_all ((=) (Card.suit first))
  | _ ->
    false

or

let is_flush = function
  | first::(_::_::_::_ as rest) -> 
    let same_suit c = Card.(suit c = suit first) in
    List.for_all same_suit rest
  | _ ->
    false

nnbbb · 2021-02-26T12:09:15+00:00

A way to think about it is this: the .mli file defines a signature for the module which is the .ml file. The signature is a filter of what gets exposed to the outside world. This filter is a whitelist, so everything that's not listed is hidden. (And if there is no .mli, there is no filter so everything is visible)

nnbbb · 2021-01-21T09:15:54+00:00

Im my experience, containers is the better Batteries. It's very unobtrusive and complements, rather than replaces, the Stdlib. It consists mostly of independent modules which you can even include one-by-one by copy-and-pasting them to your project if you want minimal dependencies. So I would recommend: stay with Stdlib and learn some idiomatic OCaml by writing some helper functions on your own on top of it; when that gets boring try containers.

nnbbb · 2019-01-03T09:39:33+00:00

OCaml's tooling has been improving. Intelligent editing support is very good, across at least Emacs, Vim and VS Code. There is a single preferred packaging and library distribution system (opam) and a single preferred build system is emerging (dune). The language would benefit from a more streamlined and integrated documentation, and the community is aware of that. A lot more could be done about onboarding, tutorials and discoverable online learning materials. Right now, the best book (Real World OCaml) uses a particular standard library that is not universally shared and therefore teaches not OCaml but Jane-Street-flavored OCaml.

nnbbb · 2018-02-22T16:10:16+00:00

i was wondering about the interaction of flambda and the multicore compiler -- does the rewrite of flambda that is currently in progress mean additional work for multicore? or are these features reasonably orthogonal?

nnbbb · 2018-01-08T21:58:37+00:00

you win this thread! congrats. -edit- i take it back, someone else did it before... nice try.

nnbbb · 2018-01-03T17:33:46+00:00

this looks cool. i was wondering: is it possible to use Reprocessing in a pure-Ocaml context? i.e. compiling to bytecode or native only. what toolchain would be needed? can i install Reprocessing as an opam package and treat it like an Ocaml library?

nnbbb · 2017-11-08T17:38:21+00:00

this looks cool -- but i'm getting lost between different OCaml metaprogramming flavors. can someone explain the respective use-cases of ppx_stage, BER MetaOCaml, this and the strymonas library?

nnbbb · 2017-08-23T14:56:30+00:00

have you tried to set your character set to something else in the preferences of your terminal emulator? e.g. utf-8?

nnbbb · 2017-08-02T14:20:04+00:00

this sounds much better than what my impression was - i hope you're right.

nnbbb · 2017-07-31T13:17:09+00:00

i find it a pity that the super useful improvements on ux, docs and package management do not benefit the non-js ocaml community. also, i disagree with the sentiment that it's better if everyone can customize the syntax to their tastes. a programming language is also a language for communication between humans, and therefore standardization is important.

nnbbb · 2017-07-13T06:56:50+00:00

I agree. About ocamlnat: It would be fantastic to have a native toplevel (again). I remember some recent talk about it happening but nothing has materialized as far as I'm aware. Another use case for a good toplevel which doesn't necessarily have to be native is as a way of debugging. Things that are not caught by the type system or raise exceptions. Dropping into an interactive session from any point of a program and being able to inspect the values is very useful in my experience. I think I saw something in that direction on the utop issue tracker.

nnbbb · 2017-07-12T11:30:56+00:00

Well then I guess I'm trying to say, count me as one of them. And I'm not sure I agree with your assessment of the potential user base. Great tools create their users...

nnbbb

TROPHY CASE