You might have noticed that I stopped posting things here sometime last week, despite my ostensible goal of posting something every work day. That's because I finally got tired of writing entries that basically said "I can't say anything about what I did today"; pretty much my whole academic experience for the past week has been programming contest related and there was nothing much to say.
But yesterday I actually did pick back up on some non-contest-related stuff, so I ought to mention that. My paper for ICFP that got rejected was semantics for Scheme, and it was rejected basically because the reviewers thought it wasn't interesting to the larger ICFP audience. That may or may not be true, but it will certainly be interesting to the Scheme community, so we're incorporating the reviewers' suggestions into our draft and sending the result to the Scheme Workshop. That's what I did for a fair bit of yesterday, along with moving a little closer in my understanding of the weirdness that is theoretical work on foreign-function interfaces (I'm about ready to make the claim that particular embeddings give you isorecursive types, which is kind of neat). As the POPL deadline approaches, I'm realizing that a big system with Java or something like that embedded may not be ready on time, but I think I'm going to write up what I've got anyway.
Also yesterday was some database monkey work that will find its way in some form into Topsl. It's great that so many people seem interested in it. I really want to get a real thing out the door; I think it has the potential to be huge.
But yesterday I actually did pick back up on some non-contest-related stuff, so I ought to mention that. My paper for ICFP that got rejected was semantics for Scheme, and it was rejected basically because the reviewers thought it wasn't interesting to the larger ICFP audience. That may or may not be true, but it will certainly be interesting to the Scheme community, so we're incorporating the reviewers' suggestions into our draft and sending the result to the Scheme Workshop. That's what I did for a fair bit of yesterday, along with moving a little closer in my understanding of the weirdness that is theoretical work on foreign-function interfaces (I'm about ready to make the claim that particular embeddings give you isorecursive types, which is kind of neat). As the POPL deadline approaches, I'm realizing that a big system with Java or something like that embedded may not be ready on time, but I think I'm going to write up what I've got anyway.
Also yesterday was some database monkey work that will find its way in some form into Topsl. It's great that so many people seem interested in it. I really want to get a real thing out the door; I think it has the potential to be huge.
posted by Jacob Matthews at
08:20
4 Comments:
Topsl - yay! Go Topsl.
What the #$@?! is an isorecursive type?
By
Dave Herman, at 12:49
So you've got this function:
fun hungry(x: int) = hungry
and you want to give it a type. You'd like to be able to give it a type that reflects that you give it an int in but what you get back is the exact same type you started with, in other words something that looks like:
μHungry. int → Hungry
(this is an example from TAPL that I'm probably mangling, by the way). If you can actually say that Hungry is the same thing as (int → Hungry), then the type is called equirecursive; if when you're holding onto that thing you know to be a Hungry you have to explicitly convert it into an (int → Hungry) and vice versa then the type is called isorecursive.
For example, Standard ML has isorecursive types: you can't give hungry as written above a type, but if you add in a data constructor you can make it work with explicit wrapping and unwrapping:
- datatype Hungry = H of (int -> Hungry);
datatype Hungry = H of int -> Hungry
- fun hungry (x) = H hungry;
val hungry = fn : int -> Hungry
[I should note that I'm not in any way an expert on this sort of thing, that this treatment is probably not just misguided but fundamentally wrongheaded, and that relying on this information may well cause you lifelong injury. HTH.]
By
Jacob Matthews, at 17:07
> This talk gave me the eeriest feeling that I'd heard it before somewhere, but I couldn't figure out where.
It sounds a lot like QuickCheck:
http://www.cs.chalmers.se/~rjmh/QuickCheck/
which is for Haskell, but there've
been ports to many other languages,
including Scheme.
By
Paul Steckler, at 19:07
irtr.org
MD5: 4F B0 9D D3 C5 F6 61 7E C5 27 99 85 05 6F 7B 2B
SHA-1: B9 85 B0 E1 83 59 49 0A C1 4D 9B 18 BA 20 6B 69 A8 4F 55 EE
By
Anonymous, at 03:08
Post a Comment
<< Home