Hacker News Reader

Comment by Shoop | Hacker News Reader

> The undocumented #? strongSpaces parsing mode has been removed.

I remember seeing lots of controversy over this feature a previous time Nim was posted here. Hopefully, its removal will stop people from dismissing the language outright (which would be a shame given all the things Nim has going for it).

(That being said, if people still want to embrace Wadler's Law [0], there's the hot-button topic of case/underscore insensitivity to talk about. [1])

[0] https://wiki.haskell.org/Wadler%27s_Law [1] https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i...

View on HN

It took me a minute to understand what strongSpaces meant [0] but yikes! That looks like a terrible thing! One question though, what is #? strongSpaces vs #! strongSpaces?

[0] https://nim-lang.org/0.11.0/manual.html#syntax-strong-spaces

I believe that's the syntax for enabling a parsing mode. I think it just changed from #! to #? (to allow a nim bash shebang).

Obviously, the yikes is gone now. It was always an experimental feature, so IMO the fear of it was overblown, but it is a pretty scary idea for a feature.

well, these two things (strongSpaces couldn't have been "undocumented": i knew about it from a cursory glance at the language a few years ago, never wrote more than a hello world in it) made me shy away from the language. i mean, it's niche and all, that does not help, but those two things did decide which way the scales went.

re [0]: whether FUBAR and f_u_b_a_r mean the same thing or not is a matter of semantics, not syntax (it's in the name: "meaning").

re [1]: i use zsh where setopt errexit and setopt e_rR_EX_it mean the same thing, and it's really annoying. all it does is complicate search in man pages and code, i'd say this feature has negative value. e_rR_EX_it is extreme, but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i never know which to search for, and i end up mixing various spellings in zsh code. now shell options are a tiny slice of my shell scripts, but doing this for all identifiers? ugh!

i think the arguments in [1] are weak, unsubstantiated, and admissions of negative value.

> but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i never know which to search for, and i end up mixing various spellings in zsh code. now shell options are a tiny slice of my shell scripts, but doing this for all identifiers? ugh!

It sounds to me like this is a problem with your search tool, if it would search in a style insensitive manner then this wouldn't be a problem, you'd find both.

it would have to ignore underscores as well. does your grep have that functionality bundled under a convenient flag? does your browser's ctrl-f have it for eg. github?

It doesn't. But it should, just because the limitation is the tooling doesn't mean we should give up on this. Instead we should assume that the tooling will evolve. Even if the language is not style insensitive, this kind of search is still useful since you often are not sure what convention was used.

Haven't tried it myself, but have read about nimgrep in previous HN nim threads. Just checked:

https://nim-lang.org/docs/nimgrep.html

Excerpt:

Nimgrep is a command line tool for search&replace tasks. It can search for regex or peg patterns and can search whole directories at once. User confirmation for every single replace operation can be requested. Nimgrep has particularly good support for Nim's eccentric style insensitivity. Apart from that it is a generic text manipulation tool.

Reply on news.ycombinator.com