Re: [Chicken-users] read-byte, etc.

[Hans Bulfone]

hi,

On Mon, Apr 10, 2006 at 06:52:07AM +0200, felix winkelmann wrote:
> On 4/6/06, Benedikt Rosenau <address@hidden> wrote:
> > On Thu, Apr 06, 2006 at 08:41:55AM -0500, Alex Shinn wrote:
> >
> > > It looks like what the compiled C code ends up doing is just the
> > > opposite of what you expected.  Binding read-char in a LET creates a
> > > closure, and the code for accessing a closure reference seems to take
> > > one extra level of indirection compared to a global reference.  Or
> > > something :) But the difference is so small I wouldn't worry about it.
> >
> > The compiler assumes usual-integrations by default. So, it can resolve
> > procedure calls at compile time. The level of indirection introduced by
> > a LET harms the performance.
> 
> Generally, yes, but not for `read-char'.. The extra binding in the let
> is just needed
> for r5rs-compliance. On the other hand the latter only matters when defining
> standard procedures. I recommend just removing it.

i'm not sure if i understand correctly...
i've looked a bit into usual-integrations and the syntax-case module
system and came to the following conclusions:

- the compiler normally assumes that +, -, read-char, etc. are not globally
  redefined and resolves the bindings at compile time
- the numbers egg can redefine +, -, etc. because code that uses it is
  compiled with (declare (not standard-bindings + - ...))
- read-char can be redefined in a syntax-case module that imports the
  utf8 module because it creates a local binding.
- but importing the utf8 module into the toplevel should not be able
  to change read-char for code compiled with usual-integrations,
  even if that code is loaded after the utf8 module is imported.

if that is correct, i guess i should remove the let.

> (But Alex' posted code already is the fastest possible method, so this
> is just a remark on the side).

somehow i don't feel comfortable with using ##sys#... procedures when
not really needed, so i'm not using it so far.

thanks,
hans.