LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Fri, 7 Aug 2015 02:41:01 +0000
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Message-ID:
In-Reply-To:
Content-Type:
multipart/alternative; boundary=94eb2c07a850998443051caf91d1
From:
Sean Allred <[log in to unmask]>
Parts/Attachments:
text/plain (4 kB) , text/html (6 kB)
Hi Bruno :)

Disclaimer: I've completely reversed my stance on this. See below.

> Can you clarify what your suggested \bool_validate:n is meant to do?
> Your description is too short for me to have any idea what it is.

\bool_validate:n is just a thought to allow the programmer to
introduce the functionality rather than impose it on him/her.  When
parsing the overall expression in, say,

    \bool_if:nF
      {
        \pbj_is_peanut_butter_jelly_time_p:               % (A)
        &&
        \pbj_can_dance_p:                                 % (B)
        &&
        ! (
            \pbj_has_suit_p:N \g_tmp_person ||            % (C)
            \bool_validate:n % or maybe \bool_eval_all:n
              {
                \token_if_eq_meaning_p:NN #1 ? ||         % (D)
                \token_if_eq_meaning_p:NN #1 !            % (E)
              }
          )
      } { dance ~ like ~ there's ~ no ~ tomorrow }

A and B will short-circuit as they do today.  If A is false, B through
E will not be evaluated.  If A is true and B is false, ... etc.

If ( A && B && !C), we'll get to \bool_validate:n.  This will evaluate
everything in its argument *without* short-circuiting.

I explained that for the sake of clarity, because...

> The cheapest change in terms of amount of code and of
> maintainability is to drop lazy evaluation of boolean expressions.
> This will require changing in minor ways a few packages where lazy
> evaluation of boolean expressions is assumed.

...this is probably the wiser option, on second thought.  Lazy
evaluation could probably be easily implemented on top of a non-lazy
version.  (This would just be an implementation of shunting-yard.)

> Actually, there is currently a mess of code that is only there to
> support lazy evaluation.  If we get rid of lazy evaluation, I strongly
> expect the code underlying boolean expressions to become simpler.

I believe it must by the very nature of the problem.  Lazy evaluation
takes a bit of knowledge about the operators in itself (in addition to
the knowledge needed to actually evaluate the expression).

> In fact, I believe it would be possible to provide a form of lazy
> evaluation when explicitly requested by the programmer.

... I promise, I just read this :) Yes, I agree this would be a good
idea.  We'd get some modularization for free, as well.

----

As long as the ability to short-circuit expressions remains, that's
probably 'good enough'.  (There's a good argument to say 'the simpler,
the better', so removing lazy evaluation from the 'default' behavior
may the the Right thing to do, anyways.)

Thanks for making me think about this again, and sorry it took me so
long to respond!  Your email was buried in short order :(

All the best,
-Sean


On Thu, Jul 23, 2015 at 8:34 PM Bruno Le Floch <[log in to unmask]> wrote:

> Hi Sean,
>
> > I don't believe it's out of the question to wrap macro-parameters in some
> > sort of \bool_validate:n (if such a thing doesn't already exist) that
> would
> > run the checks and issue appropriate errors on a case-by-case basis. I
> > believe it's important to assume the programmer knows what he or she is
> > doing and let them account for this themselves. Otherwise, you introduce
> > complexity where none is needed for a large portion of folks.
>
> Can you clarify what your suggested \bool_validate:n is meant to do?
> Your description is too short for me to have any idea what it is.
>
> If we leave things as they are, I am pretty certain that programmers
> will fall into the pitfall of thinking that
>
>     \bool_if:nTF
>       {
>         \token_if_eq_meaning_p:NN #1 ? ||
>         \token_if_eq_meaning_p:NN #1 !
>       }
>
> is safe, even though it will break horribly if `#1` is `(` or `)`
> (technically I haven't tested so perhaps this works by chance).
>
> The reason I am certain of this is that I fell into this trap (before
> I stopped using boolean expressions), even though I was aware of it.
> This is why we need to change something.  The cheapest change in terms
> of amount of code and of maintainability is to drop lazy evaluation of
> boolean expressions.  This will require changing in minor ways a few
> packages where lazy evaluation of boolean expressions is assumed.
>
> > Not to mention that it is just that much more to test and maintain.
>
> Actually, there is currently a mess of code that is only there to
> support lazy evaluation.  If we get rid of lazy evaluation, I strongly
> expect the code underlying boolean expressions to become simpler.
>
> In fact, I believe it would be possible to provide a form of lazy
> evaluation when explicitly requested by the programmer.  Something
> like
>
>     \bool_if:nTF
>       {
>         \tl_if_exist_p:N #1 &&
>         \bool_lazy:n { \tl_if_empty_p:N #1 }
>       }
>
> would do some trickery under the hood to prevent expansion of
> `\tl_if_empty_p:N #1` if `\tl_if_exist_p:N #1` gives the result
> `false`.
>
>
> Regards,
>
> Bruno
>


ATOM RSS1 RSS2