Re: [Pika-dev] new code: character special names

[Tom Lord]

    > From: "Jose A. Ortega Ruiz" <address@hidden>
    > Date: Sun, 04 Jan 2004 01:16:49 +0100

    > happy new year!

Likewise.   My apologies for the delay I'm working on how to balance
work on arch with work on Pika and am off to a rocky start, it seems.

    > i've spent some time of my holidays writing a little bit of code for
    > pika. more concretely (and following tom's suggestion), i've extended
    > the special character names handled by read and write: all usual names
    > (newline, return, page, etc.) plus standard ASCII names are included
    > (in fact, the same set as systas').

    > i've also spent sometime with tla 1.2 and i've created a new _signed_[1]
    > archive with the following coordinates:

This looks well done.

    > - - i've tried to hide away all details of char representation and name
    >   handling inside reps/char-imp.c (for instance, avoiding explicit bit
    >   twiddling in lexer.c, and things like that.)

I've moved the the codepoint and buckybit conversions to and from
strings to libscm/chars.c.  Those should be stable even under changes
to object representations and GC strategies.  Pika is Unicode centric
and makes up (drawing on emacs) its own standard for buckybits.


    > - - i've noticed that pointer arguments are seldom checked for
    >   non-nullness: i've used now and then invariant(arg != 0) in my new
    >   functions, but maybe not checking is a design issue?

Because of the calling conventions being used, unless an argument
parameter is not optional, it should not ever be null.   Invariants
aren't going to hurt there.

Perhaps return parameters should be permitted to be null -- I hadn't
considered it.


    > - - i've also missed the (consistent) use of 'const' qualifiers for
    >   pointer parameters of functions (what the c++ people call
    >   const-correctness). from my previous experience, a rigorous use of
    >   'const' improves the code's consistency and 'self-documentedness'.
    >   i've already used it in my pika hacks, but of course it must be a
    >   shared policy to be of any use. if you think it's worth the effort,
    >   i volunteer to review the current pika source tree to make it
    >   'const-correct'. but, again, maybe i am missing some design issue...


That's more just my bigotry and old-fasionedness than anything.   I
tend to just avoid const always because in my experience it hurts more
than helps.   However, I've left in your decls for now because I'm not
sure I'm not being just silly about that.

    > - - tom, i think my changes are quite self-explanatory, but if you want
    >   me to explain them in more detail to save you time, just ask! :).
    >   also, please let me know if the archive change poses any problem
    >   (the old one is still alive, btw).

It's all just fine.  I'm pushing the merge now.

-t