Gren

In this post I’m going to show a good example of where laziness would work well. This is of course not an argument that lazy programming languages are somehow better than strictly evaluated programming languages. Rather what I wish to do here is answer the question, what is laziness good for? My example here comes from the justinmimbs/time-extra Elm package. The main purpose of this library is to provide a means for working with the standard library’s Time.Posix values. Functions are provided to calculate the difference between two time values, and also to add/minus a given interval from a given time value. So for example it provides a convenient way to take a given time value and add one day, or two hours, or six months. ...

Imports in most languages always seem like a bit of an add-on, a separate language to the actual language. Today’s post is a thought experiment regarding removing imports from Elm/Gren. Ultimately I think it’s probably worthwhile having the import statements there, but this is an interesting (and quick) thought experiment. If we remove import statements from the head of a module file the first thing to note is that a file then becaomes one module declaration line followed by simply a list of top level declarations. However, we would obviously need someway to refer to values and types defined in another module. ...

There have been a few proposals for extensible custom types in Elm, the idea is that they are somewhat analogous to extensible record types. In this post I wish to give a proposal for how to make custom types ’extensible’ that could play well with opaque types. The key point is that we need not focus on extensibility so much as the distinction between structural and nominal types. The slightly longer summary is to say that we can make custom union types structural types. This means that custom union type declarations are actually type aliases, just as record type definitions are in Elm. Two record types can share the same field, and thus it is trivial to make two record types one of which is a sub-type of the other. Similarly if custom union types are structural, and their associated definitions type aliases, two such custom union types can share a constructor, and again it is trivial to create two custom union type definitions one of which is a sub-type of the other. With this apparatus we can implement opaque types by choosing to expose a type either nominally or structurally, this gives us opaque types in which the underlying type can be a primitive type, a function type, a record type or a custom union type. ...