4 ms·

More than a dialect, a skin over C which could use some syntactic sugar. let(a,1)? In my book "a = 1", not even "let a = 1". It could be interesting, but the ex

More than a dialect, a skin over C which could use some syntactic sugar. let(a,1)? In my book "a = 1", not even "let a = 1". It could be interesting, but the examples are too LOGO-ish, it could do trivial "duck-typing" (does "int a = 0" really need the "int"?), and the trade-off of using an imperative language or using another imperative language _and_ using another compiler isn't worth it.

tumult 17y ago
That's not trivial, suddenly you have to have type inference. 1? Did you mean an int? Float? Double? 8 bits? 16? 32? 64? signed? unsigned?
- pgbovine 17y ago
  yup, agreed. type inference for a dynamically-typed language is extremely hard to do well ... you often have to make people program in a restricted 'static' subset of the language, like what PyPy does with the RPython dialect: http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#re...
  - ramchip 17y ago
    C isn't especially dynamic.
- viraptor 17y ago
  > 1? Did you mean an int? 1 > Float? 1.0f > Double? 1.0 > 8 bits? 16? Those would actually need the type. > 32? 1 > 64? 1ll > signed? 1 > unsigned? 1u C copiler already does that "inference" when you pass an attribute into a function - so why not when you declare the variable?
  - tumult 17y ago
    because you can write to a variable or pass it to more than one function
    - viraptor 17y ago
      So you can infer the type on the first usage only and then treat the variable like it has a static type (because it does). That's what most type-inferring, static languages do.
      - tumult 17y ago
        the really smart, immutable ones, could let you treat the expression as any of those types as you like. this is supposed to be a cleaner C syntax, not another platform.
sswam 17y ago
brace is an experimental language, the let(a,1) business it a very primitive approach to type inference, it is simply a macro that translates to typeof(1) a = 1 (and unfortunately thereby depends on a gcc extension). I do hope to add proper type inference in a later version of brace.

tumult 17y ago

That's not trivial, suddenly you have to have type inference. 1? Did you mean an int? Float? Double? 8 bits? 16? 32? 64? signed? unsigned?

pgbovine 17y ago
yup, agreed. type inference for a dynamically-typed language is extremely hard to do well ... you often have to make people program in a restricted 'static' subset of the language, like what PyPy does with the RPython dialect: http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#re...
- ramchip 17y ago
  C isn't especially dynamic.
viraptor 17y ago
> 1? Did you mean an int? 1 > Float? 1.0f > Double? 1.0 > 8 bits? 16? Those would actually need the type. > 32? 1 > 64? 1ll > signed? 1 > unsigned? 1u C copiler already does that "inference" when you pass an attribute into a function - so why not when you declare the variable?
- tumult 17y ago
  because you can write to a variable or pass it to more than one function
  - viraptor 17y ago
    So you can infer the type on the first usage only and then treat the variable like it has a static type (because it does). That's what most type-inferring, static languages do.
    - tumult 17y ago
      the really smart, immutable ones, could let you treat the expression as any of those types as you like. this is supposed to be a cleaner C syntax, not another platform.

sswam 17y ago

brace is an experimental language, the let(a,1) business it a very primitive approach to type inference, it is simply a macro that translates to typeof(1) a = 1 (and unfortunately thereby depends on a gcc extension). I do hope to add proper type inference in a later version of brace.