Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: "core C" |
| Date | 2015-07-01 15:04 +0000 |
| Organization | Freie Universitaet Berlin |
| Message-ID | <cvidruFl3plU1@mid.uni-berlin.de> (permalink) |
| References | <ind4patt3nos39qrqj92b5dlp014o68g3v@4ax.com> <f4001c33-3768-4c92-82c0-10825a331ea9@googlegroups.com> |
Rick C. Hodgin <rick.c.hodgin@gmail.com> 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.
> #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
> #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.
> #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).
> #12 Two new arbitrary size variable type are introduced: bi, bfp
> (bi=big integer, bfp=big floating point)
> #13 A new weakly typed variable type is introduced: var
> #14 The basic class is introduced.
> #15 The concept of edit-and-continue compilation is mandatory.
> #16 A new exception framework is introduced based on inquiries
> rather than errors. These allow the machine to suspend for
> edit-and-continue guidance when an "error" condition arises,
> which will now be called an "inquiry" condition.
> #17 Flow control blocks are introduced.
> #18 Adhoc functions are introduced.
> #19 The #marker is introduced (for named return destinations, as in:
> returnto markerName).
> #20 The cask is introduced allowing for arbitrary code injection,
> and calling protocols on logical tests to meta (true) and
> mefa (false), as well as message passing using mema.
> #21 A new self-documenting protocol is introduced, which allows
> the software to be documented in source code (similar to Java's).
> #22 A new metadata set of tags is made available on a line-by-line
> basis, or at the function / struct level. These explicitly
> tag source code lines to be of a particular type, making a new
> type of search and/or replace possible (such as /* md: a, b, c */).
> #23 All standard libraries are available and #include'd by default.
> They must be explicitly excluded if they are not needed.
> #24 All functions are linked to (1) a bare minimum for standard
> libraries, (2) all are included for developer code; unless
> otherwise directed by compiler/linker flags.
All this can't be done without an interpreter or a kind of VM,
in which the program is run. With this you're throwing every-
thing out of the window what has made C such a success. And
that is that you can do bare-metal programming at nearly the
fastest possible speed - for which C has been called, not
too far off the mark, a "portable assembler:. With an inter-
preter or a VM it's impossible to use it for writing opera-
ting systems or using it as the implementation language for
higher-level languages. So, what you propose here is a new
language with a C-like syntax, but without any of the funda-
mental benefits of C. And such languages are a dime for the
dozend.
And with such a language all these points about endianess,
numbers of bits in variables, pointer sizes become mostly
irrelevant. These aren't language properties but are deter-
minded by the hardware the program is running on. They all
become implementation details the author of the interpreter/
VM has to care about, but which the user of the language has
no reason to care (or even to know) about - the interpreter/
VM has to somehow map the variables of that language to the
real hardware (or it is impossible to implement it on any
hardware that doesn't exactly fits your model).
And when you start designing a new language then you really
should look a lot further than just reproducing the syntax
of C with a few new bits added while giving up all what makes
C the lingua franca of computing. There's, for example, no
discernable reason why you're so fixated on integer vari-
ables with sizes of 8 bits and multiples of that. In C there
is a reason: it's often the "natural" size of the underlying
hardware. But for something that runs in an interpreter/VM
this is rather unimportant. Since you wil have to check each
and every calculation with such variables for over- and
underflows anyway, why not start with a fresh appproach
(but not new, e.g. ADA does that since a long time) and
have variables with e.g. user-defined ranges? So, if the
problem requires it, I can define a variable that can only
hold values between, say, -17 and 541? Since you already
have thrown out the speed advantage of C the tiny bit of
extra checking this would require won't make any major dif-
ference. And it might help writing much more secure programs
since all the checking the user has to do himself in C (but
too often forgets) are done automatically.
On the other hand, if the user doesn't know in advance whar
range he's going to need, why not make the variables adapt
themselves to what's needed? You'll have to check each assign-
ment to a variable anyway, so if the new value does not fit
anymore into an int32_t why not transparently upgrade it into
an int64_t (or your 'bi' type)?
Anything this "Core C" as stated will have to do with C (except
some similarities in the syntax) will be that the interpreter/VM
will need to be written in C or C++. (or some other languange
that probably is itself implemented in C if you don't mind to
run your interpreter/VM in another interpreter/VM;-). But it
won't be of any real interest to anyone if it hasn't any fea-
tures that make it a lot better than C when it just runs a lot
slower and doesn't allow you to do most things C typically is
used for.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
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