Re: [r6rs-discuss] Implementors' intentions concerning R6RS

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Neil Jerram]

Elf <elf@ephemeral.net> writes:

> (i usually start people off with guile nowadays,
> despite its non-r5 compliance, as the wizard book is still around r4 material.)

I hope you don't mind me emailing you in response to your r6rs post;
I'm one of the Guile developers.

I wondered if you could say more about the r5-non-compliance that you
perceive?  I thought we had solved all r5 compliance issues by now.

(Last time I heard it claimed that Guile was not r5-compliant, I
followed it up, and it was to do with a couple of tests relying on the
order of evaluation of letrec initializers.  But that is fixed now.)

Many thanks,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Elf]

On Sun, 28 Oct 2007, Neil Jerram wrote:

> Elf <elf@ephemeral.net> writes:
>
>> (i usually start people off with guile nowadays,
>> despite its non-r5 compliance, as the wizard book is still around r4 material.)
>
> I hope you don't mind me emailing you in response to your r6rs post;
> I'm one of the Guile developers.
>
> I wondered if you could say more about the r5-non-compliance that you
> perceive?  I thought we had solved all r5 compliance issues by now.
>
> (Last time I heard it claimed that Guile was not r5-compliant, I
> followed it up, and it was to do with a couple of tests relying on the
> order of evaluation of letrec initializers.  But that is fixed now.)
>
> Many thanks,
>     Neil
>

apologies.  im slightly out of date with my guile versions (i last used guile
hardcore around 1.4/1.6) so my information is incorrect.  guile is fully
r5 compliant now to the best of my knowledge.  (scwm still uses 1.4.1, which
is why i still use 1.4.1)  no offense intended.

-elf



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Neil Jerram]

Many thanks for your quick response, and I appreciate your kind words
about Guile.  The specific issue that I mentioned is still present in
1.4.1, so if you've tried running the r5rs_pitfalls test with 1.4.1,
it would fail for at least that reason; and I suspect there may be a
couple of other issues that we've fixed since then.

In case you do come across any R5 issues with the current Guile
(1.8.x), please do let us know, as we really do want Guile to be
R5RS-compliant.

FWIW, my feeling about R6 as a whole is that it is not aligned with
Guile's objective - remembering that the latter is not just to be a
Scheme implementation, but a Scheme implementation in the form of an
embeddable library that is useful for extending applications.  But my
thoughts on this haven't fully crystallised yet.

Regards,
        Neil


Elf <elf@ephemeral.net> writes:

> for what its worth, i still start people off on guile 1.4.1 when i teach them
> because a) the help system is excellent, b) i can show it to them in action
> via scwm, and c) i have a very fond spot for guile, as its the first real
> scheme implementation i used.  most of my students have also found it to be
> the easiest and most comfortable to work in initially.  i did not mean
> to offend or give misinformation about the current state of guile.  my
> most sincere apologies.
>
> -elf
>
>
> On Sun, 28 Oct 2007, Neil Jerram wrote:
>
>> Elf <elf@ephemeral.net> writes:
>>
>>> (i usually start people off with guile nowadays,
>>> despite its non-r5 compliance, as the wizard book is still around r4 material.)
>>
>> I hope you don't mind me emailing you in response to your r6rs post;
>> I'm one of the Guile developers.
>>
>> I wondered if you could say more about the r5-non-compliance that you
>> perceive?  I thought we had solved all r5 compliance issues by now.
>>
>> (Last time I heard it claimed that Guile was not r5-compliant, I
>> followed it up, and it was to do with a couple of tests relying on the
>> order of evaluation of letrec initializers.  But that is fixed now.)
>>
>> Many thanks,
>>     Neil
>>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> FWIW, my feeling about R6 as a whole is that it is not aligned with
> Guile's objective - remembering that the latter is not just to be a
> Scheme implementation, but a Scheme implementation in the form of an
> embeddable library that is useful for extending applications.  But my
> thoughts on this haven't fully crystallised yet.

Speaking of this, I hope you (Guile developers) don't mind my answer to
Marc Feeley wrt. R6RS, which he posted on `r6rs-discuss' [0].  We
haven't had a debate about it here, but I'd be glad if we had one.

BTW, as time passes, I am more and more doubtful about the "embeddable
library" argument.  After all, if we work on a Scheme implementation,
that's certainly because we want to write Scheme.  Sure we want to make
it easy to interface with existing code written in C, but we also want
to write *more* Scheme code.  With that goal in mind, the pure
interpreter approach is not sustainable (although successful PLs have
been successful although they provided only interpreters for a long
time)...

Thanks,
Ludovic.

[0] http://lists.r6rs.org/pipermail/r6rs-discuss/2007-October/003351.html


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> FWIW, my feeling about R6 as a whole is that it is not aligned with
>> Guile's objective - remembering that the latter is not just to be a
>> Scheme implementation, but a Scheme implementation in the form of an
>> embeddable library that is useful for extending applications.  But my
>> thoughts on this haven't fully crystallised yet.
>
> Speaking of this, I hope you (Guile developers) don't mind my answer to
> Marc Feeley wrt. R6RS, which he posted on `r6rs-discuss' [0].  We
> haven't had a debate about it here, but I'd be glad if we had one.

Well I didn't mind.  I was happy to see that Marc had received a
statement from "Guile", and I'm happy with what you said.

> BTW, as time passes, I am more and more doubtful about the "embeddable
> library" argument.  After all, if we work on a Scheme implementation,
> that's certainly because we want to write Scheme.  Sure we want to make
> it easy to interface with existing code written in C, but we also want
> to write *more* Scheme code.

^ Agreed up to here...

>  With that goal in mind, the pure
> interpreter approach is not sustainable

... but I don't see what you mean by this.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Ludovic Courtès]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:

>>  With that goal in mind, the pure
>> interpreter approach is not sustainable
>
> ... but I don't see what you mean by this.

He, that was sort of a teaser.  ;-)

When I started using Guile, I was fully in sync with the "embeddable
library" approach, which means that I'd write, say, 75% of an
application in C, and then arrange to have the remainder written in
Scheme in an extensible fashion.

But I started really enjoying Scheme and wanting to write less C, more
Scheme.  So why bother writing C at all when I could avoid it?  Well,
for "performance reasons".  And what are those "performance reasons"?
The interpreter is pretty slow, which is definitely not due to inherent
limitations of the language, but to the implementation.

I'm convinced that it's possible to write a Scheme interpreter much
faster than ours.  So I think that's one route we should take in 1.9.
The next step would be to have a compiler (to byte code, to C,
whatever).  However, I think the interpreter should keep playing a
central role in Guile (because it always did, and because it's often
convenient to work with an interpreter), which is why I would consider
improving/rewriting the interpreter a major goal for 1.9.

Maybe we should start a discussion about what we'd like to see in 1.9?
:-)

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Julian Graham]

> When I started using Guile, I was fully in sync with the "embeddable
> library" approach, which means that I'd write, say, 75% of an
> application in C, and then arrange to have the remainder written in
> Scheme in an extensible fashion.
>
> But I started really enjoying Scheme and wanting to write less C, more
> Scheme.  So why bother writing C at all when I could avoid it?  Well,
> for "performance reasons".  And what are those "performance reasons"?
> The interpreter is pretty slow, which is definitely not due to inherent
> limitations of the language, but to the implementation.
>
> I'm convinced that it's possible to write a Scheme interpreter much
> faster than ours.  So I think that's one route we should take in 1.9.
> The next step would be to have a compiler (to byte code, to C,
> whatever).  However, I think the interpreter should keep playing a
> central role in Guile (because it always did, and because it's often
> convenient to work with an interpreter), which is why I would consider
> improving/rewriting the interpreter a major goal for 1.9.
>
> Maybe we should start a discussion about what we'd like to see in 1.9?
> :-)


Well, for what it's worth, faster live "interpretation" of Scheme is
really important to me, whether that means some kind of Scheme JIT
compilation a la GNU Lightning or whatever.  I'm still fairly wed to
being able to "script" my C code with Scheme dynamically, so I hope
Guile's not moving away from that significantly.  Other non-specific,
poorly-researched desires for 1.9:

* Faster GC (this is probably pretty similar to "faster interpretation")

* Integrated debugging and profiling tools

* Guile was initially proposed as a multi-language scripting platform;
is that still part of the mission?

* Not related to 1.9 itself, but maybe a cleanup / redesign of the web
page, including a cleanup of active projects, better integration with
Savannah for bug tracking, etc.

* Thorough updating of the documentation

* Integration with Free Software VMs -- Bigloo currently lets you
compile Scheme to CIL; it would be neat if you could do the same with
Guile and then run on top of DotGNU.  Or Kaffe.  Or anything else.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> He, that was sort of a teaser.  ;-)
>
> When I started using Guile, I was fully in sync with the "embeddable
> library" approach, which means that I'd write, say, 75% of an
> application in C, and then arrange to have the remainder written in
> Scheme in an extensible fashion.
>
> But I started really enjoying Scheme and wanting to write less C, more
> Scheme.  So why bother writing C at all when I could avoid it?  Well,
> for "performance reasons".

Completely agreed so far, except that there is another reason for
writing C code: simply to interface with a C library that already
exists.  There are a few of those out there. :-)

I have two lines of thought that are compatible with your account, if
not exactly the same.

1. The fundamental premise of writing in a scripting language must be
   that it is easier / quicker / more fun / more effective than
   writing in C.  Therefore one must want to maximize the amount of
   scripting language code that one writes, compared to the C code.

2. I originally thought that a software-component-using-Guile should
   typically be a complete application - such as Gnucash.  Now I think
   that a software-component-using-Guile should ideally be a library -
   such as a module providing operations on financial objects - and
   that applications should be created, in Scheme, through relatively
   trivial composition of sophisticated libraries.

> And what are those "performance reasons"?
> The interpreter is pretty slow, which is definitely not due to inherent
> limitations of the language, but to the implementation.

I haven't personally been gated by this yet, but I can't disagree with
it.

> I'm convinced that it's possible to write a Scheme interpreter much
> faster than ours.

It must be possible, because other implementations have done it.

It's difficult at this point to avoid a possibly unwelcome question:
what makes Guile Guile, and why wouldn't we be better off contributing
our resources to an implementation that already is faster?

(I believe that we _do_ have a collection of features that makes Guile
currently unique, but I can't rule out the possibility that another
implementation might be open to accepting enhancements that would
incorporate these features.  But perhaps someone else has done the
analysis, and so _can_ rule this out.)

>  So I think that's one route we should take in 1.9.
> The next step would be to have a compiler (to byte code, to C,
> whatever).  However, I think the interpreter should keep playing a
> central role in Guile (because it always did, and because it's often
> convenient to work with an interpreter), which is why I would consider
> improving/rewriting the interpreter a major goal for 1.9.

Those are welcome goals, and I'm sure that I would appreciate the
increased performance.  

> Maybe we should start a discussion about what we'd like to see in 1.9?
> :-)

The kinds of things that I am most interested in are:

- finishing off the debugging infrastructure

- progressive completion and polishing of the manuals

- improving tracking, provision and regression testing of the
  available Guile add-on libraries; also providing interesting
  examples of how interesting things can be achieved by combining such
  libraries

- possibly integrating with other systems' library repositories (such
  as Snow)

- in general, any kind of situation where we can create value just by
  putting existing stuff together (another possible example: the Emacs
  Lisp translation support + existing Emacs Lisp libraries), or by
  better tracking of what's available.

The phrase "what we'd like to see" is IMO unrealistic, though.  I
don't think any of us (Guile developers) can commit to achieving
particular things by particular dates, and I wouldn't wait to delay a
new release, once a sufficient amount of interesting new stuff has
accumulated, because a particular target has not been met.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Neil Jerram]

"Julian Graham" <joolean@gmail.com> writes:

> Well, for what it's worth, faster live "interpretation" of Scheme is
> really important to me, whether that means some kind of Scheme JIT
> compilation a la GNU Lightning or whatever.  I'm still fairly wed to
> being able to "script" my C code with Scheme dynamically, so I hope
> Guile's not moving away from that significantly.

I don't think anyone intends that.

>  Other non-specific,
> poorly-researched desires for 1.9:
>
> * Faster GC

From the recent experiments vs. Boehm GC, my impression was that
Guile's GC is already pretty good and that there is little scope for
improvement here.

> (this is probably pretty similar to "faster interpretation")

Actually that's a completely different matter.  There are lots of
options here; for example, Keisuke Nishida's VM work.

> * Integrated debugging and profiling tools

Absolutely.

> * Guile was initially proposed as a multi-language scripting platform;
> is that still part of the mission?

IMO, after umpteen years of not-happening, it would be silly for us to
say that this is still a core part of the mission.  But technically I
think this is still an interesting idea.  There's a load of half-done
stuff out there: Thomas Bushnell's Python, Ian Bicking's Tcl, Ctax, my
Elisp; a good first step would be just to pull that all together, and
see if there's a coherent big picture.  For Python there's also the
possibility of leveraging PyPy.

> * Not related to 1.9 itself, but maybe a cleanup / redesign of the web
> page,

Yes, in principle.  Needs someone to volunteer though.

> including a cleanup of active projects,

That's in my list too.

> better integration with Savannah for bug tracking, etc.

I started looking at this this week.  After a bit of thought, I'm
thinking that even if we automatically gatewayed bug-guile emails into
the Savannah tracker, we'd still want to review the new bugs as they
appear - and so we might as well just cut and paste them from
bug-guile by hand.

> * Thorough updating of the documentation

Agreed.  That's on my list, but one can't have too much help!

> * Integration with Free Software VMs -- Bigloo currently lets you
> compile Scheme to CIL; it would be neat if you could do the same with
> Guile and then run on top of DotGNU.  Or Kaffe.  Or anything else.

Yes, that would be nice.  Except I'm not keen on following Microsoft
"standards".  Java VM and/or Parrot (is that still happening?) would
be fine.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Andy Wingo]

Hi Neil,

On Sun 28 Oct 2007 20:28, Neil Jerram <neil@ossau.uklinux.net> writes:

> FWIW, my feeling about R6 as a whole is that it is not aligned with
> Guile's objective - remembering that the latter is not just to be a
> Scheme implementation, but a Scheme implementation in the form of an
> embeddable library that is useful for extending applications.  But my
> thoughts on this haven't fully crystallised yet.

After having lots of plane time recently to read r6rs, I don't think
that r6rs is essentially unaligned with Guile. It's simply that a common
Guile use case is unspecified, viz embedding Scheme in a C app. If you
noticed, not even the REPL interface is specified in r6rs:

http://www.r6rs.org/final/html/r6rs-rationale/r6rs-rationale-Z-H-10.html#node_chap_8

Personally I feel that the pendelum has swung perhaps a bit too far in
the static direction, but that if people realize that the rnrs process
is up for change as Mitch Wand mentioned in the recent Scheme Workshop,
that more traditionally dynamic interfaces can be returned to the
standard.

Regards,

Andy
-- 
http://wingolog.org/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:

>> But I started really enjoying Scheme and wanting to write less C, more
>> Scheme.  So why bother writing C at all when I could avoid it?  Well,
>> for "performance reasons".
>
> Completely agreed so far, except that there is another reason for
> writing C code: simply to interface with a C library that already
> exists.  There are a few of those out there. :-)

Of course.  But I mean: when you *could* avoid writing C, e.g., because
you don't rely on any specific C library's features, it often occurs
that you actually can't avoid writing C because of performance reasons.

> 1. The fundamental premise of writing in a scripting language must be
>    that it is easier / quicker / more fun / more effective than
>    writing in C.  Therefore one must want to maximize the amount of
>    scripting language code that one writes, compared to the C code.

Agreed (although I'm not fond of the term "scripting language", since it
conveys the idea that the language, not the implementation, is limited
to a particular use case).

> 2. I originally thought that a software-component-using-Guile should
>    typically be a complete application - such as Gnucash.  Now I think
>    that a software-component-using-Guile should ideally be a library -
>    such as a module providing operations on financial objects - and
>    that applications should be created, in Scheme, through relatively
>    trivial composition of sophisticated libraries.

Agreed.  Still, as you compose more and more such libraries through
Guile, you end up having more and more Scheme code, and (potentially)
more and more performance concerns.  :-)

> It's difficult at this point to avoid a possibly unwelcome question:
> what makes Guile Guile, and why wouldn't we be better off contributing
> our resources to an implementation that already is faster?

Indeed, that's a good question, although a tough one for someone that's
too "emotionally involved" with Guile.  ;-)

To be honest, I don't know other implementations well enough to compare
available features.  I have the feeling that Guile's public (Scheme) API
is pretty good and quite rich.  We have POSIX multithreading, which not
all implementations support; we have a nice module system (although it
doesn't play well with macros ;-)), and of course a good and
well-documented C API.  Your new debugging infrastructure contributes to
Guile's friendliness.  Kevin's Guile-Lint is also an important
contribution to Guile's usability IMO (it deserves more advertisement).
It seems that we also have a set of nice libraries/bindings in a variety
of domains.

> The kinds of things that I am most interested in are:
>
> - finishing off the debugging infrastructure
>
> - progressive completion and polishing of the manuals
>
> - improving tracking, provision and regression testing of the
>   available Guile add-on libraries; also providing interesting
>   examples of how interesting things can be achieved by combining such
>   libraries
>
> - possibly integrating with other systems' library repositories (such
>   as Snow)
>
> - in general, any kind of situation where we can create value just by
>   putting existing stuff together (another possible example: the Emacs
>   Lisp translation support + existing Emacs Lisp libraries), or by
>   better tracking of what's available.

These are interesting and important goals.  I'm not sure about the last
item, though, being unfamiliar with Emacs Lisp support in Guile.

> The phrase "what we'd like to see" is IMO unrealistic, though.  I
> don't think any of us (Guile developers) can commit to achieving
> particular things by particular dates, and I wouldn't wait to delay a
> new release, once a sufficient amount of interesting new stuff has
> accumulated, because a particular target has not been met.

Of course we can't commit to anything.  Still, it's good if each of us
can say what he'd like to work on in HEAD, and get feedback from others.
It helps find motivation, too.  So far, I think we just hadn't discussed
any plan for 1.9.  So it's good we've opened the debate.  :-)

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Ludovic Courtès]

Hi,

Adding my two cents to the "wish list"...

"Julian Graham" <joolean@gmail.com> writes:

> Well, for what it's worth, faster live "interpretation" of Scheme is
> really important to me, whether that means some kind of Scheme JIT
> compilation a la GNU Lightning or whatever.

I believe the major interpreter performance improvements are to be
gained by algorithmic optimizations (e.g., closure invocation, variable
lookup), rather than micro-optimizations such as JIT.  That said, JIT is
a fascinating domain.  :-)

> * Faster GC (this is probably pretty similar to "faster interpretation")

I'm (still) interested in comparing the space/time tradeoff in Guile and
the `libgc'-based Guile.  We'll see.

Besides, I think using libgc would yield a number of practical
improvements for the end user: `scm_set_smob_mark ()' would become
useless in most cases and so would `scm_dynwind_free ()',
`scm_set_smob_free ()' could be avoided almost entirely in guile-core,
memory leaks would become less likely in the presence of non-local
exists, marking a tree-like structure would just work (see
http://thread.gmane.org/gmane.lisp.guile.bugs/3558), etc.

> * Integrated debugging and profiling tools
>
> * Guile was initially proposed as a multi-language scripting platform;
> is that still part of the mission?

As Neil suggested, I'd say "no" for the time being.

> * Not related to 1.9 itself, but maybe a cleanup / redesign of the web
> page, including a cleanup of active projects, better integration with
> Savannah for bug tracking, etc.

Right.  I've been meaning to update the projects page for a while
actually...

> * Thorough updating of the documentation
>
> * Integration with Free Software VMs -- Bigloo currently lets you
> compile Scheme to CIL; it would be neat if you could do the same with
> Guile and then run on top of DotGNU.  Or Kaffe.  Or anything else.

I'm not too fond of CIL/Java bytecode, but choosing the bytecode format
should not be the most difficult thing.  ;-)

OK, so my goals for 1.9 would be:

  * Evaluate `libgc'-based Guile (see above).

  * Rewrite the interpreter in Scheme (or a subset thereof), with a
    tiny Scheme-to-C compiler.  That could be done in such a way that we
    could re-use, e.g., the memoization and unmemoization code that
    already exists in the first step.

  * Provide a documented C doc snarfing tool, written in Scheme, with a
    public Scheme doc snarfing API.  I started looking at it based on
    the modules I wrote for doc-snarfing in Guile-{Reader,Avahi,GnuTLS}.

  * Provide some Unicode support.  The hardest part, I think, is that
    we'd probably need to rewrite/extend the C port API.

Comments?

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Julian Graham]

> From the recent experiments vs. Boehm GC, my impression was that
> Guile's GC is already pretty good and that there is little scope for
> improvement here.

Really?  My (extremely unscientific) experiments were showing
something like <10ms for C->Guile calls that didn't involve GC, and
~100ms for ones that did.


> > * Not related to 1.9 itself, but maybe a cleanup / redesign of the web
> > page,
>
> Yes, in principle.  Needs someone to volunteer though.

It might be worthwhile to put out a call to the GNU webmasters.  Or
just post an ad on Savannah -- I actually got several responses to
something I posted looking for testers for SDOM, which has about zero
name recognition.  I bet lots of people would be interested in getting
a chance to redesign Guile's page.


> Yes, that would be nice.  Except I'm not keen on following Microsoft
> "standards".  Java VM and/or Parrot (is that still happening?) would
> be fine.

Parrot had a new release two days ago.  Whether they're still on
peoples' minds (and whether they're still gonna host Perl6), I dunno.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Klaus Schilling]

From: Neil Jerram <neil@ossau.uklinux.net>
Subject: Re: [r6rs-discuss] Implementors' intentions concerning R6RS
Date: Tue, 30 Oct 2007 22:53:16 +0000

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> > I'm convinced that it's possible to write a Scheme interpreter much
> > faster than ours.
> 
> It must be possible, because other implementations have done it.

No, guile is a hell of a fast interpreter.
Faster implementations either aren't interpreters
thus losing flexibility
or pretty sloppy concerning  garbage collection stuff.

> 
> It's difficult at this point to avoid a possibly unwelcome question:
> what makes Guile Guile, 

the agenda Richard M. Stallman gave out a dozen of years ago

> and why wouldn't we be better off contributing
> our resources to an implementation that already is faster?
> 
as said, their speed is achieved at a high cost 

Klaus Schilling


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Ludovic Courtès]

Hi,

Klaus Schilling <schilling.klaus@web.de> writes:

> No, guile is a hell of a fast interpreter.
> Faster implementations either aren't interpreters
> thus losing flexibility
> or pretty sloppy concerning  garbage collection stuff.

I don't think so.  Try out, for instance, Bigloo's *interpreter*.

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Klaus Schilling]

From: ludo@gnu.org (Ludovic Courtès)
Subject: Re: [r6rs-discuss] Implementors' intentions concerning R6RS
Date: Sat, 03 Nov 2007 12:14:33 +0100

> Hi,
> 
> Klaus Schilling <schilling.klaus@web.de> writes:
> 
> > No, guile is a hell of a fast interpreter.
> > Faster implementations either aren't interpreters
> > thus losing flexibility
> > or pretty sloppy concerning  garbage collection stuff.
> 
> I don't think so.  Try out, for instance, Bigloo's *interpreter*.

The Bigloo Interpreter is crippled beyond acceptability:



    Bigloo-Manual> Bigloo includes an interpreter. Unfortunately, the
    Bigloo-Manual> language accepted by the interpreter is a proper
    Bigloo-Manual> subset of that accepted by the compiler. The main
    Bigloo-Manual> differences are: No foreign ob jects can be handled
    Bigloo-Manual> by interpreter.  Classes of the ob ject system
    Bigloo-Manual> cannot be declared within interpreted code.  The
    Bigloo-Manual> interpreter ignores modules, and has a unique
    Bigloo-Manual> global environment.


    Klaus Schilling


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Klaus Schilling]

From: Neil Jerram <neil@ossau.uklinux.net>
Subject: Re: [r6rs-discuss] Implementors' intentions concerning R6RS
Date: Sun, 28 Oct 2007 18:16:43 +0000

> Elf <elf@ephemeral.net> writes:
> 
> > (i usually start people off with guile nowadays,
> > despite its non-r5 compliance, as the wizard book is still around r4 material.)
> 
> I hope you don't mind me emailing you in response to your r6rs post;
> I'm one of the Guile developers.
> 
> I wondered if you could say more about the r5-non-compliance that you
> perceive?  I thought we had solved all r5 compliance issues by now.

no, as Guile's symbols are still case-sensitive which is illegal in r5rs

Klaus Schilling


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Ludovic Courtès]

Hi,

Klaus Schilling <schilling.klaus@web.de> writes:

> no, as Guile's symbols are still case-sensitive which is illegal in r5rs

You can switch it off using "(read-enable 'case-insensitive)".

Any other R5RS incompatibility?  :-)

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Besides, I think using libgc would yield a number of practical
> improvements for the end user: `scm_set_smob_mark ()' would become
> useless in most cases

I think I understand the point here, and it seems to me that this is
an improvement for the developer, not for the end user; and IMO not a
significant one (because it's pretty trivial to write a smob mark
function).  It also implies a performance cost, from scanning regions
of SMOB memory that Guile currently knows cannot contain heap
pointers.

> and so would `scm_dynwind_free ()',
> `scm_set_smob_free ()' could be avoided almost entirely in guile-core,
> memory leaks would become less likely in the presence of non-local
> exists, marking a tree-like structure would just work (see
> http://thread.gmane.org/gmane.lisp.guile.bugs/3558), etc.

(I don't understand these ones in detail, so there may well be
significant benefits here.)

> OK, so my goals for 1.9 would be:
>
>   * Evaluate `libgc'-based Guile (see above).
>
>   * Rewrite the interpreter in Scheme (or a subset thereof), with a
>     tiny Scheme-to-C compiler.  That could be done in such a way that we
>     could re-use, e.g., the memoization and unmemoization code that
>     already exists in the first step.

Interesting.  Do you think that that would be a lot faster than the C
code we have now?

>   * Provide a documented C doc snarfing tool, written in Scheme, with a
>     public Scheme doc snarfing API.  I started looking at it based on
>     the modules I wrote for doc-snarfing in Guile-{Reader,Avahi,GnuTLS}.

Great; I've been thinking that we need this too.

>   * Provide some Unicode support.  The hardest part, I think, is that
>     we'd probably need to rewrite/extend the C port API.

I'm pretty Unicode-ignorant, but I've read enough to think that this
area is important.  Is the problem with the C API just that it has
"char" everywhere?

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I think I understand the point here, and it seems to me that this is
> an improvement for the developer, not for the end user; and IMO not a
> significant one (because it's pretty trivial to write a smob mark
> function).  It also implies a performance cost, from scanning regions
> of SMOB memory that Guile currently knows cannot contain heap
> pointers.

It really isn't that clear what performance impact libgc's pervasive
scanning has.

>>   * Rewrite the interpreter in Scheme (or a subset thereof), with a
>>     tiny Scheme-to-C compiler.  That could be done in such a way that we
>>     could re-use, e.g., the memoization and unmemoization code that
>>     already exists in the first step.
>
> Interesting.  Do you think that that would be a lot faster than the C
> code we have now?

Note that whether it's implemented by hand in C or compiled to C doesn't
make a significant difference.  The main optimizations I have in mind
are the following:

  * heap-allocation-free closure invocations, which can be achieved by
    storing a closure's arguments into a stack-allocated C array or,
    even better, in registers (of course, invoking closures with rest
    arguments would still require allocating an argument list);

  * O(1) ILOC lookup, compared to the current O(N * M) algorithm, where
    N is the frame number and M the position of the variable within that
    frame's environment;

  * no C function call overhead for tail(-recursive) calls.

I'm sure there's much to gain from these.  Implementing it in Scheme
would improve maintainability while keeping room for future
improvements.

> I'm pretty Unicode-ignorant, but I've read enough to think that this
> area is important.  Is the problem with the C API just that it has
> "char" everywhere?

Yes, mostly.  That said, I'm not sure exactly how the C I/O API would
need to be changed.

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I think I understand the point here, and it seems to me that this is
>> an improvement for the developer, not for the end user; and IMO not a
>> significant one (because it's pretty trivial to write a smob mark
>> function).  It also implies a performance cost, from scanning regions
>> of SMOB memory that Guile currently knows cannot contain heap
>> pointers.
>
> It really isn't that clear what performance impact libgc's pervasive
> scanning has.

Fair enough, let's wait and see what further investigation reveals.

>>>   * Rewrite the interpreter in Scheme (or a subset thereof), with a
>>>     tiny Scheme-to-C compiler.  That could be done in such a way that we
>>>     could re-use, e.g., the memoization and unmemoization code that
>>>     already exists in the first step.
>>
>> Interesting.  Do you think that that would be a lot faster than the C
>> code we have now?
>
> Note that whether it's implemented by hand in C or compiled to C doesn't
> make a significant difference.  The main optimizations I have in mind
> are the following:

These sound really interesting!  Do we need to wait for a rewrite of
the core interpreter, though, or could we try doing this in the
current code?

>   * heap-allocation-free closure invocations, which can be achieved by
>     storing a closure's arguments into a stack-allocated C array or,
>     even better, in registers (of course, invoking closures with rest
>     arguments would still require allocating an argument list);
>
>   * O(1) ILOC lookup, compared to the current O(N * M) algorithm, where
>     N is the frame number and M the position of the variable within that
>     frame's environment;

Are you sure the current algorithm is O(N*M)?  I would have said
O(N+M).

>   * no C function call overhead for tail(-recursive) calls.

I thought that was mostly achieved already, by extensive use of
gotos.  But I guess there must be important cases that I've not
noticed.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Ludovic Courtès]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> These sound really interesting!  Do we need to wait for a rewrite of
> the core interpreter, though, or could we try doing this in the
> current code?

The current code is very tricky to work with.  I once tried to change
environments to use vectors instead of lists so that `scm_ilookup ()'
would become O(N), but it proved hard to do and I eventually bailed out
(IIRC the issue that stopped me had to do with rest arguments handling,
currently handled by `SCM_CDRLOC', which assumes that a frame's
variables are contained in a list, if you see what I mean).

>>   * heap-allocation-free closure invocations, which can be achieved by
>>     storing a closure's arguments into a stack-allocated C array or,
>>     even better, in registers (of course, invoking closures with rest
>>     arguments would still require allocating an argument list);
>>
>>   * O(1) ILOC lookup, compared to the current O(N * M) algorithm, where
>>     N is the frame number and M the position of the variable within that
>>     frame's environment;
>
> Are you sure the current algorithm is O(N*M)?  I would have said
> O(N+M).

Oh yes, you're right (these are two non-nested `for' loops).

>>   * no C function call overhead for tail(-recursive) calls.
>
> I thought that was mostly achieved already, by extensive use of
> gotos.  But I guess there must be important cases that I've not
> noticed.

You're right too.  :-)

Anyway, it looks like there are opportunity for performance
improvements, and that could be an opportunity to switch to a
compiled-to-C meta-circular interpreter (as seen in SICP).

(It looks like I'm "dreaming" too much compared to my free time, but I
hope others could adopt the idea!)

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel