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.

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?

> 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?

because you can write to a variable or pass it to more than one function

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.

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.

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#re...

C isn't especially dynamic.

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.

Looks like a very cool language (I can't help but love any language with real macros), but it looks more like ML than Python to me. I wonder how this compares to OOC. I think I might have to run them both through some tests and publish the results (aesthetics, speed (although I doubt that'll be an issue), flexiblity, etc).

looks cool! what features did the author add beyond straightforward (nice-looking) syntactic transformations from Python-like syntax into C code? in other words, if i stared at Brace code and imagined how to manually translate it into C, what tricky cases are there?

the ability to quickly generate graphics with little code reminds me of Processing: http://processing.org/

I would really like to mess around with this, but it doesn't compile under OS X because of some utility differences (namely readlink and cp).

drat! I didn't have an OS X box to test it on. I'll ask one of my friends to fix it for me or let me log in to do so. thx for the heads-up.

Hmm,

I'd like to have a dialect of Python that looks C.

Python is a generally cool and you can get used to meaningful whitespace easily BUT the meaningful white space thing becomes very problematic when you're on an arbitrary system using vi and without tools for dealing with Pythonism. When we had a serious bug that was removed by rewriting whitespace in a way we couldn't even determine by sight, I swore never to use the language again. I did a couple of years of python coding earlier. Kind of like project Mono's unexplained memory leaks.

:retab

(in vim)

You've nailed it; they did it backwards :(

First OOC, now this. What is the need to make anything look like the ugly indented mess that is python?

since some people like C's syntax and some people like python's syntax, I hope to support both in future, changing one to the other can be as simple as running a program like "indent" over the code.

You borrow so much from the Ruby community you should add opinionated design to the list. Adding a second syntax to OOC would really detract from the language a lot.