Re: [dev] lsw 0.3
Anselm R Garbe said: > I will create a formal release tonight. Thanks! -- Dmitrij D. Czarkoff
Re: [dev] K, a low-level procedural imperative programming language
On 27/11/2014, M Farkas-Dyck wrote: > • Unambiguous grammar > • Low level > • Tuples > • Easy interface with C Forgot one: • Free declaration order On 27/11/2014, Troels Henriksen wrote: > The only implementation seems to be written in a pretty atrocious style: > https://github.com/strake/pkc/blob/master/CodeGen/Common.hs Yeah, it is messy. Alas, code alignment means messy diffs when one modifies that alignment, so it's a choice of evils. Perhaps I chose poorly. > Also - why care about whether or not the grammar is simple to parse if > you're using something like Haskell to implement it, which can easily > handle very context-dependent grammars? Not as easily as a parser generator with a context-free grammar. I'm not against context-sensitivity per se but C's is wanton. > I'm curious about which flaws of C you are trying to fix. Sure, the > syntax is simplified, and maybe the built-in numeric types are a little > saner, but the benefit of such seems low compare to the cost of using > such an obscure language. The biggest one is tuples. > If you really want to substantially improve on C, I think adding a more > elaborate type system, with which you can encode more invariants without > run-time cost, is a more interesting approach, which can be seen in > e.g. Rust. Yes, such compiler-checked invariants are interesting, and potentially winning, but beyond the scope of K for now at least. > This will cost you greatly in increased implementation > complexity, which I think is not to the taste of many on this list. > Most of the complexity in a minimal C compiler will be in the parser, > for example. Which shows why parsibility is careworthy ☺
Re: [dev] K, a low-level procedural imperative programming language
M Farkas-Dyck writes: > Given the comments on alternatives to C lately on dev@ I thought this > a good time to introduce mine: http://k-lang.org/ The only implementation seems to be written in a pretty atrocious style: https://github.com/strake/pkc/blob/master/CodeGen/Common.hs Also - why care about whether or not the grammar is simple to parse if you're using something like Haskell to implement it, which can easily handle very context-dependent grammars? I'm curious about which flaws of C you are trying to fix. Sure, the syntax is simplified, and maybe the built-in numeric types are a little saner, but the benefit of such seems low compare to the cost of using such an obscure language. If you really want to substantially improve on C, I think adding a more elaborate type system, with which you can encode more invariants without run-time cost, is a more interesting approach, which can be seen in e.g. Rust. This will cost you greatly in increased implementation complexity, which I think is not to the taste of many on this list. Most of the complexity in a minimal C compiler will be in the parser, for example. -- \ Troels /\ Henriksen
Re: [dev] K, a low-level procedural imperative programming language
On 27/11/2014, FRIGN wrote: > No, bloody you! ... I'm proposing the language. If you want to claim that my language won't work, and fill out the checklist, feel free; I'll be over here, using it.
Re: [dev] K, a low-level procedural imperative programming language
On Thu, 27 Nov 2014 16:35:42 -0500 M Farkas-Dyck wrote: > Who? "You" is a 2nd-person pronoun. Richard Stallman of course. ... No, bloody you! -- FRIGN
Re: [dev] K, a low-level procedural imperative programming language
On 27/11/2014, FRIGN wrote: > On Thu, 27 Nov 2014 15:47:08 -0500 > M Farkas-Dyck wrote: >> > > Fill out the checklist[0] already (just copy/paste it in your > mail-client and tick) ;) Who? "You" is a 2nd-person pronoun.
[dev] Re: Questions about sta.li
Hi, Is there anything already done about it? I can't find it on the git repository. I'm very interested and I would like to help to bring sta.li to reality. Regards, -- Henrique Lengler
Re: [dev] K, a low-level procedural imperative programming language
On Thu, 27 Nov 2014 15:47:08 -0500 M Farkas-Dyck wrote: > Fill out the checklist[0] already (just copy/paste it in your mail-client and tick) ;) Cheers FRIGN [0]: http://colinm.org/language_checklist.html -- FRIGN
Re: [dev] K, a low-level procedural imperative programming language
On 27/11/2014, Wander Nauta wrote: > What does your language have to offer? Is it safety? Expressiveness? > Productivity? Ease of use? • Unambiguous grammar • Low level • Tuples • Easy interface with C > Do K programs run faster than C programs? Not in general. > Also, what is a 'for loop afterthot' (sic) It is done at the end of each loop iteration, e.g. increment loop counter. > why are the operators all weird Weird? > why do you use parentheses where every C-like language uses braces In K, braces mean struct. Parentheses are needed about sequential function bodies lest f () : () ≔ (); x : (); be so parsed as 2 declarations: f () : () ≔ (); x : (); > why are integer types 'word-sized'? Some are, some aren't. E.g. "Nat 8" is an unsigned byte. > Not criticizing your great plans, just genuinely curious. Yep, it's cool ☺ On 27/11/2014, pancake wrote: > c makes hidden heap allocations? Wat No, I meant that a true alternative to c for systems programs must also not make hidden heap allocations.
Re: [dev] K, a low-level procedural imperative programming language
c makes hidden heap allocations? Wat > On 27 Nov 2014, at 19:39, Wander Nauta wrote: > > What does your language have to offer? Is it safety? Expressiveness? > Productivity? Ease of use? Do K programs run faster than C programs? > > Also, what is a 'for loop afterthot' (sic), why are the operators all > weird, why do you use parentheses where every C-like language uses > braces and why are integer types 'word-sized'? > > Not criticizing your great plans, just genuinely curious. > > Regards, > Wander > > P.S.: Obligatory link to http://colinm.org/language_checklist.html > >> On 11/27/2014 04:32 PM, M Farkas-Dyck wrote: >> Given the comments on alternatives to C lately on dev@ I thought this >> a good time to introduce mine: http://k-lang.org/ >> >> The goal is a language appropriate for systems programs including >> kernels, sans some flaws of C. This likely means no hidden heap >> allocations. >> >> This is very much a work in progress. In particular I not yet know how >> to do arrays, modules/includes, or macros sanely. >
Re: [dev] Object-Oriented C for interface safety?
On Thu, Nov 27, 2014, at 07:27, koneu wrote:
> Greetings.
>
> The two things that really make OO languages worthwhile in my opinion
> are polymorphism and inheritance. Doing polymorphism and data/code
> hiding in C is easy enough with const function pointers. You can just
> define public interfaces in their own header like
>
> struct interface {
> void * const this;
> int (* const get_foo)(void *this);
> void (* const set_foo)(void *this, int foo);
> char * (* const get_bar)(void *this);
> void (* const set_bar)(void *this, char *bar);
> };
>
> and implement them in "classes" like
>
> struct class {
> int foo;
> char *bar;
> };
In general when this is done in real life, you do it the other way
around, so you only need one copy of the interface structure per class.
Re: [dev] K, a low-level procedural imperative programming language
What does your language have to offer? Is it safety? Expressiveness? Productivity? Ease of use? Do K programs run faster than C programs? Also, what is a 'for loop afterthot' (sic), why are the operators all weird, why do you use parentheses where every C-like language uses braces and why are integer types 'word-sized'? Not criticizing your great plans, just genuinely curious. Regards, Wander P.S.: Obligatory link to http://colinm.org/language_checklist.html On 11/27/2014 04:32 PM, M Farkas-Dyck wrote: > Given the comments on alternatives to C lately on dev@ I thought this > a good time to introduce mine: http://k-lang.org/ > > The goal is a language appropriate for systems programs including > kernels, sans some flaws of C. This likely means no hidden heap > allocations. > > This is very much a work in progress. In particular I not yet know how > to do arrays, modules/includes, or macros sanely. >
[dev] Re: K, a low-level procedural imperative programming language
On 27/11/2014, M Farkas-Dyck wrote: > This is very much a work in progress. In particular I not yet know how > to do arrays, modules/includes, or macros sanely. Or atomics.
[dev] K, a low-level procedural imperative programming language
Given the comments on alternatives to C lately on dev@ I thought this a good time to introduce mine: http://k-lang.org/ The goal is a language appropriate for systems programs including kernels, sans some flaws of C. This likely means no hidden heap allocations. This is very much a work in progress. In particular I not yet know how to do arrays, modules/includes, or macros sanely.
Re: [dev] Object-Oriented C for interface safety?
On 27/11/2014, koneu wrote: > Of course each "class" can only implement one interface. Why? C lacking tuple types makes implementing more awkward but not impossible.
Re: [dev] Object-Oriented C for interface safety?
Greetings.
The two things that really make OO languages worthwhile in my opinion
are polymorphism and inheritance. Doing polymorphism and data/code
hiding in C is easy enough with const function pointers. You can just
define public interfaces in their own header like
struct interface {
void * const this;
int (* const get_foo)(void *this);
void (* const set_foo)(void *this, int foo);
char * (* const get_bar)(void *this);
void (* const set_bar)(void *this, char *bar);
};
and implement them in "classes" like
struct class {
int foo;
char *bar;
};
static int
class_get_foo(void *this) {
return ((struct class *)this)->foo;
}
static void
class_set_foo(void *this, int foo) {
((struct class *)this)->foo = foo;
}
static char*
class_get_bar(void *this) {
return ((struct class *)this)->bar;
}
static void
class_set_bar(void *this, char *bar) {
((struct class *)this)->bar = bar;
}
struct interface
new_class(int foo, char *bar) {
struct class *this = malloc(sizeof(struct class));
this->foo = foo;
this->bar = bar;
return (struct interface){
this,
class_get_foo,
class_set_foo,
class_get_bar,
class_set_bar
};
}
For proper data & code hiding you will want all the code for the
"class" implementing your interface in its own source file and only the
prototype of new_class in a header.
You can then treat all instances of your interface the same, no matter
what "class" implemented them. For example
void
foo(void) {
struct interface bar = new_class(42, "so far");
printf("%d\n", bar.get_foo(bar.this));
free(bar.this);
bar = new_class2();
/* who knows... ? */
bar.set_bar(bar.this, "and thanks for all the fish");
printf("%s\n", bar.get_foo(bar.this));
}
Of course each "class" can only implement one interface.
Inheritance is harder to do, it usually involves nested structs and
doesn't play well with the above implementation of interfaces.
Have fun experiencing C and its beautiful simplicity. And try googling
"c programming" instead of "c". ;)
Sincerely,
Re: [dev] Object-Oriented C for interface safety?
On Wed, Nov 26, 2014 at 10:55 PM, pancake wrote: > Try Cello > I did try Cello. Cello turned out absolutely useless for me as interfacing it with other C standard types is a PITA / completely broken. After fiddling around for a while I got sick from what Cello does with code I would write and gave up. Seriously, any attempt to emulating duck typing in C is a joke and should be wiped off the face of this planet. With fire. Creating an actual interface layer on top of C as those intermediate languages do might look like an option, but then you're left there with your own implementation of guile - or worse, javascript. From where there's nothing left to do wrong any longer. I then started trusting my C skills again and wrote whatever I was attempting to do in plain C - and it worked. cheers! mar77i
