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
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0 (Apple Message framework v929.2)
Content-Type:
text/plain; charset=US-ASCII; format=flowed; delsp=yes
Date:
Sun, 30 Nov 2008 02:13:08 +1030
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Will Robertson <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
7bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (74 lines)
Hello,

Bit of a slow (but hasty) reply :)

On 28/11/2008, at 6:50 PM, Joseph Wright wrote:
>> E.g.,
>>  \tlist_if_in_TF:nn { <tlist> }{ <str> } { <true> }{ <false> }
>
> Speaking from my own experience, I quite like the :T, :F, :TF idea.   
> The
> problem with the above is that \tlist_if_in_TF:nn needs four  
> arguments,
> so it should really be \tlist_if_in_TF:nnnn.

That's true, and not as concise.

>  I think it is then much
> harder to see what is going on.  So if it were down to me I'd keep the
> T/F idea, although I'd aim for lower case as these can take braced
> arguments.

On the other hand, as exceptions, 'F' and 'T' stand out a little bit  
more than if they were lowercase :)

But yes, in general I think it's better to keep them on the "right" of  
the ':'.

>> (Although I suppose there's no reason we couldn't currently write
>>  \bool_double_if:NN_TT_TF_FT_FF )
>
> Why not just \bool_if:NN_TT_TF_FT_FF?  A slight abuse of the system,  
> but
> this is one of those edge cases where flexibility is needed.

Good idea, I think.

>> While we might be able to create a better system than we've got  
>> now, is
>> it worth it?
>
> Once again, if it were down to me I'd not make more changes than are
> really needed.  In that sense, this entire discussion could be  
> somewhat
> redundant: things already work reasonably well.

Yes, I agree!

> I'd still argue that
> \exp_after:NN is not representative of what it does, so using the
> current specifiers would prefer \exp_args:NE.  That change at least
> should be relatively easy.

Well, I think writing it as \exp_after:wN is "most correct", but in  
the end I hope that we shouldn't really be using it much in expl3  
programming.

> If other changes are made, I'd suggest that there will be something  
> of a
> "knock on" effect, and so it is only worth doing if the entire  
> result is
> more logical (e.g. just changing f => s is not worth it).

Indeed; we should be very sure the new system is actually "better" and  
we're not just changing things for the sake of it.

> Of course, I
> think my suggestion is not bad :-)

I think both your suggestions and Morten's are quite useable for our  
needs; I don't have much opinion between the two. As Frank always says  
"language design isn't easy" :)

W

ATOM RSS1 RSS2