Hello haskell,
the principle of duck typing used in dynamic OOP languages such as
Ruby and Python, is simple: if some object supports Quack method, then
it can be passed to any routine that expects an object of some Duck type
Advertising
this principle allows to build programs in quick and easy way: we just
add to objects implementations of all the methods required:
e = new Entry {label := "Hi",
color := blue,
getValue := getEntryValue,
setValue := setEntryValue}
e.display -- uses color/label properties
e.saveToFile -- uses getValue property
of course, drawback of duck typing that when we forgot to setup some
field, this will be detected only at runtime - as usual for dynamic
typing
Haskell can provide benefits of both static and duck typing with type
inference by means of extensible records. type of 'e' in this case
will be {Entry | getValue::IO String, setValue::String->IO()}, i.e.
Entry record type extended with getValue/setValue fields.
serialization function may look like this:
saveToFile x = writeToFile "data" (show x.getValue)
and its implementation infers its type:
saveToFile :: {...| getValue::(Show a) => a->IO() } -> IO ()
where {...| getValue::a} means "any record type which includes getValue
field of type a".
type of our 'e' conforms to this type signature, so `e` can be passed
to saveToFile in safe manner and this is completely checked at compile
time without any explicitly written type signatures
this becomes even more important when we want to create objects
belonging to more than one object hierarchy. by requiring that each
possible property should be explicitly declared, we may ensure that
properties used in different modules can't be mixed up:
module A: property getValue
module B: property getValue
module C: import A; import B -- conflict: from where getValue should be
imported?
it may be interesting to compare extensible records with OOP and type
classes approaches - it seems that e.r. is just like type class instances
created "at the place" and linked to the concrete object rather than
whole type
so, implementation of extensible records in haskell compilers would
allow to
1) give us simple, natural way to make bindings to various OOP
libraries. i've seen bindings in gtk2hs/wxHaskell and now they use a
lot of type hackery
2) compete with dynamic OOP languages in the areas of scripting, fast
prototyping, web programming and even make possible to use the same
techniques in larger apps, again increasing programmers productivity
also, extensible records may be useful for merging haskell into jvm/.net
world - as a way to provide haskell access to their OOP libs
ps: there are many papers on adding extensible records to Haskell, in particular
you can read http://research.microsoft.com/Users/simonpj/Papers/recpro.ps.gz
--
Best regards,
Bulat mailto:[EMAIL PROTECTED]
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
