> > > F a * = member (map (F a) [0..]) // member [a] a -> Bool
> > I mave no clue what this means.  What is `member'?
> 
> Member is memq, in, etc. Checks for membership in a list.
I'm still lost.  What is // and how does it bind?
This is how I parse it:
  (member (map (F a) [0..])) // ( (member [a] a) -> Bool )

Why does the first occurence of member only have one argument
and the second two?

> I'd like to make an argument against that. Like Fergus I am an advocate of a
> dynamic types. (I've never met a type system I didn't like ;).
I like dynamic types too.  But I don't want to pay the price for them
if I don't use them.  Because they do carry a runtime cost.

> You can add dependant types to Cayenne (theoretically) just by allowing the
> run-time type inspection that you intentionally disallowed. In my mind,
> you'd kill two birds with one stone.
Yes, and I've been thinking about adding runtime type tests.  Perhaps
by adding a function of type `encode :: # -> Type', where Type is
a normal data type used to capture the types in Cayenne.

But before adding that I'd like to play with what I've already got. :-)

> > type yourself.  I guess it would be possible to do a little type
> > inference, but for a function like apply it would be difficult
> > (and impossible in general).
> 
> The obvious question: does "in general" equal "in practice"?
What I think would work in practice is to have type inference
for those functions where it works today in e.g. Haskell.
But if you use more powerful types you have to add signatures.
Which I think is a good idea anyway. :-)

> (i.e., you leave out the pivot [x])
> 
> Obviously the result of sort will no longer be a permutation of its
> argument. Will this then not type check?
No, the proof (whereever it is) would no longer type check.

    -- Lennart



Reply via email to