On Oct 13, 2010, at 7:44 PM, Jacek Generowicz <jacek.generow...@cern.ch> wrote:


On 2010 Oct 14, at 01:32, Evan Laforge wrote:

I think I'm starting too see what my problem is. I think it boils down to
hankering for Duck Typing and variadic functions. I fully appreciate that
passing functions is a wonderful and powerful technique for catering for
variation, but Haskell's type system cramps my style by insisting that I
can't put a (Banana -> Cake) in the same container as an (Octopus ->
Truffles -> DogsBreakfast).

But the thing is, I don't use things like this, even in python.

Shame. They're damn useful :-)

How
are you expecting to call the functions in that container?  "for f in
c: try: return f(*misc_args) except: pass"?

to_do = [(call, (AuntMabel,)),
       (buy,  ([(12*kg, sugar), (6*bushel, wheat)])),
       (introduce, (Romeo, Juliet))]

for do,it in to_do:
  do(*it)

What is the point of doing that? If it's just to defer execution until that 
loop, you should just rely on lazy evaluation, or [IO ()].

If that's not the only thing you do, then the question is still how you know 
enough about the structure of values In the list to do anything useful with 
them.

If you just want to be able to inspect them interactively, you should ask about 
support for inspecting thunks in the ghci debugger.

I suppose you haven't heard of parametricity theorems. In Haskell, values have 
no hair. If you don't know anything about the type of a values you can't 
inspect it. It's one of the major tools that helps type signatures contribute 
to the correctness of implementations.
In Python, Java, and other similar languages there are lots of things you can 
do with unknown values - get a string representation, test for equality with 
another value, get the class it belongs to, etc.

So, we won't understand the point of your example without a little more 
information on what you do to those heterogeneous values, and how the program 
can tell which things to do wi which item, 

In Haskell it may be fun to turn on -XGADTs and write

data DelayedApp result where
 Base :: a -> DelayedApp a
 App :: DelayedApp (a -> b) -> a -> DelayedApp b

but it turns out to be isomorphic to data DelayedResult r = DR a Nat
 - at least until you add some more data to the constructors.



      
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to