61–70 of 81 posts
Earlier quoted context omitted.
No, I meant that Haskell doesn't consider any whitespace that isn't indentation as significant.
Very few languages consider non-indentation whitespace as significant (not counting using whitespace as a token delimiter, which Haskell definitely does, e.g. "foo bar" =/= "foobar").
Earlier quoted context omitted.
There was some discussion about doing this in D, and there was some in C++11, too. I argued that the presence or absence of the ; did not visually stand out very well, and so would be a source of confusion and errors. Hence, ; remained as a statement terminator, and the return keyword served to indicate returning an expression. However, the D lambda syntax does not require a ; when the lambda body consists of only a…
An understandable point of view. Though I can think of an even more crazy variation. Declare the semicolon a binary operator and allow overloading it. As funny as that sounds, Haskell provides something like this, as do-notation can behave differently depending on the monad it is in.
http://en.wikibooks.org/wiki/C%2B%2B_Programming/Operators/O...
My mind is blown. You can write bottom-up code in C++ :)
EDIT: no, you still can't the expressions are evaluated first, before calling "operator,"
Earlier quoted context omitted.
There was some discussion about doing this in D, and there was some in C++11, too. I argued that the presence or absence of the ; did not visually stand out very well, and so would be a source of confusion and errors. Hence, ; remained as a statement terminator, and the return keyword served to indicate returning an expression. However, the D lambda syntax does not require a ; when the lambda body consists of only a…
An understandable point of view. Though I can think of an even more crazy variation. Declare the semicolon a binary operator and allow overloading it. As funny as that sounds, Haskell provides something like this, as do-notation can behave differently depending on the monad it is in.
In other words, the semicolons of Haskell are only tenuously related to semicolons in languages like C.
Earlier quoted context omitted.
Wouldn't the type system complain that you're returning nil in a function that is not declared/inferred as returning nil?
What if foo() could return nil in some cases?
AFAIK, Rust doesn't have nil. So, the closest thing is using the option type.
Earlier quoted context omitted.
Bug prone? The compiler will inevitably warn you about your error at compile time. No such bug will have any consequence beyond that. This is also not such a big problem when a human reads the function. We can always see at a glance the return type of the function. Either it's explicitly declared, or it's a lambda whose usage is readily visible. Semicolon or not, you can easily guess if the function is supposed to re…
Ok, I misunderstood then. I thought it would subtly return no value instead of a value, and you'd only discover this at run time. That would be bug prone. If it simply generates a compilation error, no problem.
foo :: Int -> [a]
data Maybe a = Just a | Nothing
bar :: Int -> Maybe [a]
[1] Actually, I lied a bit, since there is bottom: http://www.haskell.org/haskellwiki/Bottom But bottom does not fullfil the same role as, say null pointers.
a ; b is the operator which returns the value of b. And, there is some syntactic sugar to make a ; equivalent to a ; nil which returns nil.
Earlier quoted context omitted.
Very few languages consider non-indentation whitespace as significant (not counting using whitespace as a token delimiter, which Haskell definitely does, e.g. "foo bar" =/= "foobar").
Ruby and CoffeeScript do and their syntax relies heavily on it.
You pretty much only need to remember to separate tokens where lack of whitespace might create a different vald token, and ensure any expressions that you want to let span more than one line ends with something that expects following tokens to make a complete expression.
Personally I can live with that easily. I can not live with significant indentation, on the other hand...
Earlier quoted context omitted.
Ignoring a potentially wanted return value with ";" is a hazard. I'd like to institute some set of "warn-unused-result" warnings in Rust to combat this.
Wouldn't the type system complain that you're returning nil in a function that is not declared/inferred as returning nil?
// This function lives at the top level of the module, so its types must be annotated
fn foo(bar: int) -> int {
// Here's a closure without type annotations:
let baz = |qux| { qux + 1 };
// And a closure with type annotations:
let baz = |qux: int| -> int { qux + 1 };
// Which means that this would be a compile-time error:
let baz = |qux: int| -> int { qux + 1; }; // returning nil, but expected int
// But if you expect this to return int, then there are very few cases where
// this might not be a compile-time error:
let baz = |qux| { qux + 1; };
log(error, baz(bar)); // will print "()", but did you want bar + 1?
io::println(fmt!("%?", baz(bar))); // same as previous
io::println(fmt!("%d", baz(bar))); // this one *is* a compile-time error
// macros ftw
baz(bar); // this will also be a compile-time error
}Earlier quoted context omitted.
Hello American. I'm from one of those other pesky countries that make up most of the human population of earth, and which usually have other keyboard layouts. I have to type shift+, to get the semicolon.
A potential workaround is to always use an American keyboard. It's what I do.
Earlier quoted context omitted.
What if foo() could return nil in some cases?
Then you need an algebraic data type having nil is one of its constructors, and that function returning that type. AFAIK, Rust doesn't have nil. So, the closest thing is using the option type.