[m-rev.] For review: Convert Mercury terms to XML

Ian MacLarty maclarty at cs.mu.OZ.AU
Mon Dec 6 12:43:10 AEDT 2004


On 6 Dec 2004, at 11:32, Ralph Becket wrote:

> Julien Fischer, Sunday,  5 December 2004:
>>
>> I'm not really keen on the name `to_xml'.  How about either
>> `xml' or `xml_util'?
>
term_to_xml is okay.  I want the name to reflect that it's not an XML 
parser, so xml or xml_util aren't good.  I still prefer to_xml just 
because it's shorter, but I'll go with term_to_xml if everyone else is 
happy with that.

> I'm unhappy with all three suggestions.
> term_to_xml would describe what it does.
>
>>> Index: library/to_xml.m
>
> I don't think this is of sufficiently general utility to belong in the
> standard library.  It should go in extras.
>
It's going to be used in the compiler to generated browsable HLDS dumps 
and in the debugger in a visual term browser.  I could include it in 
the mdbcomp library in browser and then copy it to extras.  Is that 
better?

>>> +
>>> +:- type element_request
>>> +	--->	from_functor_name(string)
>>> +	;	from_functor_num(int).
>>> +
>>> +:- pragma memo(get_element/2).
>>> +
>> Using memoing in the standard library is going to mean that it no
>> longer compiles for those grades that don't support it, e.g. the java
>> and il grades.
>
> I agree.  It's not a good idea.  For a start, memo tables persist
> through GC, so they are likely to be a type of space leak for
> long-running applications (this is a hole in the memoing API IMHO).
>
> I'd leave it to the user to add memoed wrapper predicates if they need
> them.
>
Why don't grades that don't support memoing just ignore the pragma?  I 
put memoing on this predicate because it's going to be called often 
with the same input.  The memo table should have at most (2 * the 
number of functors for the type) entries so I wouldn't imagine it would 
get too big.

Also the user can't really add a wrapper memoed predicate as 
get_element/2 is called from predicates that do IO.

Maybe a better solution is to allow the user to supply their own 
functor to element mapping (and we can provide a default one), then 
they could provide a memo wrapper if needed.

This also solves another problem I was thinking about on the weekend:  
the element names are quite complex looking, since I include the type 
name in the element name to make sure I have a 1 to 1 mapping between 
functors and elements so I can generate an accurate DTD.  If the user 
wants a simplified mapping from functors to elements then they should 
be able to supply their own mapping, though we won't be able to 
generate an accurate DTD in that case.

Ian.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list