On 2011/12/08 09:07:01, dak wrote:
On 2011/12/08 00:38:07, Keith wrote:
> Very nice.
> If you make it this easy, I might learn Scheme...
> nah.
Well, it is like converting people to Emacs. Those who have gotten
burnt 20
years ago are a lost cause. You can't erase their childhood memories.
And they
look with envy and disbelief and inferiority if some newcomers
seemingly get
along without much of an apparent problem. And when they interview
them or look
over their shoulders, they don't see anything to suggest that their
apparent
mastership has cost them lots of sweat. And you ask them, and they
don't seem
to understand.
So you decide that you are just wired differently, and Emacs is not
for you.
What you don't understand is that Emacs is no longer scanning your
weaknesses of
understanding and kneeing you in the gut whenever you do something as
careless
as typing a backspace.
I am working on that "Why would I be afraid of Scheme? It seems
simple." angle.
And no mistake: if you consider working in C++ easier than in Scheme,
something
is utterly wrong.
#{ ... #} goes to some lengths to defuse Scheme programming, too. Its
power has
vastly increased in the last half year or so.
>
http://codereview.appspot.com/5453045/diff/1/Documentation/extending/scheme-tutorial.itely
> File Documentation/extending/scheme-tutorial.itely (right):
>
>
http://codereview.appspot.com/5453045/diff/1/Documentation/extending/scheme-tutorial.itely#newcode76
> Documentation/extending/scheme-tutorial.itely:76: available calling
> available with this command-line
> @example
> lilypond scheme-sandbox.ly
> @end example
I prefer "command line" but other than that, I'll bow to your
judgment. I am so
used to command lines that I don't think of mentioning them.
Not uploading a separate Rietveld patch for just that, but changing it
in my
copy.
Hi David,
A Scheme sandbox is a good idea, in fact it is *A Very Good Idea*.
However, before we focus down on this solution, might it not be a good
thing to consider this:
get LilyPond in its build to provide a library of all its scheme stuff
defined in C++.
Then in our sandbox we open a Guile REPL loading the library as an
extension, and then provide a stub lily.scm to do the stuff main.cc does
in code e.g. (define-module (lily)), and all the stuff LilyPond does in
initialization when it runs its first pass through lily.scm (like
scheme-level command-line options, building the rest of the (lily)
module by loading the component scm/*.scm files, etc. before doing its
second-pass call to actually start running procedure lilypond-main in
lily.scm).
The stub version of lily.scm could then output the guile repl prompt,
and some instructions on how to set trace and breakpoints, and then tell
the user how to start compiling your Lily source from there.
If we could get to this scenario, we have a LilyPond available as a true
extension available in scheme rather than the current rather messed-up
status of an embedded app which is trying to be extensible via guile.
To conclude, I support what you want to provide, but have a good long
think about how you provide it, as you're getting into the messy area
the Lily/Scheme interface, and this may be a bigger ask than you
originally envisaged.
Cheers,
Ian
http://codereview.appspot.com/5453045/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
