caml-list - the Caml user's mailing list
 help / Atom feed
From: Malcolm Matalka <>
To: caml-list <>
Subject: [Caml-list] Unboxed types in Ocaml
Date: Fri, 25 Oct 2019 19:18:04 +0200
Message-ID: <> (raw)

I just watched the following video[0] given by Stephen Dolan, and I
really enjoyed it.  I think performance is something that most anybody
can appreciate the value of and has been effected by.  I have a few

- Given the content of the talk I don't disagree (nor feel qualified to
  disagree) with the proposed solution.  I wonder though: are the range
  of layouts so numerous to support an additional syntax?  The three
  layouts shown are value, immediate, and bit#, and tuples of them, are
  there other ones though?  Is there a clear logical extreme this has?
  Are there other types information that will cleanly fit into this way
  of expressing meta information things (maybe linear typing?)?  Also, I
  look at ATS which has a whole lot of type modifiers and seems kind of
  zany, is there anything we should keep in mind to keep Ocaml from
  going nuts with the modifiers?

- One reason I really liked this approach is because it touches on
  something that has been bothering me in high-level languages for
  awhile, and that is in order to get a high-level language to have
  certain performance characteristics you often have to do these
  incantations that are pretty related to how the optimizer works.
  Ocaml has plenty of these if one reads the Jane St doc on it.  And
  while it's nice to be able to get code to be performant, it's also
  really fragile.  The next programmer to come along in that code may
  not be aware it's structured in a particular way for performance
  reasons.  They also might need to make a change and not have the
  knowledge of how to change the code in a way that maintains those
  characteristics.  Or the compiler could change and invalidate that
  pattern.  What's great here is instead of structuring code in a way
  that you feel pretty sure the compiler will unbox the values, you tell
  the compiler and, most importantly, you get a compilation error if you
  do something wrong.  There is no ambiguity.  I know that is different
  than if one gets the performance characteristics they expect, but at
  least they know that what they intended to happen to the values
  actually happened.  This seems like a first step in moving knowledge
  that is meaningful to people about performance into the compiler, are
  there other opportunities for this in the language as well?  I think
  Ocaml already does a great job of being high-level, performant, and
  having a run-time that you can understand, so I wonder if it is well
  positioned as a language where these sort of changes could come into
  it and be impactful.

- Any idea on when this might be coming to a release near me?



             reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 17:18 Malcolm Matalka [this message]
2019-11-03 16:03 ` SP

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror

AGPL code for this site: git clone public-inbox