31–40 of 84 posts
On a related note, the most principled approach to macros for an infix language I've yet seen is Honu (brought to you by the Racket people): http://www.cs.utah.edu/plt/publications/gpce12-rf.pdf .
I'll take the time to read the paper later. Do you know how does it compares with Dylan's macros?
I am very intrigued by Nimrod. The language seems to have goals that overlap with e.g. Rust, but with a bunch of really interesting design decisions (e.g. GC by default, but first class support for manual memory management). Given the amount of force driving Rust (and Rust's PR machine), compared to Nimrod which seems to be really pushed forward by one single person, I'm really impressed by how far Nimrod got. I real…
If I understand correctly once you stop using the GC, Nimrod is not memory safe. Rust is.
I am very intrigued by Nimrod. The language seems to have goals that overlap with e.g. Rust, but with a bunch of really interesting design decisions (e.g. GC by default, but first class support for manual memory management). Given the amount of force driving Rust (and Rust's PR machine), compared to Nimrod which seems to be really pushed forward by one single person, I'm really impressed by how far Nimrod got. I real…
If I understand correctly once you stop using the GC, Nimrod is not memory safe. Rust is.
I really enjoy the language so far. For me, it's the perfect middleground between C and python: a fast compiled language, and one where you can be as productive as in python. I also tend to prefer catching errors early, and having a typed language that warns and errors at compile-time is great.
I've found some (arguably minor) things to be kinda messy. Maybe the result of a one-person language that grows too much before getting some feedback. 1) Everything is (strangely) called a procedure, and then there's syntax to differentiate arguments that will be modified in place (proc myproc(myarg : int, inplacearg : var int)). Kinda weird, and a lost opportunity to have checking for pure functions at compile time.…
I really enjoy the language so far. For me, it's the perfect middleground between C and python: a fast compiled language, and one where you can be as productive as in python. I also tend to prefer catching errors early, and having a typed language that warns and errors at compile-time is great.
I've found some (arguably minor) things to be kinda messy. Maybe the result of a one-person language that grows too much before getting some feedback. 1) Everything is (strangely) called a procedure, and then there's syntax to differentiate arguments that will be modified in place (proc myproc(myarg : int, inplacearg : var int)). Kinda weird, and a lost opportunity to have checking for pure functions at compile time.…
3. If == runtime control structure. When == COMPILE time control structure...code in a failing when clause is not compiled. Basically the equivalent of something like an #ifdef pre-processor macro in C.
4. Eh, I like it.
5. Never been an issue.
From the little I know about metaprogramming, it sounds analogous to doing string manipulations in a language, and then eval'ing it (which is heavily frowned upon, at least in python). How is this understanding wrong?
In a lot of instances, a macro isn't particularly more complicated in intent than a string + eval solution; it's just a much more verbose way of attacking the problem.
Earlier quoted context omitted.
Oh, it does bring a lot to the table that C and Python don't have. You're totally right, it is not a middleground per se, it is just the language I was looking for. If I try to answer your points: -> 1) The procedure keyword comes from Pascal. I am not shocked by it, when I learned programming the teacher used to call them procedures also. The 'var' in procedure arguments could be considered the opposite of the 'cons…
1) I'm not a fan of both the name `proc` and `var` because it allows you to mix inplace editing with return values and makes a mess of the (IMO, precise) meanings "function" and "procedure" have. If I were starting a new language, I wouldn't pass the opportunity of disallowing mixing these concepts, so there's a way to reason about pure functions. 3) I get that, but it feels like something that could've been optimize…
Earlier quoted context omitted.
Go interfaces are also new.
I looked at http://golangtutorials.blogspot.com/2011/06/interfaces-in-go... and the only new aspect of Go interfaces I see is that they are implicit - they are considered implemented if the type implements functions that interface defines and you don't need to explicitly write "implements Something". This is a handy shortcut, but it doesn't look like a "serious feature". It also looks a bit like polymorphic variants…
Contrast with Java where you'd have to both create a new interface and write an adapter class in a separate "glue" library that has hard dependencies on both libraries.
Earlier quoted context omitted.
Oh, it does bring a lot to the table that C and Python don't have. You're totally right, it is not a middleground per se, it is just the language I was looking for. If I try to answer your points: -> 1) The procedure keyword comes from Pascal. I am not shocked by it, when I learned programming the teacher used to call them procedures also. The 'var' in procedure arguments could be considered the opposite of the 'cons…
1) I'm not a fan of both the name `proc` and `var` because it allows you to mix inplace editing with return values and makes a mess of the (IMO, precise) meanings "function" and "procedure" have. If I were starting a new language, I wouldn't pass the opportunity of disallowing mixing these concepts, so there's a way to reason about pure functions. 3) I get that, but it feels like something that could've been optimize…
3) You can't optimize it away. A compile-time conditional statement has to allow for undefined identifiers and such, but for a runtime conditional statement you want to have the compiler signal an error even if it can statically determine that the condition is always true or false.
[1] http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0143-1...