[Ur] Announcing jsMove

[Timothy Beyer]

At Sun, 22 Jul 2012 08:27:20 -0400,
Adam Chlipala wrote:
> I think the mouse/key event handler changes I announced yesterday might 
> make some (but definitely not all) of your FFI work redundant.

I was actually going to ask about that, for example, is there a reason why
there isn't an onMouseMove definition provided? (since you have it in
mouseEvents)

I don't think you'd want to include touchscreen handlers, which are probably
outside of the scope of Ur/Web and are easy to define with the FFI.

I like the way you made all the mouse handlers take functions with mouseEvents
now, that is much more general and I can now get rid of my variations on the
onClick handler.

> Why does jsMove.urs include type definitions?

I like writing type definitions whenever possible, and I actually thought it
was required in this case, but if it isn't suggested, then I'll omit them.

> I notice many redundant parentheses in jsMove.ur, which is 
> understandable for someone new to ML-style syntax (if you are?), but 
> which still confuses me, since I assume parens are there for a reason. ;)

I've followed Standard ML/OCaml/F# for a long time, but haven't written any
applications in any of the three other than toy examples, so yes I'm new to
that type of syntax.

> You define a function [showXY] that would be an excellent candidate for 
> a [show] type class instance, so that you could afterward call merely 
> [show] instead of [showXY].
 
That is definitely a mess, (as is even more so the function that converts a
list of ints to a string) as I haven't learned how to make my own show
instances yet.  That's probably the first thing I'll addresss aside from
updating the FFI code.

> There is a [source] holding a [string] that gives instructions for the 
> user.  Currently, an 'onload' handler computes this string imperatively 
> and stores it in the [source].  A more idiomatic Ur/Web approach would 
> be to code the instructions part of the page as a <dyn> that refers 
> directly to the underlying data sources (in this case, [mouseOn] and 
> [clickToMove]).  This also saves you some code duplication, as currently 
> you recompute the instructions in the same way in multiple locations.

Initially I just wrote it the first way that worked, but I definitely want to
make it more declarative whenever possible.

> Clearly it is worth defining a function for the pattern [x <- signal x; 
> return <xml>{[x]}</xml>], in some common library. :-)
> 
> You use the constructor [Cons] directly in one place.  I prefer the 
> infix operator [::] for that.

I'm kind of new to statically typed functional programming, I still write stuff
kind of like I'm programming in Erlang, Scheme or Prolog, but I have written
some Haskell in the past.

Anyway, I appreciate the suggestions since I had a feeling this code would make
the eyes bleed of experienced ML or Haskell programmers :) and I have a
tendency to be lazy and not use features of a language until I can't get the
code to compile or run properly.

Tim