[9fans] speaking of kenc - Plan9

This is a discussion on [9fans] speaking of kenc - Plan9 ; are these c99 "features" from /sys/src/cmd/cc/c99 really features or are they "unwanted"? Not done (yet?): 11. _Complex, _Imaginary, _Bool 18. Notation for universal characters \uXXXX 26. _Bool, float _Complex, double _Complex, long double _Complex - erik...

+ Reply to Thread
Page 1 of 7 1 2 3 ... LastLast
Results 1 to 20 of 121

Thread: [9fans] speaking of kenc

  1. [9fans] speaking of kenc

    are these c99 "features" from /sys/src/cmd/cc/c99 really features
    or are they "unwanted"?

    Not done (yet?):
    11. _Complex, _Imaginary, _Bool
    18. Notation for universal characters \uXXXX
    26. _Bool, float _Complex, double _Complex, long double _Complex

    - erik

  2. Re: [9fans] speaking of kenc

    Those are all real C99 features :-).

    Whether anyone really thinks they're worth a damn is another question.

    On 4/26/07, erik quanstrom wrote:
    > are these c99 "features" from /sys/src/cmd/cc/c99 really features
    > or are they "unwanted"?
    >
    > Not done (yet?):
    > 11. _Complex, _Imaginary, _Bool
    > 18. Notation for universal characters \uXXXX
    > 26. _Bool, float _Complex, double _Complex, long double _Complex
    >
    > - erik
    >



    --
    - Passage Matthew 5:37:
    But let your communication be, Yea, yea; Nay, nay: for whatsoever
    is more than these cometh of evil.

  3. Re: [9fans] speaking of kenc

    On 4/26/07, erik quanstrom wrote:
    > are these c99 "features" from /sys/src/cmd/cc/c99 really features
    > or are they "unwanted"?
    >
    > 11. _Complex, _Imaginary, _Bool


    That'd be a question for the HPC people; ron, do you miss complex types in 9c?

    _Bool is a notational convenience, maybe helping document functions
    returning only pass/fail status, or for the isalpha(2) family of
    functions.

    > 18. Notation for universal characters \uXXXX


    For the characters in Plan 9's char set, it's unneeded; you can type
    the character in as many keystrokes (Alt, X, xxxx). For characters
    outside Unicode's BMP, it's not terribly helpful, since Plan 9 doesn't
    understand them at all.

    That said, these universal characters aren't hard to implement at all.
    Come semester's end and I'll submit a patch to add them to the lexer.

  4. Re: [9fans] speaking of kenc

    official C went downhill more than 20 years ago.

    fortunately you can still program in what i called "Safe-C"
    in some flippant paper.

    i was particulalry impressed with VS2005 which has
    wchar_t as a fundamental type which can't be assigned
    to anything.

    shoot me, i did a if(sizeof(wchar_t) == sizeof(Rune)) etc.

    it seems that subjective C is more popular than objective C.

    brucee

    On 4/27/07, David Leimbach wrote:
    > Those are all real C99 features :-).
    >
    > Whether anyone really thinks they're worth a damn is another question.
    >
    > On 4/26/07, erik quanstrom wrote:
    > > are these c99 "features" from /sys/src/cmd/cc/c99 really features
    > > or are they "unwanted"?
    > >
    > > Not done (yet?):
    > > 11. _Complex, _Imaginary, _Bool
    > > 18. Notation for universal characters \uXXXX
    > > 26. _Bool, float _Complex, double _Complex, long double _Complex
    > >
    > > - erik
    > >

    >
    >
    > --
    > - Passage Matthew 5:37:
    > But let your communication be, Yea, yea; Nay, nay: for whatsoever
    > is more than these cometh of evil.
    >


  5. Re: [9fans] speaking of kenc

    never understimate trigraphs for something that made it into a standard
    but nobody every uses. ever.

    brucee.

    On 4/27/07, Joel C. Salomon wrote:
    > On 4/26/07, erik quanstrom wrote:
    > > are these c99 "features" from /sys/src/cmd/cc/c99 really features
    > > or are they "unwanted"?
    > >
    > > 11. _Complex, _Imaginary, _Bool

    >
    > That'd be a question for the HPC people; ron, do you miss complex types in 9c?
    >
    > _Bool is a notational convenience, maybe helping document functions
    > returning only pass/fail status, or for the isalpha(2) family of
    > functions.
    >
    > > 18. Notation for universal characters \uXXXX

    >
    > For the characters in Plan 9's char set, it's unneeded; you can type
    > the character in as many keystrokes (Alt, X, xxxx). For characters
    > outside Unicode's BMP, it's not terribly helpful, since Plan 9 doesn't
    > understand them at all.
    >
    > That said, these universal characters aren't hard to implement at all.
    > Come semester's end and I'll submit a patch to add them to the lexer.
    >


  6. Re: [9fans] speaking of kenc

    > i was particulalry impressed with VS2005 which has
    > wchar_t as a fundamental type which can't be assigned
    > to anything.


    but you can probably assign '1234' to it; no need for L either, valid
    literal in c99. gosh, i sure hope there is a cMMIX in the works.


  7. Re: [9fans] speaking of kenc

    >_Bool is a notational convenience, maybe helping document functions
    >returning only pass/fail status, or for the isalpha(2) family of
    >functions.


    no, since its type is different from that produced by the logical
    and equality operators (eg, ! and ==) which are still int!
    it's a unsigned integer type with a limited range (0 or 1), a special
    conversion rule, and of course a peculiar name (not even _bool!).
    pointless tinkering.

  8. Re: [9fans] speaking of kenc

    >_Bool is a notational convenience, maybe helping document functions
    >returning only pass/fail status, or for the isalpha(2) family of
    >functions.


    oh: and isalpha etc are defined to return int, as are all the other
    (conventionally) boolean operations and functions of the standard,
    although perhaps i overlooked some.

    as a convenience it's mainly a suitable target for micturating.

  9. Re: [9fans] speaking of kenc

    >
    > That said, these universal characters aren't hard to implement at all.
    > Come semester's end and I'll submit a patch to add them to the lexer.
    >


    i'm having trouble imagining under what circumstances this could be useful.
    can you help me out?

    i have yet to see \uxxxx in any code that wasn't part of the c99 spec.

    - erik

  10. Re: [9fans] speaking of kenc

    On 4/27/07, Charles Forsyth wrote:
    > >_Bool is a notational convenience, maybe helping document functions
    > >returning only pass/fail status, or for the isalpha(2) family of
    > >functions.

    >
    > no, since its type is different from that produced by the logical
    > and equality operators (eg, ! and ==) which are still int!
    > it's a unsigned integer type with a limited range (0 or 1), a special
    > conversion rule, and of course a peculiar name (not even _bool!).
    > pointless tinkering.
    >

    Since we're complaining about stuff being standardized to death...
    consider the entire tgmath.h header which actually can't be
    implemented in legal C99... yet is a part of C99. That one's a real
    twister...

  11. Re: [9fans] speaking of kenc

    On 4/27/07, erik quanstrom wrote:
    > > That said, these universal characters aren't hard to implement at all.

    >
    > i'm having trouble imagining under what circumstances this could be useful.
    > can you help me out?


    They'd only be useful on systems that don't support Unicode in source
    files, the way digraphs and trigraphs are only useful if you have a
    broken keyboard without braces. But they're part of the spec, add
    maybe 20 lines of code, and don't slow anything down unless they're
    used. Maybe in the Unix port of kencc they'll be wanted.

    Besides, the handful of minor patches I've submitted have all been
    accepted; it's high time I try something that gets rejected. ☺

    --Joel

  12. Re: [9fans] speaking of kenc

    > They'd only be useful on systems that don't support Unicode in source
    > files, the way digraphs and trigraphs are only useful if you have a
    > broken keyboard without braces. But they're part of the spec, add
    > maybe 20 lines of code, and don't slow anything down unless they're
    > used. Maybe in the Unix port of kencc they'll be wanted.


    one problem. kenc runs on plan 9. plan 9 supports unicode.

    have you ever used a di/trigraph? reading one in the spec does not count.

    - erik


  13. Re: [9fans] speaking of kenc

    \u doesn't add anything useful to the plan 9 c compiler because of the
    way its input language is defined. it is useful in c99, because of the
    way its input language is defined.

    in plan 9, each escape sequence in a string constant represents a
    unicode code point. "\x1234" represents a string with a single
    character with value 0x1234. but in c99, that is an erroneous
    string because each escape sequence represents a byte. thus
    to represent a unicode value, one is expected to write out the
    utf-8 byte sequence. plan 9's "\x1234" becomes, in c99,
    "\xe1\x88\xb4". the \u escapes were created to give plan 9's
    functionality without breaking compatibility with the existing
    implicit meaning of the \x escapes.

    this subject is quite long and involved - where does utf-8 fit in?
    how does source encoding interact with internal representation?
    output encoding? etc. etc. - but the key point about \u is that
    it makes sense in a utf-8 world with standard c and c++.

    plan 9's c is very non-standard in this regard. i prefer its design
    but i don't find \u to be a bad solution. there are a number of
    related notations in the standards pipeline to deal with some of
    the other issues, such as forcing utf-8 byte sequences. the
    notation is going to get pretty ugly.

    -rob

  14. Re: [9fans] speaking of kenc

    > > Maybe in the Unix port of kencc they'll be wanted.
    >
    > one problem. kenc runs on plan 9. plan 9 supports unicode.


    http://code.google.com/soc/p9/appinf...263BFBBBDEAE1B

    --Joel

  15. Re: [9fans] speaking of kenc

    > http://code.google.com/soc/p9/appinf...263BFBBBDEAE1B

    i should have said "utf-8", not unicode. in any event, i've used
    utf-8 with sam on solaris, irix, aix and linux since 1991 or 1992.

    which is to say, there's nothing about unix per se that has ever
    prevented utf-8.

    one might need to mangle names for the system linker. i haven't
    tried.

    - erik

  16. Re: [9fans] speaking of kenc

    >> > Maybe in the Unix port of kencc they'll be wanted.
    >>
    >> one problem. kenc runs on plan 9. plan 9 supports unicode.

    >
    > http://code.google.com/soc/p9/appinf...263BFBBBDEAE1B


    the compilers already run on unix (and windows) and because their input
    language handles utf-8 values and escapes in strings, the c99 construction has
    not been needed (or i'd have added it). it might be needed for some unix programs
    (but there are so many other things those expect that it's probably the least of your
    worries)


  17. Re: [9fans] speaking of kenc

    > >_Bool is a notational convenience, maybe helping document functions
    > >returning only pass/fail status, or for the isalpha(2) family of
    > >functions.

    Charles Forsyth wrote:
    > no, since its type is different from that produced by the logical
    > and equality operators (eg, ! and ==) which are still int!
    > it's a unsigned integer type with a limited range (0 or 1), a special
    > conversion rule, and of course a peculiar name (not even _bool!).
    > pointless tinkering.


    Actually we expect that _Bool will be used only via the typedef
    "bool" in . The reason for the spelling was to use
    an identifier that was within the namespace already reserved
    for C implementors, so as not to impact any existing code.
    Similarly for the complex type(s).

    Note also that _Imaginary is not required by C99. There was
    considerable debate about the utility (or not) of a purely
    imaginary type, in the end deciding that there was insufficient
    utility to require it.

    There are reasons behind all of the C standards committee's
    decisions. Often they reflect practical constraints such as
    wanting not to conflict with existing strictly-conforming code.

    If VS2005's wchar_t is truly not assignable then it doesn't
    conform to the C standard.

  18. Re: [9fans] speaking of kenc

    David Leimbach wrote:
    > Since we're complaining about stuff being standardized to death...
    > consider the entire tgmath.h header which actually can't be
    > implemented in legal C99... yet is a part of C99. That one's a real
    > twister...


    There have always been some library features that are not
    implementable within the language itself. The real complaint
    about should be that it mandates some mechanism
    that the implementation can exploit, but that mechanism is
    not made available to the general programmer.

    I will agree that is of dubious design and utility.

    If you guys really care about this stuff, you should participate
    in the process, rather than sit on the sidelines and carp about
    what others have done.

  19. Re: [9fans] speaking of kenc

    On 4/26/07, Joel C. Salomon wrote:

    > That'd be a question for the HPC people; ron, do you miss complex types in 9c?


    No, but you're not going to like the reason. AFAIK nobody misses it,
    because there may not be a single HPC app in widespread use that could
    be run on Plan 9 today. We've been looking. Roman knows more than I do
    on this issue.

    But the apps I've found to date need Fortran, Python, C++, and,
    occasionally C; and, on top of that, need a library or two. Oh, and
    did I mention, OpenMP, and of course you need an MPI.

    This one is instructive:
    http://www.llnl.gov/asc/computing_re...readme.bm.html

    Hence my concerns re Python, but that one is on the way to being solved.

    We're trying to work this one :-)

    ron

  20. Re: [9fans] speaking of kenc

    This discussion made me curious whether good high-level languages are being developed for scientific computing.

+ Reply to Thread
Page 1 of 7 1 2 3 ... LastLast