Archive for software

Public access LogiQL

We now have a web based tutorial for LogiQL, the descendent of Datalog we have been developing at LogicBlox. Given my high standards, I feel we still have more work to do on the language. However, as our newly revised website points out, it is being successfully used it solve very real business problems already.

Comments

Mining Yahoo Images for color schemes

I meant to post about this a while ago, but while reading Bruce Sterlings's Beyond the Beyond, I learned about this clever tool for generating color schemes. Given your keywords it searches for the top five images on Yahoo! Image Search and chooses the six most prominent colors from each.

Perhaps unsurprisingly, given "existential type" it just returns different shades of gray – ones even less interesting than Bruce got for "cyberpunk".

Comments (2)

Finding symbols graphically

Jeff pointed me to these extremely cool and useful web application: Detexify2.  At least a few of you readers have spent time skimming The Comprehensive LaTeX Symbol List looking for the incantation required for a specific symbol. With Detexify2 you can just scribble something that roughly looks the symbol and it will tell you the name and, if necessary, the LaTeX package that provides it.

The only problem is that it lets users help train the recognizer.  This can also be a good thing, but I can imagine a few malicious users (or perhaps just people with very bad drawing skills) ruining it for everyone.

Comments (2)

Literally dependent types

Given that the formalization of Scala Classic has ground to a halt, for reasons I may go into later, I spent part of today hacking on the Scala compiler itself to add support for singleton literals. Currently, Scala allows singleton types for stable identifiers. My modification allows literals to be used in singleton types. I can't promise that it will be in the forthcoming Scala 2.7.2 release, but I would like it to be.

Overall it was far less work than I was expecting.  Scala already internally supports what it calls "constant types", there is just no way to write them in Scala source code presently.  Consequently, most of the effort was in extending the parser.

Given my modifications, it is now possible to write code like the following:

  1.  
  2. scala> val x : "foo".type = "foo"
  3. x: "foo".type = foo
  4.  

What I was not expecting was that out-of-the-box things like the following would work:

  1.  
  2. scala> val x : "foobar".type = "foo" + "bar"
  3. x: "foobar".type = foobar
  4. scala> val y : 10.type = 2 * 5
  5. y: 10.type = 10
  6. scala> def frob(arg : 10.type) : 6.type = arg - 4
  7. frob: (10.type)6.type
  8.  

Unfortunately the excitement soon passes when you realize all the things you can't do with singleton literals (yet). Even if we turn on the experimental dependent method support, you can't write things like

  1.  
  2. def add(arg : Int) : (arg + 5).type = arg + 5
  3.  

because these are exactly what they are called, singleton literals, not full-blown dependent types.

One cute example, based on a use suggested by Sean McDirmid, would be that some people might do something like the following with implicits:

  1.  
  2. implicit stringToColor(arg : String) : java.awt.Color = java.awt.Color.getColor(arg)
  3.  

However, with singleton literals you can tighten it up by ensuring that for some strings it will never fail:

  1.  
  2. implicit redToColor(arg : "red".type) : java.awt.Color = java.awt.Color.RED
  3. implicit blueToColor(arg : "blue".type) : java.awt.Color = java.awt.Color.BLUE
  4.  

Happily, the type inferencer already chooses the most specific implicit conversions.

In any event, they will hopefully become more useful as the type system continues to grow. I am also sure someone will probably come up with a clever use for them that hasn't occurred to me yet. If so, let me know.

Comments (5)

Functors in Scala

Following on my earlier entry on modules in Scala, I'll give an encoding of Standard ML style functors here. You can get a pretty close approximation by using class constructor arguments. However, I am going to cheat a little to get the closest encoding I think is possible by using the experimental support for dependent method types. You can get this by running scala or scalac with the option -Xexperimental. It works okay at least some of the time, but no one has the time at the moment to commit to getting it in shape for general consumption.

So here is my example of how the encoding works. First, the SML version:

  1.  
  2. signature Eq = sig
  3. type t
  4. val eq: t -> t -> bool
  5. end
  6.  
  7. signature RicherEq = sig
  8. include Eq
  9. val neq: t -> t -> bool
  10. end
  11.  
  12. functor mkRicherEq(arg : Eq) :> RicherEq where type t = arg.t = struct
  13. type t = arg.t
  14. val eq = arg.eq
  15. fun neq x y = not (eq x y)
  16. end
  17.  

We can transliterate this example into Scala as:

  1.  
  2. type Eq = {
  3. type T
  4. def eq(x: T, y: T): Boolean
  5. }
  6.  
  7. type RicherEq = {
  8. type T
  9. def eq(x: T, y: T): Boolean
  10. def neq(x: T, y: T): Boolean
  11. }
  12.  
  13. def mkRicherEq(arg: Eq) : RicherEq { type T = arg.T } = new {
  14. type T = arg.T
  15. def eq(x: T, y: T) = arg.eq(x, y)
  16. def neq(x: T, y:T) = !eq(x, y)
  17. }
  18.  

The only problem I discovered is that it is not possible to define RicherEq in terms of Eq as we could in SML:

  1.  
  2. scala> type RicherEq = Eq { def neq(x: T, y: T): Boolean }
  3. <console>:5: error: Parameter type in structural refinement may
  4. not refer to abstract type defined outside that same refinement
  5. type RicherEq = Eq { def neq(x: T, y: T): Boolean }
  6. ^
  7. <console>:5: error: Parameter type in structural refinement may
  8. not refer to abstract type defined outside that same refinement
  9. type RicherEq = Eq { def neq(x: T, y: T): Boolean }
  10. ^
  11.  

Why this restriction exists I don't know. In fact, this sort of refinement should work in the current version of Featherweight Scala, so perhaps it can be lifted eventually.

I still need to think about higher-order functors, and probably spend a few minutes researching existing proposals. I think this is probably something that cannot be easily supported in Scala if it will require allowing method invocations to appear in paths. However, off hand that only seems like it should be necessary for applicative higher-order functors, but again I definitely need to think it through.

Comments (2)

Modules in Scala

I just saw a thread on Lambda the Ultimate where I think the expressive power of Scala in comparison to Standard ML's module system was misrepresented. I don't want to go into all of the issues at the moment, but I figured out would point out that you can get the same structural typing, opaque sealing, and even the equivalent of SML's where type clause.

For example, consider the following SML signature:

  1.  
  2. signature Nat = sig
  3. type t
  4. val z: t
  5. val s: t -> t
  6. end
  7.  

This signature can be translated in to Scala as:

  1.  
  2. type Nat = {
  3. type T
  4. val z: T
  5. def s(arg: T): T
  6. }
  7.  

It is then possible to create an implementation of this type, and opaquely seal it (hiding the definition of T). In SML:

  1.  
  2. structure nat :> Nat = struct
  3. type t = int
  4. val z = 0
  5. fun s n = n + 1
  6. end
  7.  

In Scala:

  1.  
  2. val nat : Nat = new {
  3. type T = Int
  4. val z = 0
  5. def s(arg: Int) = arg + 1
  6. }
  7.  

In many cases when programming with SML modules it is necessary or convenient to give a module that reveals the definition of an abstract type. In the above example, this can be done by adding a where type clause to the first line:

  1.  
  2. structure nat :> Nat where type t = int = struct
  3. ...
  4.  

We can do the same thing in Scala using refinements:

  1.  
  2. val nat : Nat { type T = Int } = new {
  3. ...
  4.  

Great, right? Well, almost. The problem is that structural types are still a bit buggy in Scala compiler at present. So, while the above typechecks, you can't quite use it yet:

  1.  
  2. scala> nat.s(nat.z)
  3. java.lang.NoSuchMethodException: $anon$1.s(java.lang.Object)
  4. at java.lang.Class.getMethod(Class.java:1581)
  5. at .reflMethod$Method1(<console>:7)
  6. at .<init>(<console>:7)
  7. at .<clinit>(<console>)
  8. at RequestResult$.<init>(<console>:3)
  9. at RequestResult$.<clinit>(<console>)
  10. at RequestResult$result(<console>)
  11. at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  12. at sun.reflec...
  13.  

There were some issues raised about how faithful an encoding of SML functors, and well-known extensions for higher-order functors, one can get in Scala. Indeed, off the top of my head it is not entirely clear. So I need to think more about that before I write some examples.

Comments (7)

Revisiting higher-rank impredicative polymorphism in Scala

I've been meaning to write this up for a while, but it seems like there has always been something else I really ought to be doing. So I expect this will be a bit more terse than I might like. Anyway, when I wrote about encoding higher-rank universal quantification in Scala back in March, I used a rather elaborate scheme involving the use of Scala's first-class existential quantifiers. While this was the point of the exercise, surprisingly, no one called me on the fact that if you just want higher-rank impredicative polymorphism in Scala, there is a much simpler encoding. Maybe it was obvious to everyone or no one read closely enough to think of raising the issue. So today, I'll explain the better way to encode them.

First we can define an infinite family of traits to represent n-ary universal quantification, much like Scala represents n-ary functions types:

  1.  
  2. trait Univ1[Bound1,Body[_]] {
  3. def Apply[T1<:Bound1] : Body[T1]
  4. }
  5.  
  6. trait Univ2[Bound1,Bound2,Body[_,_]] {
  7. def Apply[T1<:Bound1,T2<:Bound2] : Body[T1,T2]
  8. }
  9.  
  10. // ... so on for N > 2
  11.  

Really, the key to this encoding is the use of higher-kinded quantification to encode the binding structure of the quantifier.

Now it is possible to write some examples similar to what I gave previously, but more concisely:

  1.  
  2. object Test extends Application {
  3. def id[T](x : T) = x
  4.  
  5. type Id[T] = T => T
  6. val id = new Univ1[Any,Id]
  7. { def Apply[T <: Any] : Id[T] = id[T] _ }
  8.  
  9. val idString = id.Apply[String]
  10. val idStringList = id.Apply[List[String]]
  11.  
  12. println(idString("Foo"))
  13. println(idStringList(List("Foo", "Bar", "Baz")))
  14.  
  15. type Double[T] = T => (T, T)
  16. val double = new Univ1[Any,Double]
  17. { def Apply[T <: Any] : Double[T] = (x : T) => (x, x) }
  18.  
  19. val doubleString = double.Apply[String]
  20. val doubleStringList = double.Apply[List[String]]
  21.  
  22. println(doubleString("Foo"))
  23. println(doubleStringList(List("Foo", "Bar", "Baz")))
  24. }
  25.  

As I mentioned previously, this example would be much improved by support for anonymous type functions in Scala. I am pretty sure Scala will eventually support them, as they would not require any deep changes in the implementation. They could be just implemented by desugaring to a higher-kinded type alias with a fresh name, but depending on when that desugaring is performed, it is possible that it would result in poor error messages. Supporting curried type functions is also quite desirable, but given my current knowledge of the internals, that seems like adding them will require some more elaborate changes.

I think Vincent Cremet was the first person to suggest this sort of encoding, and I vaguely recall reading about it on one of the Scala mailing lists, but I could not find the message after a little bit of time spent searching.

Comments (4)

An unusual definition of total ordering

One of the things that will show up in the imminently forthcoming Scala 2.7.1 release candidate, is the addition of traits for representing equivalence relations, partial orderings, and total orderings. Previously, the trait

  1. Ordered
was used for representing totally ordered things:

  1. trait Ordered[A] {
  2. def compare(that: A): Int
  3. def < (that: A): Boolean = (this compare that) < 0
  4. def > (that: A): Boolean = (this compare that) > 0
  5. def <= (that: A): Boolean = (this compare that) <= 0
  6. def >= (that: A): Boolean = (this compare that) >= 0
  7. def compareTo(that: A): Int = compare(that)
  8. }

However, the

  1. Ordered
trait does not provide a representation of a total ordering. Therefore, the new trait Ordering:

  1.  
  2. trait Ordering[T] extends PartialOrdering[T] {
  3. def compare(x: T, y: T): Int
  4. override def lteq(x: T, y: T): Boolean = compare(x, y) <= 0
  5. override def gteq(x: T, y: T): Boolean = compare(x, y) >= 0
  6. override def lt(x: T, y: T): Boolean = compare(x, y) < 0
  7. override def gt(x: T, y: T): Boolean = compare(x, y) > 0
  8. override def equiv(x: T, y: T): Boolean = compare(x, y) == 0
  9. }
  10.  

The tricky part however, was writing description of the properties required of something that implements the

  1. Ordering
trait. When one normally thinks of a total ordering one thinks of a relation that is

  • anti-symmetric,
  • transitive,
  • and total.

The problem is that

  1. Ordering
is not defined in terms of a binary relation, but a binary function producing integers (
  1. compare
). If the first argument is less than the second the function returns a negative integer, if they are equal in the ordering the function returns zero, and if the second argument is less than the first the function returns a positive integer. Therefore, it is not straightforward to express these same properties. The best I could come up with was

    1. compare(x, x) == 0
    , for any
    1. x
    of type
    1. T
    .
    1. compare(x, y) == z
    and
    1. compare(y, x) == w
    then
    1. Math.signum(z) == -Math.signum(w)
    , for any
    1. x
    and
    1. y
    of type
    1. T
    and
    1. z
    and
    1. w
    of type
    1. Int
    .
  • if
    1. compare(x, y) == z
    and
    1. lteq(y, w) == v
    and
    1. Math.signum(z) >= 0
    and
    1. Math.signum(v) >= 0
    then
    1. compare(x, w) == u
    and
    1. Math.signum(z + v) == Math.signum(u)
    ,
    for any
    1. x
    ,
    1. y
    , and
    1. w
    of type
    1. T
    and
    1. z
    ,
    1. v
    , and
    1. u
    of type
    1. Int
    .

Where

  1. Math.signum
returns
  1. -1
if its input is negative,
  1. 0
if its input is
  1. 0
, and
  1. 1
if its input is positive.

The first property is clearly reflexivity. I call the third property transitivity. I am not sure what to call the second property. I do not think a notion of totality is required because it is assumed you will always get an integer back from

  1. compare
rather than it throwing an exception or going into an infinite loop.

It would probably be a good exercise to prove that given these properties on

  1. compare
hold if and only if
  1. lteq
(defined above in terms of
  1. compare
) has all the normal properties of a total ordering.

Comments

Research update

I finished a draft of "Generalizing Parametricity Using Information-flow" for LMCS this past weekend. That should leave me with fewer distractions to work on something for ICFP.

My work on Featherweight Scala is moving along, sometimes more slowly than others. Other than the issues with singletons I have already discussed, one problem with the original definition of Featherweight Scala is that it did not truly define a subset of Scala proper – that is, there were many valid Featherweight Scala programs that were not valid Scala programs.

So I have been working on trying to get Featherweight Scala to be as close to a subset of Scala proper as is possible without making it far too complicated to be a useful core calculus. Some of this has involved changing the definition of Featherweight Scala. Some of this has involved lobbying for changes to Scala proper to make it more uniform (so far I've succeed with extending traits to allow value declarations to be overridden).

Through the whole process I've also been spending a lot of time typing things into the Scala interpreter to figure out how Scala proper treats them. For better or worse, I've actually managed to uncover a fair number of bugs in Scala proper doing this. I've almost reached the point where I treat it as a bit of a game: can I from thinking about the properties of the Scala type system come up with some corner case that will exhibit an unsoundness in the language (a ClassCastException, a NoSuchMethodException, etc.), or at least crash the compiler?

Last week I came up with a pretty nice one where I used the fact that Scala should not allow inheritance from singleton types to launder types in an unsafe fashion (now fixed in trunk!). Prior to that I came up with something fun where you could trick the compiler into letting you inherit from Nothing (which is supposed to be the bottom of the subtyping hierarchy). Today I got to thinking about Scala's requirements that paths in singleton types must be stable – all components of a path must be immutable. So for example in

  1.  
  2. var x = 3
  3. val y : x.type = x // ill-typed

The path x is not stable because x is a mutable variable. However, Scala does allow lazy value declarations to be stable.

  1.  
  2. var x = 3
  3. lazy val y = x
  4. val z : y.type = y // allowed, at present

Note that y is not evaluated until it is first needed, and in this case its evaluation involves a mutable reference. Furthermore, add into the mix that Scala also provides call-by-name method arguments (lazy values are call-by-need). So I started riffing on the idea of whether I could violate stability by changing the mutable reference between the definition of the lazy value, or a call-by-name argument, and its use. In retrospect, I am leaning at present towards the belief that there is no way this should be exploitable from a theoretical standpoint. That does not mean that the implementation is necessarily in alignment with theory, however. I did manage to hit upon a combination in my experiments that resulted in a NoSuchMethodException, so the exercise was not a complete letdown.

I should point out that these things do not really reflect on the quality of the Scala language as whole. It is a rich language that does not yet have a complete formal model, and as such, in the implementation process it can be easy to overlook some particularly perverse abuses of the language.

Comments

Tablet computing

Writing about RSI reminded me that I had never gotten around to talking about the ThinkPad X61 tablet I purchased at the beginning of August. It is a pretty solid when used as a laptop.

As far as being a tablet goes, it works reasonably well in that domain too, with some exceptions. Firstly, for now if you want to use the tablet capabilities to their fullest, you need to run Windows Vista. The tablet is supposed to be supported under Linux, but there is really only one program that supports handwriting recognition program available, Cellwriter. It looks promising, particularly because it can be trained to generate any Unicode glyph – with Vista you are limited to the system's configured language. However, I do not think it would be difficult for Gnome or KDE to catch up in this area if they put a little effort into it.

My initial solution to this was that I would just run Linux under VMWare. Except I soon found that while I can use the tablet as a mouse, VMWare will not accept the input events the handwriting recognition subsystem generates. When I filed this as a bug they did not seem to think this was a problem.

While working with standard Windows applications, anything with a input field can accept handwriting recognition input. I almost wrote my entire defense presentation this way, but near the end I gave in and used the keyboard to do most of the last minute tweaking.

Of course, there is the question of whether writing by hand is any easier on my wrists than typing. It is difficult to say, for one, it becomes basically impossible to use emacs, unless you can do everything from pull-down menus, because of the chording necessary to activate some functionality. And it is definitely slower than typing, even with practice I expect. However, part of the problem could perhaps be resolved by rethinking various applications with tablets in mind.

Comments

« Previous entries Next Page » Next Page »