Re: Provide Scheme sandbox. (issue 5453045)

[ianhulin44]

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/