From: "Linus Björnstam" <linus.internet@fastmail.se>
To: "Frank Terbeck" <ft@bewatermyfriend.org>
Cc: guile-user@gnu.org
Subject: Re: SRFI-151 (Bitwise Operations) Implementation
Date: Thu, 09 Jan 2020 21:45:46 +0100 [thread overview]
Message-ID: <581d4068-203f-426a-95ef-2595561c63b0@www.fastmail.com> (raw)
In-Reply-To: <87muaw3i7z.fsf@ft.bewatermyfriend.org>
Hey again!
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 :)
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 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 :)
If you want you can just copy it from my module declaration. You can have it, no attribution required. Or you could just do the renaming in the #:re-export clause.
--
Linus Björnstam
On Thu, 9 Jan 2020, at 13:52, Frank Terbeck wrote:
> Linus Björnstam wrote:
> > Your bitwise-nand etc takes more arguments than they have to. They are
> > 2-argument procedures according to the spec, which gives you better performance
> > than the apply-dance you are doing now. Maybe have a bitwise-nand and a
> > bitwise-nand*?
>
> Yeah, I did that on purpose. The performance argument is probably valid,
> though. However, I don't want to extend the API. Maybe I'll put in a
> case-lambda there.
>
> Thanks for taking a look!
>
>
> 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
>
next prev parent reply other threads:[~2020-01-09 20:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 4:28 SRFI-151 (Bitwise Operations) Implementation Frank Terbeck
2020-01-09 6:50 ` Zelphir Kaltstahl
2020-01-09 7:15 ` Linus Björnstam
2020-01-09 9:10 ` Frank Terbeck
2020-01-09 12:13 ` Linus Björnstam
2020-01-09 12:52 ` Frank Terbeck
2020-01-09 17:50 ` John Cowan
2020-01-09 18:26 ` Frank Terbeck
2020-01-09 20:45 ` Linus Björnstam [this message]
2020-01-10 5:15 ` Frank Terbeck
2020-01-10 6:59 ` Linus Björnstam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=581d4068-203f-426a-95ef-2595561c63b0@www.fastmail.com \
--to=linus.internet@fastmail.se \
--cc=ft@bewatermyfriend.org \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).