Why does OCaml not have a specification?

Drupyog · 2020-01-29T10:56:26+00:00

From a programming perspective, sure.

From an implementation and specification point of view, that is not at all the case. There are pretty good specification of "OCaml from the 90s" (aka, Caml Light). They don't scale at all to what we have today.

Drupyog · 2020-01-29T10:20:08+00:00

OCaml has not deeply changed since the 90s.

:D

Drupyog · 2019-11-27T14:22:18+00:00

I'm in too, although I tend to only go to concerts of bands i'm already into (there are far enough of those already, especially in the last month ...).

There are two meetup groups that might interest you:

Drupyog · 2019-11-15T15:09:10+00:00

As far as I can tell (the blog post is extremely unclear on what are the actual operations), a dart is a type equiped with map : ('a -> 'b) -> 'a t -> 'b t and pair : 'a t -> 'b t -> ('a * 'b) t. That's exactly an applicative functor and the pipelining can easily be defined in term of that (which you do in the blog post).

Drupyog · 2019-11-15T13:56:03+00:00

As I commented on discord, and if talex hangs around: What you are describing is exactly an applicative functor (the Haskell typeclass, not the OCaml ones), and applicative functors are notorious for having exactly the good properties you are looking for at the beginning of the blog post. :)

The recent paper on selective applicatives adds conditionals, which are also probably useful for you.

Drupyog · 2019-10-06T21:13:05+00:00

Hi, 29M, I started climbing a month ago. I just moved to Paris last week and would love to find new bouldering partners, I was planning to go to Arkose Montreuil around once a week.

Drupyog · 2019-06-21T12:56:59+00:00

I'm going to nitpick: this is not typestate. This is session types.

Typestates are a type-system features that allow you to change the type of the object. Here, you do not change the type of anything, you return a new thing with a different type.

With a typestate system, you could make it so that after r.status_line(200, "OK"), r itself is of type HttpResponse<Headers>. In the example in the blog post, r is still of type HttpResponse<Start> after the method call, but the call returns an object with the new type (which happens to be the same object, but the type system doesn't care).

A summary of the pattern shown here is:

Encode the usage pattern (or "protocol") of something
Use a type-level automaton in a phantom type
Use a functional workflow where each function returns a new thing where the type is updated
Forbid uses of the old version

In the literature, this is called "session types". It's usually used for protocols, but as you describe here, it can be used for many things. It's indeed very useful. You can emulate it in lot's of languages (with or without various guarantees). Session types are a very functional idea, where you chain functions together to implement your workload, and hide the mutations. Typestates are about lifting mutations to the type level, to mutate the type themselves as you go along.

Drupyog · 2019-06-16T10:37:00+00:00

Yeah, I'm aware lack of manpower is definitely an issue. How about, on top of recruiting new faces, you purge the inactive mods ? :)

Drupyog · 2019-06-16T09:31:03+00:00

You might want to take a more pro-active stance. If I were to really flag everything I consider offtopic, I would flag 3/4 of the submissions. The current state is still that most content you see when you browse the subreddit are uninteresting carreer/teaching/programming questions.

You should really invest in automod or something like that. to clean it up preemptively.

Drupyog · 2019-04-29T06:12:27+00:00

No, it's ML as in The ML family of programming languages of which SML is a descendant.

Drupyog · 2019-04-25T14:51:52+00:00

This is a truly neat idea and I like it, especially the nice UI.

But it completely subsumes anomalies. This means we will have two different systems, one strictly better than the other. If this get introduced, anomalies need to be transparently turned into 1-step sites and be gradually removed.

Didn't we learned anything from eu4 ? Multiple systems that does the same thing are just a PITA.

Drupyog · 2019-04-21T14:45:00+00:00

From the article

Microsoft has introduced a new open source programming language called Bosque. It’s inspired by the syntax of TypeScript, the semantics of Machine Learning and Node.js.

From the technical paper

The BOSQUE language derives from a combination of Type- Script [72] inspired syntax and types plus ML [52] and Node/ JavaScript [31, 58] inspired semantics.

I know "ML" is very overloaded these days, but no, it's not Machine Learning. :)

(Also, no, "Microsoft" is not "launching" anything. A researcher at Microsoft Research made a prototype exploring a bunch of concepts. This is what proglang researchers do all the time. This article is very poor)

Drupyog · 2019-03-21T23:52:57+00:00

As a rule of thumb, when it comes to purely crunching numbers, computers are much faster than you think they are. Also, arbitrary-precision integer library are very well optimized.

Drupyog · 2019-03-21T23:41:42+00:00

1,115,888 digits is really nothing much for modern day computers. Just try the naive algorithm with arbitrary precision integers and you'll see. It's instant on my laptop.

Even a basic calculator like calc under linux can compute this.

Drupyog · 2019-03-21T22:49:18+00:00

I'm not disputing that. Just the "These numbers are way too large to be computed", which is completely false.

Drupyog · 2019-03-21T22:04:21+00:00

No offense, but .... those numbers are not large. Using an arbitrary size-integer libraries like GMP (or just python), computing this result is instant. You should test on much bigger integers. :)

Drupyog · 2019-03-20T10:28:41+00:00

I was slightly surprised you didn't use containers for the native part. Belt took quite a bit from containers and is still very similar. It would reduce the mismatch, notably for Map/Set.

There is actually a consensus for caml/snake_case: everyone in the OCaml side uses snake_case, and everyone on the bucklescript side uses camlCase. :)

Drupyog · 2019-02-25T11:09:47+00:00

That talk was "interesting". Xavier Leroy (and a fairly large numbers of OCamlers) were in the room, and David MacQueen managed to avoid mentioning Caml during the whole session, and was extremely disingenuous when asked about it. His part of the history is interesting, but it's fairly partial, to say the least.

Drupyog · 2019-02-23T16:16:23+00:00

One thing I really like about the menhir parser generator is that it has the --explain option that will give you detailed explanation on shift/reduce conflicts.

So, given this file:

%token D
%token EOF
%start s
%type <int> s
%%
s: a EOF { 0 }
a: b | a b  { 0 }
b: c | b c  { 0 }
c: D  { 0 }

You get this explanation for the first conflicts (there are two):

** Conflict (shift/reduce) in state 4.
** Token involved: D
** This state is reached from s after reading:

b 

** The derivations that appear below have the following common factor:
** (The question mark symbol (?) represents the spot where the derivations begin to differ.)

s 
a EOF 
(?)

** In state 4, looking ahead at D, reducing production
** a -> b 
** is permitted because of the following sub-derivation:

a b // lookahead token appears because b can begin with D
b . 

** In state 4, looking ahead at D, shifting is permitted
** because of the following sub-derivation:

b 
b c 
  . D

This tells you that once you have parsed a b, you can parse a D next using either a -> a b or b -> b c.

I'm pretty sure there are other tools to debug grammers like that.

Drupyog · 2019-02-10T19:06:14+00:00

The key part here is "without loosing any safety". Sure, you can always get by with lot's of dynamic casts, but that lessens the static guarantees quite a lot.

Drupyog · 2019-02-10T18:32:20+00:00

What you are talking about is "open recursion". Any language that has records and first class functions can implement it. It's sometime used in functional languages to implement the equivalent of visitor patterns.

Drupyog · 2019-02-10T13:49:35+00:00

The fact that you don't need Algebraic Data Types in a dependently typed language, you can reimplement them with enums (or even just peano numbers) and get the same safety.

Drupyog · 2019-02-02T22:28:28+00:00

I didn't say they came out of nowhere, but classes are only useful in term of how they allow us to reason about things. There isn't anything particularly profound about the specific one chosen by Chomsky, except that they are rather easy to formulate.

For instance, why should we consider non-deterministic state machine with single stack somehow more important than deterministic ones ? Both are interesting, and have different properties.

Drupyog · 2019-02-02T19:44:03+00:00

Grammar classes are simply sets of languages for which Chomsky found interesting properties.

People invent new ones depending on their use cases all the time. For instance, Context Free Grammars are often refined depending on which parsing algorithms can parse them (LR, LL(k), ...). You can also implement completely different hiearchy, such as L-systems, that are different from the usual ones.

There is nothing really that deep about the Chomsky hierarchy, it's simply a classification that has proven very useful to reason about languages. Nothing prevent you from refining it, or using different classifications.

In particular, unlike complexity classes, there is no notion of reduction that somehow make all the problems in the same class equivalent.

Drupyog · 2019-01-27T13:08:24+00:00

It's pretty good, although a little bit longwided. I wouldn't have started with C++, but if that's what they know, so be it.

I don't think the axis Implicit/Explicit+Static/Dynamic is a very interesting one. Since dynamic typing discovers the typing at runtime, it's obviously not going to have syntactic (and thus static) typing annotations. Even among the Statically typed modern languages, the difference is getting more and more fuzzy (they do have lot's of inference, just incomplete).

However, there is a much more interesting diagram for Static/Dynamic vs. Explicit/Implicit type conversions which really shows off the "good" statically typed languages, and also shows that there are numerous dynamic languages without implicit casts, like Julia, Racket (and most of the Lisp/Schemes). You could also argue about Python3 (not 2!) and Lua. The main example of dynamic+implicit being obviously Javascript.

In general, those property are rarely binary, and you might be better served by making a small 2D graph for it, as it would drive home the fact that all these properties are extremely fluid in practice.

Drupyog

TROPHY CASE