Dedicated functions for negative predicate tests

Dedicated functions for negative predicate tests

Negative tests, e.g. (not (null? x)), are everywhere
in Scheme functions.  Having dedicated functions for
the most common ones may allow to make the code a bit
lighter (and possibly very slightly faster).

This patch includes tests for not-null?, not-zero?,
not-integer?, not-number?, not-symbol?, not-string?
and not-list?, as well as a C++-defined not-pair?
that may be used instead of the already-existing one
found in srfi-1.  (These are all available as ly:-prefixed
functions as well, which may help in case something
changes in upstream Guile.)

It is, however, a rather substantial addition (turning
some Scheme functions into somewhat of a non-standard
dialect, even though the syntax remains self-evident), and is
therefore open to discussion -- or outright rejection :-)

[Valentin Villenave, 2019-02-08 09:15:11]

Fix `make check’.

[Valentin Villenave, 2019-02-08 09:46:17]

FWIW, here’s what `make test-clean; time make-test’ returns:

Without the patch:
real	10m5.239s
user	17m3.656s
sys	1m2.055s

With the patch:
real	9m27.001s
user	17m5.396s
sys	1m0.880s

(Note that I’m not saying it has any meaning.)

V.

[dak, 2019-02-08 11:51:37]

On 2019/02/08 09:46:17, Valentin Villenave wrote:
> FWIW, here’s what `make test-clean; time make-test’ returns:
> 
> Without the patch:
> real	10m5.239s
> user	17m3.656s
> sys	1m2.055s
> 
> With the patch:
> real	9m27.001s
> user	17m5.396s
> sys	1m0.880s
> 
> (Note that I’m not saying it has any meaning.)
> 
> V.

Frankly, I don't like it.  The relevant metric here is the user time and it's
_increased_ in your benchmark (not that it's likely significant).  The inverted
predicates are _opaque_ to the Scheme compiler and thus are no longer useful for
constant expression elimination.  Stuff like (if (not (pair? ...))) is optimized
already by the compiler, and such optimizations will actually be more prevalent
(a whole lot) if we ever make the move to Guilev2.  Throwing code in that the
compiler does not know about is not likely to be much of an advantage.

[Valentin Villenave, 2019-02-08 12:45:43]

On 2019/02/08 11:51:37, dak wrote:
> Frankly, I don't like it.  The relevant metric here is the user time and it's
> _increased_ in your benchmark (not that it's likely significant).

Agreed.

> Throwing code in that the compiler does not know about is
> not likely to be much of an advantage.

In that case, how about adding these as mere Scheme shortcuts?
not-null?, in particular, would be quite useful.

V.

[dak, 2019-02-08 16:41:06]

On 2019/02/08 12:45:43, Valentin Villenave wrote:
> On 2019/02/08 11:51:37, dak wrote:
> > Frankly, I don't like it.  The relevant metric here is the user time and
it's
> > _increased_ in your benchmark (not that it's likely significant).
> 
> Agreed.
> 
> > Throwing code in that the compiler does not know about is
> > not likely to be much of an advantage.
> 
> In that case, how about adding these as mere Scheme shortcuts?
> not-null?, in particular, would be quite useful.

For what?

[Valentin Villenave, 2019-02-08 17:05:46]

On 2019/02/08 16:41:06, dak wrote:
> For what?

For making some functions ever so slightly less cumbersome to type and to read. 
But I’m gathering from your question that you’ve never felt any need for it :-)

Since you’re complaining about LilyPond-specific functions not handled by Guile,
what about assoc-get? From what I gather, this remains entirely bound to our
codebase?

BTW, just out of curiosity: when you say "let’s not make things opaque to the
Scheme compiler", are you referring to something already existing with Guile 1.8
and which I’ve (very conceivably) never heard about, or only to the JIT-bytecode
feature that’s been introduced with v2.0?

V.

[dak, 2019-02-08 17:15:49]

On 2019/02/08 17:05:46, Valentin Villenave wrote:
> On 2019/02/08 16:41:06, dak wrote:
> > For what?
> 
> For making some functions ever so slightly less cumbersome to type and to
read. 
> But I’m gathering from your question that you’ve never felt any need for it
:-)

(not (null? xxx)) vs (not-null? xxx) is not really much of an advantage.

(filter (lambda (x) (not null? x)) ...) vs (filter null? ...) would be an
advantage but in that case pair? can often quite well replace not-null? .

> Since you’re complaining about LilyPond-specific functions not handled by
Guile,
> what about assoc-get? From what I gather, this remains entirely bound to our
> codebase?

And I plan to at one time let it deal with more than just pairs in a list, also
allowing hashtables as members (and likely tails) and likely vectors.

So it's actually good if it is under our control.

> BTW, just out of curiosity: when you say "let’s not make things opaque to the
> Scheme compiler", are you referring to something already existing with Guile
1.8
> and which I’ve (very conceivably) never heard about, or only to the
JIT-bytecode
> feature that’s been introduced with v2.0?

It's not just bytecode but also optimization of the intermediate language.  Not
sure to which degree Guile 1.8 does that.  Admittedly Guile-1.8 supported a
completely hare-brained hack I tried for reimplementing local-eval using
call-with-current-continuation, and that hack would likely not have worked in a
multiple-pass system of compilation.

[c_sorensen, 2019-02-08 17:20:53]

On 2/8/19, 10:17 AM, "lilypond-devel on behalf of dak@gnu.org"
<lilypond-devel-bounces+c_sorensen=byu.edu@gnu.org on behalf of dak@gnu.org>
wrote:

    On 2019/02/08 17:05:46, Valentin Villenave wrote:
    > On 2019/02/08 16:41:06, dak wrote:
    > > For what?
    
    > Since you’re complaining about LilyPond-specific functions not handled
    by Guile,
    > what about assoc-get? From what I gather, this remains entirely bound
    to our
    > codebase?
    
    And I plan to at one time let it deal with more than just pairs in a
    list, also allowing hashtables as members (and likely tails) and likely
    vectors.
    
    So it's actually good if it is under our control.
    
Also, IIRC, assoc-get works to get values out of alist-chains, not just out of
plain alists.

Thanks,

Carl