Re: SRFI-151 (Bitwise Operations) Implementation

[Linus Björnstam]

To clarify: guile does not yet do cross module inlining. It was mentioned as a 
potential thing in the thread about native guile SHA2(?) implementation. As 
such there is nothing to learn about it. Potential heuristics and how to make 
it clear to the optimizer what is simple re-exports I leave to Andy, Ludo, and 
Mark, but I feel safe saying that #:re-export is the safest bet.

-- 
  Linus Björnstam

On Fri, 10 Jan 2020, at 06:15, Frank Terbeck wrote:
> Hi,
> 
> Linus Björnstam wrote:
> > I just re-read my message and noticed it could come off as somewhat 
> > dismissive.
> > Ah, the joys of not having English as a first language while being a tired
> > father :)
> 
> Didn't strike me particularly as such. So, all is good.
> 
> 
> > I looked through your code. It is nicer than mine, but why did you chose to 
> > not
> > just re-export bindings that are available in srfi60? I don't know the
> 
> I actually didn't think about it too  much. I was more focused on making
> the implementation  match the  order used in  the specification  and add
> documentation to  all API so  it can be  followed in a  straight forward
> manner.
> 
> 
> > practical implications of not doing so, but I read in another thread of
> > potential cross-module Inlining, and helping that optimization in every way 
> > you
> > can would be a great thing for low level stuff like bit fiddling :)
> 
> Sure. I must admit that I haven't  really played a lot with Guile's com-
> piler and  optimiser. I wonder what  the impact would be  here. Remember
> the subject of said thread?
> 
> 
> Regards, Frank
> -- 
> In protocol design, perfection has been reached not when there is
> nothing left to add, but when there is nothing left to take away.
>                                                   -- RFC 1925
>