lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: define-grobs.scm properties not alphabetical


From: Mark Polesky
Subject: Re: define-grobs.scm properties not alphabetical
Date: Thu, 25 Jun 2009 12:23:38 -0700 (PDT)

Carl D. Sorensen wrote:
> I like this, because it makes the out-of-order stuff be only a
> programmer's problem, and programmers can use searches to find
> the code they're looking for.

To an extent, I would say. There's obvious value to well-organized
code. The more searches a programmer needs to make, the more time
is wasted.

By the way, thanks for taking the time to study this.
Now some new questions:

So whenever I create a function with "define-public", do I have to
make sure that its containing file is listed in the 
init-scheme-files definition in lily.scm?

And is the order of the init-scheme-files list relevant? So for
example, if files "a" and "b" are listed in that order in the
init-scheme-files list, can "a" refer to a function from "b" that
was created with define-public? If not, how are circular
references resolved (or do they just need to be avoided)?

> (define (mismatch str0 str1 ci)
>   "Return a pair containing the first character from str0 and str1 where
> the two strings differ.  If one of the strings is a substring of the other,
> the entry for that string will be #f."
>   (define (helper list0 list1 ci)
>             (cond ((and (null? list0) (null? list1))
>                     #f)
>                   ((null? list0)
>                     (cons #f (car list1)))
>                   ((null? list1)
>                     (cons (car list0) #f))
>                   ((not (if ci char-ci=? char=?) (car list0) (car list1)))
>                     (cons (car list0) (car list1))
>                   (else
>                     (helper (cdr list0) (cdr list1)))))
>
>   (helper (string->list str0) (string->list str1) ci))
>
> I like the recursion rather than the loop because the
> termination point is uncertain, so I think the loop structure is
> less idiomatic. 

Well, IIUC the "named let" syntax is basically shorthand for this,
which allows you to do this without having to explicitly call
"helper" at the bottom. So your function would translate (without
*any* change to the functionality) like so (I added the missing
parens in the 3rd clause and removed the redundant "ci" in the
bindings):

(define (mismatch str0 str1 ci)
  (let helper ((list0 (string->list str0))
               (list1 (string->list str1)))
    (cond ((and (null? list0) (null? list1))
             #f)
          ((null? list0)
             (cons #f (car list1)))
          ((null? list1)
             (cons (car list0) #f))
          ((not ((if ci char-ci=? char=?) (car list0) (car list1)))
             (cons (car list0) (car list1)))
          (else
             (helper (cdr list0) (cdr list1)))))

So you see, the loop construct is a more compact structure for
doing the same thing.

> I've used the (not ....) on the next-to-last cond clause because
> I want the recursive call to show up last in the structure.

I think I see the value in that approach, but I do like a and b
better than list0 and list1 (it's easier for me to read). So do
you approve of this (or do you prefer <test> and <expression> on
separate lines?

(define (mismatch str0 str1 ci?)
  (let loop ((a (string->list str0)) (b (string->list str1)))
    (cond ((and (null? a) (null? b)) #f)
          ((null? a) (cons #f (car b)))
          ((null? b) (cons (car a) #f))
          ((not ((if ci? char-ci=? char=?) (car a) (car b)))
              (cons (car a) (car b)))
          (else (loop (cdr a) (cdr b))))))


> Also, I think that mismatch needs a doc string because its
> function isn't transparent.
> ....
> Although it works to have both a globally-defined and
> locally-defined mismatch in ly:string-*> developers, so I'd
> recommend using different names.

Okay, I've knocked both pins down with one bowling ball by
changing "mismatch" (the function-name) to "first-diff-chars".

And one more question: what do you think of the debugger? Is it a
waste of source-code space?

> Anyway, I think this is a solid contribution.  Thanks!

Well, thank *you* for the thorough and insightful comments.
- Mark


      




reply via email to

[Prev in Thread] Current Thread [Next in Thread]