Ur/web: pure functional, statically typed web programming

C++ has a similar (though more carefully specified) limit on template instantiation depth.

I would be surprised if this were not true in practice for all compiled languages - some programs will be too large to compile given the memory constraints of the machine the compiler is running on.

I think yesod (http://www.yesodweb.com/) manages to achieve a decent amount of this stuff in Haskell.

Note that the Haskell list notation is just syntactic sugar. [2,3,4] gets translated directly into

    2:3:4:[]

It looks more like ML than haskell. But the explicit return of a function and explicit case aren't necessary in ML either, so I'm not sure why they are used here. A quick scan of the reference manual finds mention of currying, but I don't see anything about pattern matching without case statements, so maybe the language doesn't have that.

The map example with toplevel pattern matching is really just sugar for the expanded case statements which isn't that far from the Ur equivalent.

  map :: forall a b. (a -> b) -> [a] -> [b]
  map =
    \ (@ a) (@ b) (ds :: a -> b) (ds1 :: [a]) ->
      case ds1 of _ {
        [] -> [];
        : x xs ->
          (ds,x,xs) : ((ds,x) ds x) ((ds,xs) map ds xs)
      }

It's because the more advanced features that it has over Haskell in type-level computation make its type inference undecidable. http://impredicative.com/ur/tutorial/tlc.html

To be fair, I'm guessing that BazQux is not getting the same amount of traffic as many of the other alternatives. FWIW, I've been using The Old Reader[1] quite successfully since Google Reader went away.

[1] http://theoldreader.com/

I've been using BazQux since the Google Reader close and have been pretty happy with it. I don't think I've noticed a single issue with BazQux so far.

The web interface is actually quite snappy, in contrast to a lot of the overly-designed alternatives I tried out. That said, I generally interface with FeeddlerPro on my phone/tablet rather than directly hitting bazqux.com.

The first thing that grabbed me about bazqux was just how fast and responsive it felt to use. The second thing was that it was the closest replacement to Google Reader I had come across. I'm still using it.

Row types are a way to encode type information of OOP object in a hindley milner type system. It allows you to type check the kind of ducked objects that are often featured in dynamic OOP languages like ruby and javascript. So you may specify a function on a object containing specific fields or methods without specifying a concrete type:

  f :: {left: Number, right: Number} -> Number
  f object = object.a + object.b

All type checked of course.

See here for more info: https://www.cs.cmu.edu/~neelk/rows.pdf

Row types are an alternative to subtyping for record/object types. With subtyping you say that if you have a record Foo and you leave out some fields to get a record Bar then Foo is a subtype of Bar. For example the type {a:int, b:string} is a subtype of {a:int}. This means that if you have a function f : {a:int} -> ResultType, then you can pass a value of type {a:int, b:string} to it, since it has all the required fields. A problem with subtyping for records/objects is that it doesn't work very well with type inference.

With row types you use parametric polymorphism to make the extra fields explicit. You have types of the form {a:int, ...B} where B indicates that the value may have additional fields. In this system you give f the type forall B. {a:int, ...B} -> ResultType.

Row types are more powerful than subtyping in some ways but less powerful in other ways. For example with subtyping you can put two records {a:3, b:"hello"} and {a:5} in the same list. With row types you can't do that (you'd need existential types to do that). It turns out that these restrictions make type inference for row types decidable.

Row types refer to row polymorphism. It's a kind of polymorphism that lets you write code that's generic over different records with different fields without using subtyping.

Lets say you want to write a function that takes anything with a .length field:

    maxByLen a b = if a.length > b.length then a else b

How would you come up with the types for this? In a Java-like system of nominative sub-typing, you would make an interface Length and require types to declare it explicitly. However, this is messy, completely unnecessary and messes up type inference, so it's not a good idea.

You could also use structural sub-typing. You could declare the function to have a type like

    byLength : { length : Int } -> { length : Int } -> { length : Int }

where any record with a field length of type Int has the type { length : Int }. In other words, the type { length : Int, name : String } is a subtype of { length : Int } without needing to declare an interface explicitly. This is a definite improvement over the nominative Java case.

There are a couple of problems with this, however. A major one is that it "throws away" type information. In particular, all you know about either argument is that they have length fields. They might otherwise be of different types, with all their other fields completely different. You could compare a Foo and a Bar, as long as they both have lengths. Also, if you return something of the argument type, all you will know about it after that is that it has a length field; you've lost its actual type statically. To cast back up would require a potentially failing runtime check.

Consider that if we have two type Foo { length : Int, name : String} and Bar { length : Int, height : Int }, we can pass one of each into the function. Then which one it returns depends on runtime data: it might be a Foo and it might be a Bar. This means we cannot know the specific return type; all we know now is that it has to have a length field.

This is very different from normal parametric polymorphism which has type variables. While you don't know anything about the variable inside the function, it doesn't throw out type information when its used. For example, imagine this code instead:

    maxBy : (a -> Int) -> a -> a -> a
    maxBy pred a b = if pred a > pred b then a else b

This one can be used the same way by passing in a length function. However, since it doesn't use subtyping, both arguments have to have the same type! This means we can't use it to compare a foo and a bar. But when we do use it on Foos, for example, we know we will get a Foo out because that's what the a variable will be unified to:

    (a -> Int) -> a -> a -> a
    (Foo -> Int) -> Foo -> Foo -> Foo

When we use the function on a Foo, a gets instantiated to Foo giving us the second type.

Row types are just a way to bring this second style of polymorphism to records with different fields. Basically, it allows you to put a type variable representing the "rest" of the record:

    maxByLen : { length : Int | r } -> { length : Int | r } -> { length : Int | r }

Now, when we use this on a Foo, r gets instantiated to { name : String }; when we use it on a Bar, it gets instantiated to { height : Int }. This means we can't mix Foos and Bars and we don't lose type inference.

It also lets us do some other nice things. For example, we could add a field, polymorphically:

    annotate : { length : Int | r } -> { length : Int, lenStr : String | r }

It's also nice to note that we don't lose anything: we can get something very similar to the old behavior by throwing information away explicitly:

    maxBy : { length : Int | a} -> { length : Int | b } -> { length : Int }
    maxBy a b = if a.length > b.length then { length = a.length }
                                       else { length = b.length }

We can get almost exactly the sub-typing behavior by using existential types:

    maxBy : (exists a. { length | a }) -> (exists b. { length | b }) -> 
               (exists c. { length | c })
    maxBy a b = if a.length > b.length then a else b

I'm not sure why we would want this though! (I also don't know if any languages support this sort of syntax exactly, so you might have to jump through some additional hoops to simulate "exists".)

As a final note, I haven't used row polymorphism or existential types very much, so there might be some mistakes above.

It's also worth noting that Ermine has a slightly more general form of row polymorphism, but I'm not sure what the specific differences are.

Agreed. Code samples are one of the most effective ways to communicate an idea of how ones library/language/whatever works. Also, a layout that doesn't make it look like the site was written in 1996...

You could also be interested in PureScript[1] then; and its React bindings[2]. It is a statically typed language which compiles to JS. It has row polymorphism and effects (yay!).

[1]: http://purescript.org [2]: https://github.com/purescript-contrib/purescript-react

Given that Elm is a FRP language, what additional benefit does React grant you?

The difference is that the HTML in Ur/Web is not just a string like in PHP. Ur provides a special syntax for building XML trees and so if you include the code like "<b>something<b" in Ur/Web it just won't compile. You can't ever output malformed HTML in Ur.

This also allows for type checking of HTML - for example you can be sure that you won't have unescaped output in your HTML because the type system makes it impossible (won't compile) to use unescaped string in place of escaped one.

So in short, what you saw already is a template engine (also look at React (and maybe Opa?), which also has a special syntax for building XML/HTML), and it's already insanely powerful.

What more do you want from a language homepage?

The overlap between web programming and web design is similar to the overlap between oil painting and bowls of fruit.