C++ vs. Scheme

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

C++ vs. Scheme

David Feuer-2
What's the rationale behind the division into C++ and Scheme?  I don't
quite see why Lilypond uses C++ and Guile rather than using a serious
Scheme implementation (like PLT) and working to shift code from C++
over to Scheme.

David


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ vs. Scheme

Paul Scott-3
David Feuer wrote:
> What's the rationale behind the division into C++ and Scheme?  I don't
> quite see why Lilypond uses C++ and Guile rather than using a serious
> Scheme implementation (like PLT) and working to shift code from C++
> over to Scheme.
>  
It's simple.  Scheme code will probably never run as fast as C++.  Some
fully compiled language is needed for speed for the heavy internal
calculations.  I doesn't have to be C++ but Han-Wen is not going to
rewrite the C++ at this point.  Check the archive for these discussions.

Paul Scott



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ vs. Scheme

Pedro Kröger
Paul Scott <[hidden email]> writes:

> It's simple.  Scheme code will probably never run as fast as C++.

Unless, of couse, one uses a scheme compiler that can generate fast
code, like bigloo [1].

Pedro

Footnotes:
[1] http://www-sop.inria.fr/mimosa/fp/Bigloo/



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ vs. Scheme

David Feuer-2
On 4/4/06, Pedro Kröger <[hidden email]> wrote:
> Paul Scott <[hidden email]> writes:
>
> > It's simple.  Scheme code will probably never run as fast as C++.
>
> Unless, of couse, one uses a scheme compiler that can generate fast
> code, like bigloo [1].

Or a Scheme system like PLT that uses JIT compilation (mzscheme),
supports separate compilation for time critical sections (mzc), and
has a foreign function interface for C++ and C.  The big advantage?
Rapid development.  If Scheme isn't fast enough for some things, they
can be written in C. I suspect there are few of those.

David


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ vs. Scheme

Han-Wen Nienhuys-2
David Feuer wrote:

> On 4/4/06, Pedro Kröger <[hidden email]> wrote:
>> Paul Scott <[hidden email]> writes:
>>
>>> It's simple.  Scheme code will probably never run as fast as C++.
>> Unless, of couse, one uses a scheme compiler that can generate fast
>> code, like bigloo [1].
>
> Or a Scheme system like PLT that uses JIT compilation (mzscheme),
> supports separate compilation for time critical sections (mzc), and
> has a foreign function interface for C++ and C.  The big advantage?
> Rapid development.  If Scheme isn't fast enough for some things, they
> can be written in C. I suspect there are few of those.

The choice for GUILE is mostly historical, and I'm all for switching to
Mz, but I fear that such a move involves a tremendous amount of work,
due to API differences.

You're welcome to give an Mz port a try, if you think it's feasible.


--

Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

LilyPond Software Design
  -- Code for Music Notation
http://www.lilypond-design.com



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ vs. Scheme

Han-Wen Nienhuys-2
In reply to this post by David Feuer-2
David Feuer wrote:
> What's the rationale behind the division into C++ and Scheme?  I don't
> quite see why Lilypond uses C++ and Guile rather than using a serious
> Scheme implementation (like PLT) and working to shift code from C++
> over to Scheme.


The reason for having C++ is historical.

I'm not certain that using Scheme for everything will lower hackability
of the code, eg. I'm still not as fluent in Scheme as in C++ --with all
its shortcomings.  Also, having opaque C++ objects is convenient,
because it makes it easy to enforce invariants and maintain encapsulation.

--

Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

LilyPond Software Design
  -- Code for Music Notation
http://www.lilypond-design.com



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ vs. Scheme

David Feuer-2
On 4/4/06, Han-Wen Nienhuys <[hidden email]> wrote:

> The reason for having C++ is historical.
>
> I'm not certain that using Scheme for everything will lower hackability
> of the code, eg. I'm still not as fluent in Scheme as in C++ --with all
> its shortcomings.  Also, having opaque C++ objects is convenient,
> because it makes it easy to enforce invariants and maintain encapsulation.

If I were writing LilyPond, from scratch, alone, I'd probably write it
in Standard ML.  Unfortunately, not a lot of hackers are familiar with
that.  As for opaqueness, that's certainly possible in Scheme, and
implementations like PLT provide lots of object-oriented kinds of
things if you're into that.  What I'd really like to see is more
functional (in the FP sense) management of Stencils.  set!s make me
nervous.

David Feuer


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ vs. Scheme

Han-Wen Nienhuys-2
David Feuer wrote:

> On 4/4/06, Han-Wen Nienhuys <[hidden email]> wrote:
>
>> The reason for having C++ is historical.
>>
>> I'm not certain that using Scheme for everything will lower hackability
>> of the code, eg. I'm still not as fluent in Scheme as in C++ --with all
>> its shortcomings.  Also, having opaque C++ objects is convenient,
>> because it makes it easy to enforce invariants and maintain encapsulation.
>
> If I were writing LilyPond, from scratch, alone, I'd probably write it
> in Standard ML.  Unfortunately, not a lot of hackers are familiar with

Well, me too  ;) i'd probably use it as an excuse to learn ocaml or
similar. However, it's not the case, so we'll have to live with bits of C++.

> that.  As for opaqueness, that's certainly possible in Scheme, and
> implementations like PLT provide lots of object-oriented kinds of
> things if you're into that.  What I'd really like to see is more
> functional (in the FP sense) management of Stencils.  set!s make me
> nervous.

Yes, me too.

Feel free to rewrite them more functionally.

--

Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

LilyPond Software Design
  -- Code for Music Notation
http://www.lilypond-design.com



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ vs. Scheme

David Feuer-2
In reply to this post by Han-Wen Nienhuys-2
On 4/4/06, Han-Wen Nienhuys <[hidden email]> wrote:

> The choice for GUILE is mostly historical, and I'm all for switching to
> Mz, but I fear that such a move involves a tremendous amount of work,
> due to API differences.
>
> You're welcome to give an Mz port a try, if you think it's feasible.

Having now looked at a little more of the code, I don't think a PLT
port would be feasible right now.  If at a later date the
functionality provided by C++ and Scheme are sufficiently separated,
or most of the functionality of the C++ code gets shifted over to
Scheme, it might become reasonable.

David Feuer


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel