Re: music-function type-check options

[Mark Polesky]

----- Original Message ----
> From: Neil Puttock <address@hidden>
> To: Mark Polesky <address@hidden>
> Cc: lilypond-devel <address@hidden>
> Sent: Sunday, August 16, 2009 2:36:39 PM
> Subject: Re: music-function type-check options
> 
> 2009/8/16 Mark Polesky :
> 
> > I didn't really ask anything in the previous post. What I
> > meant to ask was: Are there any predicates here that I
> > *shouldn't* add to the alist? Any objections to including
> > all the "C++ predicates"? If no one objects, I'll make a
> > patch that includes everything.
> 
> Might I suggest an alternative approach, which will work with any predicate?
> 
> Since the real issue is the vagueness of `unknown', why not tweak
> `type-name' so it will instead return the name of the predicate if
> there's no match in type-p-name-alist?  This also has the added
> benefit of producing useful information with user-defined predicates.
> 
> (define-public (type-name predicate)
>   (let ((entry (assoc predicate type-p-name-alist)))
>     (if (pair? entry) (cdr entry)
>     (symbol->string (procedure-name predicate)))))

Neil, this is very clever. I might tweak it a little (remove
"?" if it's the last character etc.), but I think I'll
implement this idea. However, I might argue that by your
logic, we should get rid of the alist altogether. But I'm
not in favor of that. One additional benefit to adding
predicates to the alist is that it could be used to generate
a list of acceptable music-function type-check options in
the docs. This is something you and I discussed a while ago
http://lists.gnu.org/archive/html/lilypond-devel/2009-06/msg00622.html
So, unless I hear otherwise, I'll put together a patch with
all the options. Of course I won't push it without final
approval.

- Mark