I like C but not its syntax

Why hasn't anyone made C that doesn't look like dogshit?

Just use s-exps. Should be easy e.g. with Racket. I mean, there is already L++.

(def pointer_compare (-> (location1 void *) (location2 void *) int)
(cond
((< location1 location2) ~1)
((> location1 location2) 1)
(t 0)))

(def string_hash (-> (string void *) (unsigned int))
(def result (: int) 5381)
(def p (: (unsigned char *)))
(set! p ((cast unsigned char *) string))
(while (!= (@ p) '\0')
(set! result (+ (<< result 5)
(result)
(@ p)))
(++ p))
(result))

I'm sorry, I meant

(def string_hash (-> (string void *) (unsigned int))
(def result (: int) 5381)
(def p (: (unsigned char *)))
(set! p ((cast unsigned char *) string))
(while (!= (@ p) '\0')
(set! result (+ (<< result 5)
(result)
(@ p)))
(++ p))
result)

C looks fine

>>6
...in this thread.

creat

>>8
Blame Unix, not C. I guess it comes up Thompson either way and even he regrets it.

Unfortunately there's no way to use a Lisp as a GC-less systems language. The syntax is tied to the evaluation model, which depends on being able to perform arbitrary allocations in the construction of a value. Even if you implemented a new dialect designed for manual memory management, there would simply be no way around this problem.

>>10
There's a way to use Lisp syntax for C.

>>11
No, unfortunately, that's just impossible.

>>12
Whatever you say. Just don't visit this page, it might shatter your worldview:

https://bitbucket.org/ktg/l

The goofy syntax is not even the worst problem with C, by far. It's the way it straddles the huge gulf between "portable assembler" and "fast applications language" and isn't especially good at either of those roles. A language trying to replace C should aim for one side of that chasm or the other, and do a better job there.

>>8-9
DOS has create
Checkmate unix niggers.

>>14
The syntax is the only problem with C. Read >>1.

>>16
The syntax is the only non-problem with C.

>>17
No, the syntax is definitely one of the problems with C.

creat my anus

>>18
The syntax is as good as programming language syntax will ever get. You won't improve on it, because there's no improvement to be had.

>>20
Try trolling more gently next time, OK?

There are some inconsistencies with the syntax; however, the syntax itself is simple and (for the most part) consistent.

>>22
Also ugly and stupid. Why does the return type come before the function name? Why do I have to visually fish the line to get the fucking name of what's being declared?

def func_name(type1 arg1, type2 arg2): ret_type { ...

would be much better.

>>22
Another thing that's wrong with C's syntax is that the "pointer" operator at the type level is the same as the "dereference pointer" at the value level. Because of that I always want to throw up when I see C code. These are two fucking opposite operations, who had the idea to denote them with the same (*) sign? Fucking idiots.

Also the array syntax is stupid. Why is it int arr[] if it's not an int? It's an array of ints, the [] needs to go to the type, ya incestuous drunken faggots. Hey, it's equivalent to int* arr (at least in function arguments), so why does the * go to the type if the [] goes to the identifier? Fucking disgusting.

>>23
What the fuck? No, C is fine as it is.

>>26
But its syntax sucks.

>>27
The return type before the function type is the least of the concerns about its syntax,

>>28
Well why don't you tell us your major concerns about its syntax? Also if it's a small concern, why was this mistake fixed in newer languages like Rust and Go?

>>28
Having the return type anywhere else is stupid and doesn't make any sense.

>>23
Personally, it looks better with the type before, but it's harder to parse. I'm not sure why they did that. I wouldn't, in a language I made.

>>24
It's a mnemonic. But I don't wonder why you don't know it, only a retard would complain about C's syntax.
int **i means that **i is of type int.

>>25
Same for this. int arr[] means that arr[N] is of type int

Hey, it's equivalent to int* arr

Only people that do not understand C syntax use int* arr. This shows something about you.

so why does the * go to the type if the [] goes to the identifier

It does not. Think of int* a, b. b is a int while *a is a int.

I still have to see a real problem about C's syntax in this thread.

>>23-25,31
You do not understand C. Naturally you are frustrated and confused by what you do not understand. But, as I know better, I will selflessly go out of my way to enlighten you.

In other languages, you would write the identifier, and then the identifier's type: Foo : Integer, Bar : Map<String, Float>, and word []char. But the syntax for declaring such identifiers is completely different from the syntax for using them in your code, which complicates the language: You must be able to express both the name of the type itself and the way it is used.

In C, there is a different basic rule: You write the type of an expression (the contents of a dereferenced pointer or array, or the return value of a function) and then you write an expression invoking the identifier you are declaring, using exactly the same syntax as you would in normal code. And naturally, the type of that expression is the same type that precedes it in the declaration: The type of *p is int, and therefore you would write int *p. The type of buf[n] is unsigned char, and therefore you would write unsigned char buf[BUFSIZ].

If it were not done this way, C would need additional syntax for each of these types: A special syntax for function types, a special syntax for pointer types, and so on. Reusing what is already there allows the compiler to save precious memory and grammar complexity by simplifying the language. It is the best choice a language designer could have made.

>>31

but it's harder to parse

How's that?

only a retard would complain about C's syntax.

Didn't read the rest.

>>33
Okay, I see some sort of rationale behind C's syntax, but it still doesn't justify the choices made for C. For example, writing the function declaration like

int func_name(...);

would make sense in a pure language, where the expression func_name(...) may indeed be replaced by a value of type int. But it doesn't make sense in C because there are unrestricted implicit side effects everywhere, and a function call is not, as a rule, observationally equivalent to its return value.

Same goes for the other arguments:

1) C wouldn't need a special syntax for function types because it doesn't have function types. It forces you to use (void *) for all function types.

2) C already has special syntax for pointer types, e.g.

[code]typedef int* IntPtr ;

3) C already has an infernally complex grammar. If simplicity was wanted, why not use s-exps? They're much simpler.

>>35
You just proven me right.

>>37
No. I've just seen that you are a conceited idiot and you present no proofs to the contrary.

If you can't argue without calling names you're obviously wrong. That's what "add hominem" means.

>>39
Ad hominem