Home Original page

What static typing makes difficult

Brian McNamara! gt5163b at prism.gatech.edu
Sat Oct 25 17:55:43 EDT 2003 
james.anderson at setf.de once said:
>"Brian McNamara!" wrote:
>> mertz at gnosis.cx once said:
>> >The package gnosis.xml.objectify takes an XML source, and turns it into
>> >a "native" Python object....
>> > ...
>> >           if parser==DOM and (hasattr(xml_src,'documentElement'): ...
>> > ...
>>
>> I have no chance at a full implementation, but here is a sketch in
>> Haskell.  I know that a mere sketch is never as good as a working
>> implementation, so I hope someone else will take up the challenge.
>> 
>> ...
>> 
>> As far as I can tell, the only "extra scaffolding" is the type class
>> ConvertibleToXML.  Each time some new data type comes along which can be
>> converted to XML, we add a new instance declaration which shows how.
>
>? would haskell suggest to handle the attribute-based specialization in a
>manner similar to the original post, or does it offer some other mechanism?

There are two ways to go.  If it's reasonable to know statically about
this attribute, then you could encode it in the type system (e.g. a type
like DOMWithDocumentElement).  My hunch (based on my very limited
knowledge of the domain) is that this is a dynamic attribute.  So
instead you'd 'fail' if the attribute didn't match at run-time.  Note
that my Haskell code returned "Maybe XMLRep"s, so the corresponding code
would look something like

   -- has type Maybe XMLRep
   if (hasAttr domObj "documentElement")
   then Just ...  -- do the conversion of the domObj
   else Nothing

The same strategy would be used to cope with other 'dynamic failures'
in the other branches, such as a malformed XML string, or a
non-existent file when converting from a filename.

-- 
 Brian M. McNamara   lorgon at acm.org  :  I am a parsing fool!
   ** Reduce - Reuse - Recycle **    :  (Where's my medication? ;) )
More information about the Python-list mailing list