Hallo,
Doing a bit of search, I've found:
http://www.math.purdue.edu/~lucier/gambit-srfis/
Is this the preferred implementation of this SRFI for Gambit-C?
Cheers,
Afficher les réponses par date
On Wed, 2009-04-15 at 14:14 +0000, Alex Queiroz wrote:
Hallo,
Doing a bit of search, I've found:
http://www.math.purdue.edu/~lucier/gambit-srfis/
Is this the preferred implementation of this SRFI for Gambit-C?
Well, it was *my* preferred implementation ;-).
At one point my implementations of SRFI 13 and 14 used the internal Gambit API to properly check the types and bounds of arguments and raise exceptions with the proper continuations. That API has changed since I wrote those, but there are only a few macros and types that have to be rewritten to bring it up to date, but I don't have time to do so now.
Also, I use a very naive bitmap implementation for character sets, which is OK for Latin-1 but not for Unicode, so a different data structure should be used for that. Haven't done that, either.
Brad
Hallo,
On 4/15/09, Bradley Lucier lucier@math.purdue.edu wrote:
At one point my implementations of SRFI 13 and 14 used the internal Gambit API to properly check the types and bounds of arguments and raise exceptions with the proper continuations. That API has changed since I wrote those, but there are only a few macros and types that have to be rewritten to bring it up to date, but I don't have time to do so now.
It built flawlessly with 4.4.2, but then it may give unpleasant surprises at runtime. I'll try to spot the needed changes.
Also, I use a very naive bitmap implementation for character sets, which is OK for Latin-1 but not for Unicode, so a different data structure should be used for that. Haven't done that, either.
Hmmm. this is more serious since I tend to use UTF-8 encoding.
Cheers,
On 15-Apr-09, at 10:53 AM, Alex Queiroz wrote:
Hallo,
On 4/15/09, Bradley Lucier lucier@math.purdue.edu wrote:
At one point my implementations of SRFI 13 and 14 used the internal Gambit API to properly check the types and bounds of arguments and raise exceptions with the proper continuations. That API has changed since I wrote those, but there are only a few macros and types that have to be rewritten to bring it up to date, but I don't have time to do so now.
It built flawlessly with 4.4.2, but then it may give unpleasant
surprises at runtime. I'll try to spot the needed changes.
Also, I use a very naive bitmap implementation for character sets, which is OK for Latin-1 but not for Unicode, so a different data structure should be used for that. Haven't done that, either.
Hmmm. this is more serious since I tend to use UTF-8 encoding.
Are you talking about the Unicode character class tables? If I'm not mistaken Will Clinger wrote a fairly compact and fast implementation of those tables. The code must be in Larceny somewhere. I believe it is also part of the reference implementation for R6RS.
Marc
On Wed, 2009-04-15 at 11:08 -0400, Marc Feeley wrote:
Are you talking about the Unicode character class tables? If I'm not mistaken Will Clinger wrote a fairly compact and fast implementation of those tables. The code must be in Larceny somewhere. I believe it is also part of the reference implementation for R6RS.
I'm just talking about manipulating general subsets of $0,...,2^{21}-1$ (which is what charsets are in unicode) efficiently without throwing around bit-vectors of length 256 kB.
Perhaps Clinger's code does this, I don't know.
Brad