Re: change to standard-char-p in SBCL 2.4.2

On 3/2/24 10:32, Matt Kaufmann wrote:
> Hi,
>
> In SBCL 2.4.2, standard-char-p no longer returns t on a standard
> character input.  Apparently it now returns that input, as defined in
> file src/code/target-char.lisp of the SBCL 2.4.2 source distribution.
> This behavior is of course Common Lisp compliant, since every value is
> a so-called generalized Boolean.  That said, our ACL2 development has
> assumed for more than 30 years that predicates return Booleans except
> when specified otherwise, like member (not looking here for an
> argument about whether that assumption was proper) -- and we've never
> seen that assumption violated by any Common Lisp implementation that
> can host ACL2 (currently 6 of them, including SBCL).  So, I'll ask:
>
> Might that change be reversed in the next SBCL release?
>
> Since the change wasn't mentioned in the "changes in sbcl-2.4.2
> relative to sbcl-2.4.1" emailed to the list, at least not mentioned
> explicitly, I'm hoping that the change was inadvertent.  Of course, if
> there are other such examples I'd be very interested to learn of them.
>
> Thanks,
> Matt


a long time ago ; before emacs had character.h most people decided that 
characters where assumed EQL. I don't know if this helps or not. this 
unicode is a terrible concept. it keeps changing. linux used to use a 
representation that was similiar to BSD compression. i don't have the 
code here though...


I do remember a consideration for modifier bits or character 
"attributes". I wonder if we could just use 4 octets in place of these 
character attributes. I don't know unicode but 4-bytes per char can be 
simple.

however I still feel as though base-char or character should be one of 
95 ASCII glyphs.


this is such a big deal my linux kernel has unicode translation and the 
fonts I use also have these enormous amounts of useless data; but what 
about 128?


i have some code dedicated to character-p being 128 printing characters.


your request is a good one in a murkey area - IMHO.

_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help