LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bruno Le Floch <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 14 Apr 2011 20:22:42 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
>> * These should probably be consistent.
>> * I think returning a quark is dangerous in case of sloppy package
>> authors.

From the seq point of view, I like the idea of \seq_pop:NNF, with a
\seq_pop:NN variant for an expl3-provided error.

For prop, a missing key is more often not an error(?), so perhaps
providing all four \prop_get:NnN(T)(F) variants may make sense. They
would be implemented internally with a quark test on the result of
\prop_get:NnN (very small performance overhead). Then
\prop_if_in:Nn(TF) would be much less useful, since it is just as slow
as \prop_get:NnN(T)(F).

> I find that the quark-based approach is about twice as fast as using
> \prop_if_in:Nn.

Yes, you end up doing the same work (defining an auxiliary function,
expanding the prop, grabbing delimited arguments) twice. And quark
tests on single tokens are fast.

In these kind of cases, I feel like providing an optimized function in
the kernel is better than letting higher-level programmers try to
guess what is the right/fastest way of doing things.

-- 
Regards,
Bruno

ATOM RSS1 RSS2