Hacker News Reader

Comment by levodelellis | Hacker News Reader

I won't speak for teammates but I found everytime I list features people don't really think about it. Maybe it's because they never seen it so they never thought about it and as a consequence don't think it's noteworthy. If you browse through the pages and read the examples you'll see many. The On statements for loops are my favorite and elsewhere someone told me they have no idea why I would want to know if a loop is complete (meaning you didn't break or return out of it) or why I would want a special handler for when you break a loop.

View on HN

Python has an ‘else’ block for ‘while’ and ‘for’ which executes when the loop completes without a break or return.

Never used it myself but it is probably handy, handy enough to be included in the language at least.

_OnComplete works on while and for loops. There's an empty as well and I'm not sure if empty should also execute complete or not. I figure I'll know after writing real code in more than one project

> If you browse through the pages and read the examples you'll see many

Respectfully, I browsed all the examples I could find on the site (Highlights, Examples, and Quick Start) and I'm not really sure what you expect to be recognized as novel ("Has features not found in any other language"). You may have a combination of features that is unique, but nothing individually stood out as something never seen before. Perhaps you just need to highlight these things better.

Notes:

> value = fn1() error { return }

Allow for Error short circuits. This has slowing been adopted by other languages - An error can be handled/or not and continue cleanly without crashing anything (erlang style) or typed semantics (Java style). Go can return an error message, as part of the multi-return semantics, similarly allowing for error short circuits. Because of Bolin's multiple return semantics, you can implement this pattern as well, but it's nice to not bake it in.

The for-loop conditional exit handlers are novel enough.

Some unique syntax choices, like .= for assign and mutable/immutable assignment dynamically is great. Ponylang has typed containers that act similarly, but they are not dynamically declared.

I know I've seen lazy type signatures before, but I don't remember where. So I'd consider it novel enough to note: ie you don't need to specify int every param -> add(int a, b) and implicit void on main()

I can't speak to under-the-hood compiler optimizations, but there's a little bit here and there that's interesting.

P.S. Typo in: https://bolinlang.com/quickstart/basics //you don't need to specificy int every param

> Allow for Error short circuits

Is the `try` keyword in the highlight section what you're looking for? You can write `var = try fn()`

Thanks. I fixed the typo when I first saw this hours ago but it's been busy and I forgot to reply

> Is the `try` keyword in the highlight section what you're looking for?

I worded it poorly.

> Allow for Error short circuits

I was trying to say that I liked the feature as-is, because it Allows for Error short circuits. There are a lot of common patterns that modern languages avoid idiomatically, despite their widespread use in roundabout ways.

I'm not good with this site. Do most people have some kind of notification when someone replies to them?

Is the problem with short circuits that you can ignore the error? It's not documented yet but `error return` requires the function to be an error type so the error can propagate. If thats not good enough do you have some insight on how to fix it? What's worse and was designed intentionally by me is `fn() error { return }` not requiring the function to have an error return (although this would be a void return type). I make the assumption if you have a block (instead of `error return`) you're handling the error. You can also propagate by doing something like this `nonErrVal = fn() error { print("write a better error log"); return error }`.

"Can you give a reason I would spend the time of looking through the docs?"

"If you look through the docs you'll find many reasons"

The first sentence explains why. You don't need to be a jerk

If you know that answering the question will make people lose interest then that suggests they will lose interest even after reading the docs as well.

Reply on news.ycombinator.com