1 Sep
2017
1 Sep
'17
4:58 a.m.
I did a quick read of the language spec but I didn't see a rationale or
nit picky details.... Would have to study it more but I'm not convinced
it is better..... I believe Go has pretty much everything L has (+ I like
its support for concurrency).
Stroustrup's C with classes did seem better but then it became C++.
On Aug 31, 2017, at 7:27 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
No offense intended but I pretty much dealt with all of this in L.
little-lang.org
I'll freely admit it is not perfect but it certainly touches on your
comments and would not be hard to bring into C.
On Thu, Aug 31, 2017 at 07:22:10PM -0700, Bakul Shah wrote:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
On Aug 31, 2017, at 6:26 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
See below. I think it would be not easy to build a simpler language
that is consistent and regular. I just touched on a couple of things
but there would be many more such small decisions....
1. Ptrs. If you remove them completely, functions can become
pure and can not change anything. Most likely you'd end up
adding "ref" parameter, which would be sorta like Pascal's
var parameters.
int f(var int x) {
x++;
return x
}
...
int z = 1;
int y = f(z); // y should be 2
int x = f(z); // x should be 3
The benefit is that now you can not clobber the ptr but
otherwise the same result.
Do you allow declaring refs? You should for consistency.
int x1;
ref int x2 = x1;
But if you allow this, either this assignment behaves
differently from a ref int parameter or it would crash
since x2 doesn't really point anywhere on initialization.
So now you will be tempted to say
ref int x2 = ref x1;
This is almost exactly like
int *x2 = &x1;
A bit ugly. IIRC Algol68 had something similar and well
defined rules for how multi level refs were handled.
2. Passing Arrays. Now you need a way to pass subarrays.
int z[] = {1,2,3,4};
int g(int x[]) {
...
}
...
int x = g(z[3:5]); // g.x[0] = z[3]; g.x[1] = z[4].
Now you need a way to iterate through the array in g.
int g(int x[]) int {
int sum = 0;
for (int i = 0; i < len(x); i++) sum += x[i];
return sum;
}
But what happens if in g you change x[i]? Does z change?
If you don't allow this, x[] becomes a constant but a
scalar variable can be changed. So this is inconsistent.
If you allow this, int x[] almost acts like var int x[]!
For consistency with scalars you should copy z[3:5] but
that can be expensive for large arrays. So now you will be
tempted to use const (now a ref can be impllicitly passed
since array won't be written over).
Then there is the issue of multidimensional arrays.
int z[4][5];
int h(int x[][]) {
...
}
int w = g(z[2:4][1:3]);
If you are fixing arrays, you may as well do them right
so that fortran code can be easily ported. So what about
int h(int x[][]) {
int s = g(x[1][]);
}
Here we're passing a column of z as a vector to g.
You'd end up with a illife vector or something! But
if you do this, vector access can slow down...
> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
>
> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>> I look to the likes of go and rust to get us back on track. C is a pretty good
assembly language.
>
> So what chaps my grumpy old hide is why the heck do a whole new language
> when you have one that is pretty good? Suppose we took C and added a
> dialect via options:
>
> --no-ptrs // use arrays and indices, you get bounds checking
> --strings // system managed memory for strings, like tcl
> --perlisms // if (buf =~ /re/) and unless (it_worked())
Such a language would stop being C.
Indeed. But it builds on C.
In Go you can use slices instead of arrays (but
slices are only one dimensional).
Ptrs are relatively safe as memory is garbage collected so e.g. a function can
return &local_variable. No perlism.
Go provides other features which are quite useful: concurrency, channels,
interfaces, packages.
People who like C tend to like Go. But Go is not low-level enough. No one
is writing a kernel in it! Or doing bare metal programming. AFAIK.
Exactly.
> etc. Why create an entirely new language,
new syntax, new linkage, etc,
> instead of fixing C's shortcomings?
C has too many problems. If you try fixing them, none of the "dusty decks"
would run on such a compiler + the new language would be severely
hampered in its evolution due to its C legacy.
So I'd need to understand more to believe that claim. And for the record,
what I'm going for is a new C that is still C enough to be useful but
fixes the problems enough to be a new language. Someone asked about
C++ and D, nope. Too far from C. I just want a C that fixes enough
of the problems that it is more acceptable to modern programmers but
is still C. Not sure if I'm explaining that well enough.