
I like your idea of joining alligator tails to
represent the connective, but just came up with a
different idea about representing types.
The difficulty with using alligator sizes to represent
types is that deciding how to represent relationships
between types could pose a problem. For example,
suppose I have a function lengthOfAddedList, which
takes a Char and a list, and returns the length of the
list with the Char prepended:
lengthOfAddedList.hs:
lengthOfAddedList :: Char -> [Char] -> Int
lengthOfAddedList c cs = length([c]++cs)
If we represent types as sizes, then, we can have,
say, Char having a smallest size, [Char] having a size
one size larger than Char, and Int having a size one
size still larger than [Char].
But then, how do we represent the difference in
relationships between the Char and [Char], and the
[Char] and Int? A [Char] is a list of Chars, but an
Int is an unrelated type.
Further, suppose we have the following function:
lengthOfAddedListWithBool.hs:
lengthOfAddedListWithBool :: Bool -> [Bool] -> Int
lengthOfAddedListWithBool b bs = length([b]++bs)
How do I decide whether Char or Bool has a larger
alligator size, and how do I motivate this decision?
Again, it is not clear.
Therefore, I propose that types be represented by
patterns (as it stripes vs. dots vs. a checkered
pattern, etc.) instead of sizes. I.e., the Char type
can be represented by a striped pattern on an
alligator, the Bool type can be represented by a
striped pattern, and so on.
Then, we can establish the rule that putting a type in
a list is represented by putting that pattern in bold
on the alligator, so we can have
lengthOfAddedList :: Char -> [Char] -> Int
be represented by an alligator with a striped pattern
tying its tail to an alligator with a bold striped
pattern tying its tail to an alligator with, say, dots
(assuming dots represent the Int type), and we can
have
lengthOfAddedListWithBool :: Bool -> [Bool] -> Int
be represented by an alligator with a checkered
pattern tying its tail to an alligator with a bold
checkered pattern tying its tail to an alligator with
dots.
Patterns would seem to allow more freedom of
expression in denoting relationships between types
(say, a type of a list of Chars to a type of a Char)
than sizes.
There are probably even better ways of representing
relationships between types on alligators.
This seems a good start; what do you think?
Benjamin L. Russell
--- Justin Bailey
On Wed, Mar 19, 2008 at 12:48 AM, Benjamin L. Russell
wrote: However, in thinking about how to adapt the game, I am not quite sure how to incorporate the representation of "->" (function type):
* ???: "->" (function type)
What ideas, if any, would anybody have on how "->" (function type) could be represented in a simply-typed lambda calculus version of Brett Victor's Alligator Eggs?
Since color is already taken, how about representing types as skinny and fat alligators? Functions can then be represented by alligators with their tails joined together. For example, Nat -> Bool would be represented as a skinny alligator joined to a fat alligator. A skinny alligator will only eat anotehr skinny alligator, and then goes to take a nap (i.e. disappears). That leaves the fat alligator (bool). Just a sketch but maybe it will help you out!
Justin