
Fantasy World OCaml (2013) - a0
http://chaudhuri.info/misc/fwocaml/
======
jeffreyrogers
I'm surprised that better threading wasn't mentioned. As I understand it,
OCaml has threads but parallelism isn't possible. That is, although you can
have multiple threads, only one can execute at a time.

~~~
jallmann
#5 of Build Tools and Runtime would cover that (encapsulating all global state
into a runtime context). The ongoing multicore work at OCamlPro is taking this
approach [1].

Erlang-style actors or lightweight processes would be my dream multicore
scenario (no more monads for concurrent IO!), but that's likely too difficult
to graft onto the current runtime, which is otherwise extremely well-done.

Also, I'd really like checked exceptions. The omission of checked exceptions
has always struck me as strange, given the emphasis on compile-time checking.
Considering how fast exceptions are in OCaml, it seems like a bit of a missed
opportunity -- it is faster to use exceptions for control flow [2] than
matching on variants (such as Option), which usually involve an extra
allocation + dereference, IIRC.

[1] [http://www.ocamlpro.com/pub/multi-
runtime.pdf.tar.gz](http://www.ocamlpro.com/pub/multi-runtime.pdf.tar.gz)

[2] Odd as it may sound, it's encouraged to use exceptions as a control-flow
construct in OCaml, but that is falling out of favor in modern code as far as
I can tell.

~~~
rwmj
Checked exceptions are possibly the worst feature of Java.

Now it may be a good idea to have an optional tool for checking exceptions --
in fact, one exists already, but I can't recall the name of it. But please
don't make this mandatory unless you avoid the mistakes of Java.

~~~
danieldk
_Checked exceptions are possibly the worst feature of Java._

Why? I absolutely hate C++ codebases where all of a sudden you get yet another
type of exception that was not documented, possibly because the exception was
thrown ten functions down (up) the stack.

In Java, at the very least you know what to expect and can prepare for it.
Unfortunately, even there people try to avoid exceptions by throwing classes
that derive from RuntimeException.

Given that Java has no sum types, checked exceptions are really the next best
thing.

------
talex5
Generally sensible, but a few things seem already fixed.

The duplicate argument thing already generates a warning (I wish warnings were
enabled by default though):

    
    
      # let f x x = x;;
      Warning 27: unused variable x.
      val f : 'a -> 'b -> 'b = <fun>
    

"Values of type string and bytestring are not mutable." In 4.02, strings can
be made immutable (it's optional currently, to avoid breaking existing code).

Camlp4 is already on the way out, being replaced by Extension Points.

Rather than adding checked exceptions, I'd rather just see more use of
variants in the standard library (3rd-party libraries mainly do this already).
I don't see why checked exceptions should be faster - maybe this is just a
compiler optimisation problem?

------
lpw25
Most of these things seem nice but are actually a bad idea. Many of the rest
are already implemented or in the process of being implemented. A couple of
them are good ideas which are awkward to implement due to politics (e.g. the
licence) or backwards compatibility.

Still, I enjoyed reading the post, and it is good to see people looking to
improve OCaml and make suggestions.

~~~
codygman
Can you list some specifics that seem nice but are actually a bad idea? I
would be interested and I'm sure others would be too.

------
PieSquared
I would be interested in seeing a similar list for Haskell. Like OCaml, it's a
great language, but definitely has a few long-standing warts that could be
fixed. (Among these, the many competing streaming libraries and cabal hell
come to mind. Though maybe the first ain't so bad, since they are all pretty
high-quality.)

~~~
tel
I think there's a big difference between language issues (which are routinely
being worked on) and community questions like the pipes libraries and cabal.

Probably the two biggest problems, both of which are currently being worked
on, is a solution to true modules/modular dependencies (which is highly
beneficial to fixing the community problem of cabal hell) and a solution to
the "record problem" which is probably going to come in a new GHC extension
which automatically allows for structural subtyping on public records via row
types.

~~~
plinkplonk
"Probably the two biggest problems, both of which are currently being worked
on, is a solution to true modules/modular dependencies "

I'm looking forward to this. I have Haskell code in production and would
_greatly_ appreciate these features. Is there a url where I can check/follow
for the state of these efforts? Who is working on these? Thanks in advance.

~~~
tel
Edward Z Yang[0] is doing a GSoC project (I think) on expanding
Backpack[1][2]. He's a GHC contributor, so it's relatively big.

And here's overloaded record syntax: [http://www.well-
typed.com/blog/84/](http://www.well-typed.com/blog/84/)

[0][http://ezyang.com/](http://ezyang.com/) [1][http://plv.mpi-
sws.org/backpack/](http://plv.mpi-sws.org/backpack/)
[2][http://blog.ezyang.com/2014/07/type-classes-confluence-
coher...](http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-
global-uniqueness/)

------
rwmj
I would like to see a 'return' statement added to the language, so that:

    
    
        fun () ->
          if foo then return r;
          more code ...
    

is the equivalent of:

    
    
        fun () ->
          if foo then r
          else more code ...
    

Note that type safety would obviously have to be preserved. The returned type
would have to match the return type of the overall function.

~~~
tel
I think this is pretty intentionally avoided most of the time since it
clutters up the continuation-passing semantics of the code... With `return`
you have a much more complex base language. Especially since you can achieve
it using monads.

~~~
rwmj
Monads don't (quite) short-circuit the later computations unlike a return
statement. Anyway, I'd like to see an example of writing this using monads,
since it makes the idea more concrete.

~~~
tel
I can write a continuation monad in Haskell which would. Something like

    
    
        {-# LANGUAGE DeriveFunctor #-}
    
        module Return where
    
        import Control.Monad
    
        newtype Cont r a = Cont { runCont :: (a -> r) -> r } deriving Functor
    
        instance Monad (Cont r) where
          return a = Cont (\k -> k a)
          m >>= f  = Cont (\k -> runCont m (\a -> runCont (f a) k))
    
        early :: r -> Cont r a
        early a = Cont (\_ -> a)
    
        ex :: Cont Integer [Integer]
        ex = do
          forM [1..] $ \i -> do
            when (i == 33) (early i)
            return i

~~~
Peaker
Why Cont when Either would do?

~~~
tel
True, but I mentioned continuation-passing semantics! Peaker's right
though—and Either might be a little easier to understand.

------
microcolonel
Unicode support is the biggest problem I have with OCaml, and it's something I
noticed immediately as I tried to put in messages and keywords for a japanese
friend.

It may not be wise to break current behaviour of the char and string types,
but their literals should at least support unicode escapes. One way to do this
would be to bring in UCS-4/UTF-32 strings as offered by Camomile, and have
some simple convention to allow UCS-4 strings to be mapped from what are UTF-8
literals in the code.

~~~
rwmj
I prefer that OCaml _doesn 't_ support Unicode in the core language, and that
it's left to Camomile to support.

One reason is that it's very hard to get it right -- see how complex Perl 5 is
which is about the only language that does do the right thing. Another reason
is that baking an incorrect Unicode into the language would be worse than the
current situation. For examples of brokenness, see: all of Win32, Java, Ruby.

It would be good to remove the broken String.lowercase and String.uppercase
functions from the stdlib though.

Edit: Although perhaps your problem was more to do with supporting arbitrary
binary in the source files (which instead are encoded as ISO-8859-1). That
would be something to fix.

~~~
tel
Haskell has its Text library type. Which is a great example of how complex UTF
done right can be... And how it can be done quite nicely as a lib. String
literal overloading is pretty important (and library-level rare) though.

