[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