Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #141110
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: list of chars to introduce in future c |
| Date | 2019-02-16 01:25 -0600 |
| Organization | albasani.net |
| Message-ID | <q48dss$1tv$1@news.albasani.net> (permalink) |
| References | (5 earlier) <q43ggi$enl$1@dont-email.me> <q44hah$nc0$1@news.albasani.net> <q44jg8$2vl$1@dont-email.me> <q45n9f$ah4$1@news.albasani.net> <GOJ9E.1238186$Fi6.1102052@fx12.am4> |
On 2/15/2019 7:36 PM, Bart wrote:
> On 15/02/2019 06:47, BGB wrote:
>
>> The same compiler also now does a version of my BS2 language, which in
>> some ways sounds like "the worst of both worlds" (in many ways, it
>> goes pretty much exactly the opposite direction of most current
>> "trendy" languages).
>>
>> For BS2, its syntax is sorta like the lovechild of C, Java, and AS3.
>> Semantics also borrow a fair bit from C# and C++, and is statically
>> typed, does not use garbage collection, can still make use of raw
>> pointers, ...
>>
>> But, I am not designing this language to try to appeal to popular
>> sensibilities (nor aims to replace existing languages).
>
> I've recently started on a new language, but it is nothing
> earth-shattering, and is certainly not trendy. (Such languages I tend to
> ignore; mine tend to be much more practical, to design, implement and use.)
>
Yeah. A few years ago, people were obsessing over Go, now it is Rust.
Most of what I do is still C, and I don't really expect this to change
much in the near future.
> It is also a hybrid, somewhere between my static language and my dynamic
> language. The latter is great to code in, but is interpreted so that
> programs will be slow. (I was doing some image processing stuff with it,
> and I didn't like that you sometimes had to wait for things to finish.)
>
> Too early to say how it will pan out. The idea is that it will replace
> both of the current languages. (I tried this experiment a few years ago,
> but my compilers of the time were not deft enough to do instant
> whole-program or run-from-source compilation.)
>
> At best, it will give both C and C++ a run for their money. (The current
> static one only does that for C.)
>
I am not trying to replace C, FWIW.
However, it is not always the best possible language either.
BS2 is pretty much on the statically-typed side of things, with a
similar type-system to other C-family languages (ex: C, C++, Java, and
C#), I would probably also classify it as C-family.
It has some limited dynamic-typing capabilities, but these still exist
within the context of an overarching static typesystem. They are mostly
intended for edge-cases, as they will come with a performance penalty.
Rough list of types:
Integer
char, cchar (char is 16-bit, like Java; whereas cchar is 8-bit).
byte, sbyte (bytes are given their own types)
short, ushort
int, uint
long, ulong
int128, uint128 (secondary)
bool
Floating Point
float
double
hfloat (16-bit half-float)
bfloat (16-bit, truncated float)
float128 (secondary)
Reference Types
object
variant (dynamic)
string
...
Others
auto (type-inferred)
enum (decays to an integer type)
cstring (basically a C-style string, alias for '*cchar').
...
Object
class (like in Java)
interface (like in Java)
struct
Behaves roughly like in C#
Limited to "POD classes" in the C++ sense.
union (like in C, similar restrictions to 'struct')
dynamic class
...
'object' and 'variant' are similar in that both are tagged reference
types, but differ in how they behave:
object is "opaque" but can be cast to/from other types;
variant will try to figure out what to do at runtime.
Various operations can be applied, with dynamic results.
Dynamic subtypes of 'variant':
fixnum (62 bit long);
flonum (62 bit double);
object instances and array references;
strings, symbols, keywords, ...
'auto' behaves roughly like 'auto' in C++.
'enum' differs from C in that, rather than always decaying to 'int', it
may also decay to a smaller type (such as byte or short).
Pointer/Array:
*int foo1; //pointer, '*' is attached to the type.
int *foo2; //pointer, '*' is attached to the declarator.
int[] bar; //array ref
int[256] arr1; //array, size assigned to type.
int arr2[256]; //array, size assigned to declarator.
Sized arrays can decay to either array-refs or pointers. An array ref
will generally be bounds-checked, and a pointer will not (pointers
basically behave the same as in C; supporting pointer arithmetic and
other fun, ...). Array-refs can exhibit many similar behaviors to
pointers in C, though the underlying mechanism differs (and they still
preserve bounds checking behavior).
In terms of use, foo1 and foo2 are functionally equivalent in this case,
but '*' placement may become relevant in more complex declarations.
'arr1' and 'arr2' are fairly similar, but differ in semantics. 'arr1'
will nominally decay to 'int[]' whereas 'arr2' will nominally decay to
'*int'. Both are explicitly sized arrays which will reserve storage at
their point of declaration, with a lifetime tied to the scope of their
declaration.
It is also possible to create arrays via 'new', "arr=new int[128];", or
inline, "arr=[1,2,3,4,5,6,7,8]SI;".
Structs:
Have a defined memory layout (like in C).
Are pass-by-value by default (like in C).
Don't support inheritance;
Don't support virtual methods or overloading;
Don't support interfaces.
Class:
Exact memory layout depends on the implementation;
Pass-by-reference by default;
Support inheritance, virtual methods, interfaces, ...;
...
Dynamic classes are a subtype of class objects, which support fields
being added dynamically. Either the "obj.foo" or "obj[#foo]" syntax may
be used for accessing fields within dynamic objects.
A special case exists, known as an "ex-nihilo" object: "obj={x: 3, y:
4};", which is fully dynamic and lacks a parent class.
For other dynamic objects (from a base-class), the creation syntax is
"obj={x: 3, y: 4}:Foo();", with the base class still requiring the
'dynamic' modifier. Note that "obj=new Foo();" also works for dynamic
objects, though will not create any dynamic fields.
By default, any objects created this way will still require 'delete',
however, objects created with "new!" will have automatic storage
duration instead (and thus 'delete' would not be used), though 'new!' is
one-off (and thus may not be used in a loop).
Implicitly:
"Foo! obj();"
is functionally equivalent to:
"Foo obj=new! Foo();"
There are also regions:
"Foo obj=new(someRegion) Foo();"
Which assigns the lifetime of the object to a region (rather than it
being part of the global heap).
When a region is destroyed (or cleared), any contained objects are
implicitly deleted. Similarly, it is possible to "mark" or "clear to
mark" within a region (where "clear to mark" would delete anything
created after the mark was created; sort of like Quake's 'Hunk' allocation).
There are also closures, with several sub-versions. The normal version
(heap allocated, dynamic lifetime; still needs 'delete') captures bound
variables by value, and can be represented via a function pointer (the
closure pointer points to an executable stub-function).
Ex:
"fptr=function():int {x+1};" //heap storage
"fptr=function!():int {x+2};" //automatic storage
"fptr=new(someRgn) function():int {x+3};" //region storage
Though, the current (new) implementation isn't entirely complete on
these fronts.
...
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 03:16 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 04:56 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 05:16 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-13 15:43 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 09:55 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 11:05 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-13 20:29 +0100
Re: list of chars to introduce in future c "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-13 20:33 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 12:08 -0800
Re: list of chars to introduce in future c John Bode <jfbode1029@gmail.com> - 2019-02-13 12:02 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 12:16 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 09:34 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:04 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:08 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 11:28 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:38 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 14:54 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 06:39 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 16:26 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:49 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:59 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 03:10 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 03:34 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 05:25 -0800
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 13:54 +0000
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:07 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:10 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:14 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:18 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:22 -0800
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 14:24 +0000
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:32 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:39 -0800
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 14:47 +0000
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 07:32 -0800
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 15:56 +0000
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 08:18 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 17:10 +0100
Re: list of chars to introduce in future c Keith Thompson <kst-u@mib.org> - 2019-02-14 12:20 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 21:32 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 13:52 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:31 -0800
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-13 12:48 -0600
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 09:45 +0100
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-14 04:06 -0600
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 11:39 +0100
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-14 14:34 +0000
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 16:31 +0100
Re: list of chars to introduce in future c Robert Wessel <robertwessel2@yahoo.com> - 2019-02-14 14:39 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-14 23:48 +0000
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 09:20 +0100
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 11:09 +0000
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 17:25 +0100
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 16:46 +0000
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 18:05 +0100
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-17 14:45 -0600
Re: list of chars to introduce in future c James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-15 10:51 -0800
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-14 13:59 -0600
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 21:36 +0100
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-15 00:47 -0600
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 09:26 +0100
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-15 14:15 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-16 01:36 +0000
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-16 01:25 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-16 12:17 +0000
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-16 15:08 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-16 23:10 +0000
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-17 00:56 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-17 17:30 +0000
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-17 16:02 -0600
Re: list of chars to introduce in future c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 13:49 +0000
Re: list of chars to introduce in future c Philipp Klaus Krause <pkk@spth.de> - 2019-02-14 09:08 +0100
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 09:56 +0100
Re: list of chars to introduce in future c Philipp Klaus Krause <pkk@spth.de> - 2019-02-14 11:06 +0100
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 15:01 +0100
Re: list of chars to introduce in future c mark.bluemel@gmail.com - 2019-02-15 05:30 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 05:42 -0800
Re: list of chars to introduce in future c Lynn McGuire <lynnmcguire5@gmail.com> - 2019-02-15 18:19 -0600
csiph-web