Basically, when you leave out the ‘{’ then Haskell uses your intendation to insert ‘;}’ on later lines between the leading whitespace and the first token.
There some really old Haskell code out there that lines up the ‘{;}’ characters on the left under block-introduction keywords.
It’s not just old Haskell code that’s how you write Haskell if you want explicit braces. Well, mostly generate, but it’s still the idiomatic formatting (and when you generate you always generate braces because it’s easy to get layout subtly wrong when generating).
Haskell also does the whole
data Foo = Bar
| Baz
| Quux
foo = [ Bar
, Baz
, Quux
]
thing, makes sense to apply it to braces especially as they’re seen only very rarely. Single-line, yes, but not multi-line.
I think you’ll like Ruby. It has mostly done away with braces and code blocks end with end, e.g.
defcreateunless admin redirect_to new_session_path andreturn@product = Product.new product_params
if@product.save
flash[:success] = "New product has been created!"
redirect_to edit_product_path(@product) andreturnelse
flash[:error] = "Something went wrong!
render :new
end
end
This is working code that I simplified a bit from an old project of mine.
Ruby syntax is nice although I prefer python way of enforcing indentation instead of adding "end"s. Personally I just want a statically typed language with enforced indent as syntax.
Funny, the forced indentation is what I hate about Python. If you think a missing semicolon can be hard to catch, don’t ever think about a missing whitespace :p
The end keyword really isn’t a big deal for me. I find it to be a good way to easily spot the end of a method. But if you wouldn’t like it I’d still find it a good compromise to avoid syntax issues due to whitespace.
Same and agreed, especially if you keep your functions small and focused as you should. 3-5 indents is nbd to keep track of, and if you need more than that… No you don’t, refactor.
I’ve had way more hangups with brackets then indentation, personally, not that either is a super frequent issue, but I’m indenting anyway, so brackets are redundant and just another thing I have to keep track of
That’s just Algol instead of B. Most languages use the one or the other, then there’s sexpr-based languages (lisp, scheme), lua (technically Algol but not needing semicolons while also not needing newlines so it’s definitely special), and layout syntax (Haskell, or, if you want a bad implementation, python).
I kinda like it…
Might check out the Haskell layout rules.
Basically, when you leave out the ‘{’ then Haskell uses your intendation to insert ‘;}’ on later lines between the leading whitespace and the first token.
There some really old Haskell code out there that lines up the ‘{;}’ characters on the left under block-introduction keywords.
It’s not just old Haskell code that’s how you write Haskell if you want explicit braces. Well, mostly generate, but it’s still the idiomatic formatting (and when you generate you always generate braces because it’s easy to get layout subtly wrong when generating).
Haskell also does the whole
thing, makes sense to apply it to braces especially as they’re seen only very rarely. Single-line, yes, but not multi-line.
I think you’ll like Ruby. It has mostly done away with braces and code blocks end with
end, e.g.def create unless admin redirect_to new_session_path and return @product = Product.new product_params if @product.save flash[:success] = "New product has been created!" redirect_to edit_product_path(@product) and return else flash[:error] = "Something went wrong! render :new end endThis is working code that I simplified a bit from an old project of mine.
Ruby syntax is nice although I prefer python way of enforcing indentation instead of adding "end"s. Personally I just want a statically typed language with enforced indent as syntax.
Funny, the forced indentation is what I hate about Python. If you think a missing semicolon can be hard to catch, don’t ever think about a missing whitespace :p
The
endkeyword really isn’t a big deal for me. I find it to be a good way to easily spot the end of a method. But if you wouldn’t like it I’d still find it a good compromise to avoid syntax issues due to whitespace.}helps me easily spot the end of stuff.endjust blends into the statements.i can count on one hand how many times ive had white space issues in 15 years of using python. its just not an issue
Same and agreed, especially if you keep your functions small and focused as you should. 3-5 indents is nbd to keep track of, and if you need more than that… No you don’t, refactor.
I’ve had way more hangups with brackets then indentation, personally, not that either is a super frequent issue, but I’m indenting anyway, so brackets are redundant and just another thing I have to keep track of
That’s just Algol instead of B. Most languages use the one or the other, then there’s sexpr-based languages (lisp, scheme), lua (technically Algol but not needing semicolons while also not needing newlines so it’s definitely special), and layout syntax (Haskell, or, if you want a bad implementation, python).
Who’s going to write the extension so that they are all hidden and automatically inserted?