Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: "core C" |
| Date | 2015-06-30 13:02 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <mmu0dc$f67$1@dont-email.me> (permalink) |
| References | <ind4patt3nos39qrqj92b5dlp014o68g3v@4ax.com> <f4001c33-3768-4c92-82c0-10825a331ea9@googlegroups.com> |
On 30/06/2015 12:27, Rick C. Hodgin wrote: > We can define Core C here if you'd like. :-) I appoint myself chair, > and the rest of us a "committee of the whole" to address the issue. > > #1 Little endian. > #2 Two's complement. > #3 All pointers are the same size per target. > #4 All memory is executable. No way of turning it into non-executable? A bit dangerous. > #5 All memory is read/write unless explicitly flagged as read-only. > #6 No default support for char, short, int, long, long long, etc., > but these keywords are reserved for use with typedef or #define > statements to map to the appropriate target for the machine. > #7 Signed variable types: s8, s16, s32, s64 > #8 Unsigned variable types: u8, u16, u32, u64 No 'char' type? > #9 Floating point types all IEEE 754-2008 compliant: f32, f64 > #10 A new "flag" variable type is introduced which is 1-bit, > assigned with yes/true/up and no/false/down keywords. I bet it won't be 1-bit! How much storage will an array of 1000 flags take up? Anything smaller than 1000 bytes means you have to deal with bits and bit-pointers, which might compromise #3, making all pointers the same size. > #11 A new "bits" variable is introduce which is n-bits, where: > 1 <= n <= 7. Defined as "bits:2" for a 2-bit width, range- > checked on use with inquiries being thrown (see #16 below). Anywhere, or just inside structs or as array elements? But the same objection as before. What about bits:12 and bits:20 (which tidily fit into a 32-bit type)? What is the range of bits:2? Is it 0 to 3, or can be it anything (-2 to +1 for example)? Will bits:N ever cross a byte-boundary? (In which case, you might want bits:8 starting halfway through a byte.) Range-checking on assignment is going to slow down any operations, as presumably this encompasses all possible overflows on arithmetic as well as when assigning to and from a bits:N from a different type. How many bytes and/or bits will a [5] array of bits:7 take up? Just saying bit types and bitfields take a lot of support. > #12 Two new arbitrary size variable type are introduced: bi, bfp > (bi=big integer, bfp=big floating point) Not exactly part of a core language. You would expect a core language to implement features like this. > #13 A new weakly typed variable type is introduced: var And this is completely misplaced. I assume this would be dynamically typed? Then it would make nonsense of whatever type system you're trying to impose. Example, in A=&B; you would expect that if B is of type T, then A ought to be of type T*. But both could of of 'var' type with nothing amiss; anything goes. And you need to make a distinction between the static 'var' type of something, and the dynamic type it contains. Would a var* type be allowed? Would var types be passed by value or by reference? Etc. Another can of worms inappropriate in a 'core' language. > #15 The concept of edit-and-continue compilation is mandatory. And this is where you're going to lose everyone who's made it this far. This is nothing to do with languages or compilers as they are normally understood. -- Bartc
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
"core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 08:38 +0200
Re: "core C" jt@toerring.de (Jens Thoms Toerring) - 2015-06-30 07:54 +0000
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 02:55 -0700
Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 17:31 +0200
Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 18:15 +0200
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 12:19 -0700
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:27 -0700
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:48 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:07 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 05:15 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:02 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 05:13 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:58 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:11 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 15:11 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:50 -0700
Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 17:24 +0200
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 17:44 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 10:04 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-07-01 11:46 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 04:40 -0700
Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 08:05 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-07-01 17:01 +0100
Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 10:56 -0700
Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 12:59 -0500
Re: "core C" Bartc <bc@freeuk.com> - 2015-07-04 20:25 +0100
Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 20:56 -0500
Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:17 +0100
Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:03 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:16 -0700
Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-06-30 15:46 +0200
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:54 -0700
Re: "core C" Steve Thompson <stevet810@gmail.com> - 2015-07-03 12:25 +0000
Re: "core C" jt@toerring.de (Jens Thoms Toerring) - 2015-07-01 15:04 +0000
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 08:12 -0700
Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 10:36 -0500
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:41 -0700
Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:19 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:25 -0700
Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 15:48 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:52 -0700
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:42 -0700
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 08:28 -0700
Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-06-30 22:28 +0200
Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 08:45 +1200
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 13:56 -0700
Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-07-01 10:27 +0200
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 14:56 -0700
Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 10:03 +1200
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 15:31 -0700
Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 10:52 +1200
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 16:58 -0700
Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-06-30 17:30 -0700
Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-07-01 08:54 +0200
Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 07:54 -0700
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-01 09:42 -0700
csiph-web