Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: "core C" |
| Date | 2015-06-30 22:28 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <mmuu28$jdf$1@dont-email.me> (permalink) |
| References | <ind4patt3nos39qrqj92b5dlp014o68g3v@4ax.com> <f3e0a42e-7df6-4f86-b3f6-e275dd8e8774@googlegroups.com> |
On 30/06/15 17:28, Rick C. Hodgin wrote:
> On Tuesday, June 30, 2015 at 9:47:07 AM UTC-4, David Brown wrote:
>> On 30/06/15 13:27, Rick C. Hodgin wrote:
>>> #1 Little endian.
>>
>> There are far too many big endian systems around for this to be defined
>> as "core". I'd be happy to say it should support big endian and little
>> endian systems, but not mixed endian systems.
>
> Alright. Both are allowed. Little endian will be the default.
>
No, that makes no sense. You can't have them both supported yet one of
them is the default.
>> More usefully, I would like to see type/variable qualifiers for
>> specifying endianness, which would eliminate all issues that different
>> endianness causes today (e.g., when specifying a binary file format, you
>> would explicitly give the endianness of the fields).
>
> I do like this. Added. What should the syntax be? I have been fond
> of adding "dot tags" to things, so s32.le for little endian, and
> s32.be for big endian. They also allow additional tags, such as
> read-only being s32.le.ro. And of course these can be typedef'd
> or #define'd.
I would suggest, as I said, using a qualifier - grammatically similar to
"const" or "volatile". You would have qualifiers _Big_endian, and
_Little_endian, using the style now common for new C keywords.
I could see uses of other qualifiers too, such as _Saturated and
_Wrapped to affect how integer types perform arithmetic.
qualifiers, as I see it (without having thought everything through in
depth), would let you make these specialised types when you need them,
without having to have a proliferation of different types. And they can
be applied to types, variables, structs, arrays, etc. You could not do
that with "dot tags". I also think this sort of thing should have long,
clear names - you would only use them rarely, so clear and explicit
names are far better than minimal abbreviations.
>
>> The bit-endianness (order of bitfields) would also need to be
>> specified.
>
> Yes.
>
>>> #2 Two's complement.
>> I'm OK with that.
>>
>>> #3 All pointers are the same size per target.
>> I don't see the point of this restriction, and it would cause
>> limitation on real-world microcontrollers.
>
> No limitations. They will be included in extension allowances to
> Core C. But, they are not part of Core C.
Extensions to a language specification can make additional restrictions
(such as the way POSIX restricts the C standard's flexibility on
CHAR_BIT by insisting that it is 8). They can also allow flexibility
and expansion capability of the base standard to be made concrete - such
as the C standards allowing extended integer types, and gcc implementing
an _int128_t type.
But you can't base your language around a "core" and then have
extensions break those rules. They can add to the rules, but not break
them. You cannot have a base or "core" that says all pointers are the
same size, and then say that in /this/ extension those rules don't hold.
It would be completely ass-backward.
If you don't want to allow pointers of different sizes (you have yet to
come up with a convincing argument for this, but I realise that you are
adamant that it is important), then don't allow them. I and many others
would disagree on this rule, but it's /your/ "core C".
>
>>> #4 All memory is executable.
>>
>> Nope - that's a terrible idea. C does not currently distinguish between
>> types of memory (code, data, bss and stack sections are all
>> implementation details, not part of the standards). But if you want to
>> make memory areas part of "Core C", then you definitely want
>> restrictions on executable parts.
>>
>> And for many real-world microcontrollers, only some of the memory can be
>> executable. If "Core C" is to have a point, it must be suitable for a
>> range of "normal" systems, even if it excludes odd or outdated systems.
>
> Only some memory on any system can be executable. However, in the
> Core C virtual machine, all memory will be executable. And by
> default, the Core C language would allow branching to any address.
> It would be up to the OS to catch the error and shutdown the app.
That only makes sense in a sandbox in a VM - not in the real world, and
not on many systems (most microcontroller systems don't even have an OS).
Are you trying to reinvent Java, or are you trying to make a better C?
>
>>> #5 All memory is read/write unless explicitly flagged as read-only.
>>
>> Again, that's a terrible idea. And it would not work on
>> microcontrollers, which have read-only memory regardless of
>> what the user might try to do with flagging.
>
> I disagree. Memory can be flagged as read-only. We can add a
> block like:
>
> readonly {
> // Everything defined in here is in read-only memory
> };
>
C already has a way to do this - it's called "const". What are you
trying to do here that is different?
> I don't anticipate this language being used for microcontrollers,
> by the way. I anticipate it being used by people on desktop
> machines, mobile devices, and other personal devices.
I believe a substantial proportion, perhaps more than 50%, of all C code
written today is for microcontrollers rather than PC's. On the desktop
and PC world, there are many languages in use for different purposes,
and C is very much a minority choice for special cases such as low-level
code, OS code, and libraries where speed is a high priority. On
microcontrollers, C dominates (though C++ use is increasing).
Trying to move forward with C but ignoring microcontrollers is almost
entirely pointless.
>
>>> #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.
>>
>> That's going to upset a lot of people...
>
> I've had the idea of including a #pragma or compiler switch which,
> for each version of Core C, wraps those values to their appropriate
> values on tha version. But, by default we need to move away from
> those generic concepts and get into specifics.
The language specs should not be concerned with compiler switches, and
#pragmas are only suitable for odd implementation-specific settings.
They should not be part of the language itself.
>
>>> #7 Signed variable types: s8, s16, s32, s64
>> No, these are called int8_t, int16_t, int32_t and int64_t. Don't change
>> these to non-standard names that could easily be mixed up, just to save
>> a couple of keystrokes.
>
> Disagree. Both the name int8_t and uint8_t are silly. It can
> be shortened, and I'm writing a language for the future, not
> the past.
Those names were picked for good reason, based on what was in use at the
time. Those reasons have not changed.
I have worked with code that uses a variety of different size-specific
types, with histories dating back to the pre-C99 days. It may be a
matter of taste, but I am much happier with int8_t style. (Things like
int_fast8_t get a bit tedious, however - I am open to better ideas
there. But since we are guaranteed that 8-bit data types exist, and the
compiler can optimise local variables in many ways, types like
int_fast8_t are not really needed - just use int8_t and let the compiler
implement it with a 32-bit int if that is faster.)
The original C language had various short forms (such as implicit int),
which are widely believed to be a way to save K & R typing more than
necessarily on their unpleasant DEC keyboards. There is no such
necessity now - you can pick names that make sense.
>
>>> #8 Unsigned variable types: u8, u16, u32, u64
>> Again, these are uint8_t, uint16_t, uint32_t and uint64_t.
>
> Ibid.
>
>> Note that some systems (in particular, some DSP's) have minimum 16-bit
>> or 32-bit accesses. I'm okay with these not being fully compatible with
>> "Core C", but you need to be aware of them.
>>
>>> #9 Floating point types all IEEE 754-2008 compliant: f32, f64
>> That would be float32_t and float64_t.
>
> Ibid.
>
>>> #10 A new "flag" variable type is introduced which is 1-bit,
>>> assigned with yes/true/up and no/false/down keywords.
>>
>> That would be "bool", with "true" and "false" values. It would be fine
>> to make those keywords (just like in C++), and save #include'ing <stdbool.h>
>
> bool is 1-byte as I understand it. flag variables are bits, packed
> into scoped local or global space.
The only valid values for bool are true and false. If C had a way to
address single bits (some systems do), then it would be sufficient to
use a single bit for a bool.
But if you want something that is always 1 bit, and that the compiler
should pack (despite the inefficiencies that may entail), why not call
it "bit" ? That would be in addition to the logical "bool" type.
>
>>> #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).
>> That is not in the spirit of C - and certainly not in a "Core C".
>
> I've redefined it in subsequent messages. It's now bN, such as b17.
> And you can specify a type tob e b17:s32, which means treat the
> value in those 17 bits as an s32 for calculations. It will also
> allow for simple signed and unsigned values using b17:s, b17:u.
>
That's just too unpleasant for words.
>>> #12 Two new arbitrary size variable type are introduced: bi, bfp
>>> (bi=big integer, bfp=big floating point)
>> That is not in the spirit of C - and certainly not in a "Core C".
>
> It is part of Core C.
>
>>> #13 A new weakly typed variable type is introduced: var
>> That is not in the spirit of C - and certainly not in a "Core C".
>
> It is part of Core C.
>
>>> #14 The basic class is introduced.
>> That is not in the spirit of C - and certainly not in a "Core C".
>
> It is part of Core C.
>
>> If you want to invent a language that is half-way towards C++, and call
>> it "Core C+", that's fine - but it's a different language.
>
> C needs the class. It is a minor addition with major scope. We
> already have everything we need provided for in structs. It just
> allows encapsulation and the nicer syntax usage.
>
> It is part of Core C.
C does not /need/ classes, or any of the stuff here. Remember, this is
just a thought experiment - not reality.
There certainly are advantages in adding classes to C - that is why C++
was created. Of course one does not need to go as far as C++, but you
very quickly move out of C philosophy - hence the suggested Core C+.
>
>>> #15 The concept of edit-and-continue compilation is mandatory.
>> That has no place in a language. Even though you like
>> edit-and-continue, you must surely see that!
>
> Disagree completely. And you even said previously that you could
> see how it could have some use.
I said I could see how it could have some use in an IDE and development
tools - not that it should be involved in the language itself in any
way. There is a /huge/ difference.
> For others it has exceeding use.
> Apple even thought it had enough to add it to versions of GCC,
> calling it "fix-and-continue." It's not a trivial thing. It's
> major. And...
It's a trivial thing as far as the language is concerned - there is
nothing involved.
It is also a trivial thing as far as the compiler is concerned, and I
believe has been implemented in several tools. All that is needed is a
couple of nop's at the start of the function, where the debugger can
insert a jump to the patched code. That is it, basically.
Making it work well with the debugger and IDE is another matter. /That/
is hard. But it is not a language issue in any shape or form.
>
> It's part of Core C.
It would never be part of anything anyone else would consider to be
"Core C", or a "next generation C" or a replacement for C.
>
>>> #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.
>> That is not in the spirit of C - and certainly not in a "Core C".
>
> It is part of Core C.
It would never be part of anything anyone else would consider to be
"Core C", or a "next generation C" or a replacement for C.
>
>>> #17 Flow control blocks are introduced.
>> C already has plenty of flow control keywords - it doesn't need any more.
>
> It is part of Core C.
What flow control blocks do you mean here? I assumed you were talking
about "iterate", "until", "unless", etc., that you discussed earlier -
and which I showed are easily implemented by simple macros in today's C.
>
>>> #18 Adhoc functions are introduced.
>>
>> I'd be fine with local nested functions - but call them local functions
>> or nested functions, since that is what they are. "Adhoc" means
>> something completely different from the way you use it (look the word up
>> in a dictionary).
>
> Adhocs relate to casks, which are now part of Core C. As such,
> adhocs are part of Core C.
Casks would never be part of anything anyone else would consider to be
"Core C", or a "next generation C" or a replacement for C, and thus the
same applies to other features that go with them.
On the other hand, local nested functions are often useful ideas (so
useful that C++ has them now, called lambdas, and many other programming
languages have always supported them), and could be added to C if it
were done carefully.
>
>>> #19 The #marker is introduced (for named return destinations, as in:
>>> returnto markerName).
>> Nope.
>
> It is part of Core C.
Great, a new way to do spaghetti programming. Just what we need.
If you feel that something like this has any use, read about generators
and coroutines for better methods.
>
>>> #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.
>> Nope.
>
> It is part of Core C.
>
>> "casks" have no place in C of any sort, "core" or otherwise. They may
>> be part of RDC, but that's because RDC is a different sort of language.
>
> It is part of Core C.
See above.
If you insist on things like this as "Core C", rather than RDC, then you
will lose any hope of support from other people. Many of your ideas
here are interesting and could conceivably form suggestions for changes
to the C standards or enhancements and extensions in real compilers.
But this cask nonsense is for you alone.
(I'm not going to bother commenting any further, as your later ideas and
replies just get sillier and more Rick-centric.)
>
>>> #21 A new self-documenting protocol is introduced, which allows
>>> the software to be documented in source code (similar to Java's).
>> doxygen already exists, and is very popular. You can't mandate
>> documentation as part of a programming language.
>
> Mandated in Core C. We are looking to the future, not the past.
> I may even use the doxygen code then as an import into Core C, but
> it will be an explicitly defined and integral part.
>
>>> #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 */).
>>
>> That makes almost no sense at all - and if it is nothing more than an
>> attempt to standardise comments, then forget it. Comments are entirely
>> at the discretion of the programmer - that's the nature of comments.
>
> It will be parsed and known by the compiler, debugger, and the IDE.
> It will provide utility which today has no specific form other than
> text-based searches. Adding metadata abilities means sorting and
> finding things far more easily.
>
>>> #23 All standard libraries are available and #include'd by default.
>>> They must be explicitly excluded if they are not needed.
>> Nope, bad idea - polluting the namespace and making compilation far
>> slower and more complicated. I would have nothing against a bit of
>> restructuring, simplifying, and improving the standard library - but it
>> should not be included automatically.
>
> Disagree. I'll add a #pragma at the top which allows for some kind
> of "undefine all standard #includes" so it can be done away with,
> but I can't tell you how many hours over the years I've spent trying
> to figure out which #include file I needed for some function I was
> using. It's probably added up to a week or more over time.
>
> I would spare all future users from that. And the experienced ones
> will have no problems adding that one additional line to #undef
> everything so they can manually define them one-by-one.
>
>>> #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.
>> Terrible idea.
>
> Disagree. It is part of Core C. Compiler/linker flags will allow
> for other settings.
>
> Best regards,
> Rick C. Hodgin
>
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