search

nim-lang / Nim

Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
https://nim-lang.org
Other
16.61k stars 1.47k forks source link

Subrange definition with ..< #6788

Closed Adrien79 closed 6 years ago

Adrien79 commented 6 years ago

I'm surprised that this fails to compile:

const size = 6
type A = range[0..<size]

and I have to type this instead:

const size = 6
type A = range[0..(size - 1)]

I thought it would be the same.

Araq commented 6 years ago

This is suprisingly difficult to support in the compiler, but I improved the error message.

bluenote10 commented 6 years ago

@Adrien79 Note that you can also minimize the syntactical overhead by using range[0..size.pred].

kaushalmodi commented 6 years ago

@Adrien79 From issue #6216, I have learned that it's always best to put a space before and after the .. operator. So this works:

const size = 6
type A = range[0 .. <size]
Araq commented 6 years ago

@kaushalmodi That's not true, .. < is in fact deprecated.

kaushalmodi commented 6 years ago

@Araq Ah! I wasn't aware.. need to update my notes.. So as @bluenote10 says, should we instead always do [0 .. str.pred] instead of [0 .. <str.high]?

OK.. [0 .. str.pred] does not work. So I am missing out on something.. So if I have:

var str = "abc"
echo str[0 .. <str.high]

what's the new way of writing the same (as of the latest devel version, the above works)?

kaushalmodi commented 6 years ago

@Araq OK, I found the commit https://github.com/nim-lang/Nim/commit/70ea45cdbaa9d26a7196ab2718f60c9ca77e2d12

So I believe, following the convention of:

var str = "abc"
echo str[0 .. str.high]

It would be preferred to do the below (space before and after ..<)?

var str = "abc"
echo str[0 ..< str.high]

Just that now ..< is treated as a single binary operator, just as ... Is that correct?

Update: Updated my notes.

Araq commented 6 years ago

It would be preferred to do the below (space before and after ..<)?

The jury is still out on this matter, but I would say, yes, that is the way to do the formatting.

Just that now ..< is treated as a single binary operator, just as ... Is that correct?

Yes.

dom96 commented 6 years ago

Unfortunately my book uses 0 .. <len(x) everywhere :\

kaushalmodi commented 6 years ago

@dom96 Yeah, I noticed that immediately after I fixed my post. :(

dom96 commented 6 years ago

We'll just have to keep it deprecated post-v1 I guess

kaushalmodi commented 6 years ago

@dom96 Don't mean to ruin this thread with off-topic question.. but do you plan to release digital copies of your book with fixes for such deprecated syntax? Does MEAP support providing PDF/ebook updates to folks to bought stuff from them?

dom96 commented 6 years ago

I don't think I will do that. Fixes should go into a "second edition", making small incremental changes to the ebook would make it diverge from the printed copy. Maybe that would be fine, to be honest I'm not sure, would need to ask Manning and see how they feel about it.

kaushalmodi commented 6 years ago

making small incremental changes to the ebook would make it diverge from the printed copy

Isn't that the benefit of an ebook that it can always stay up to date? I remember the days in school where I would take my printed textbook, open a pdf of its errata and manually fix all the typos and errors in the book. With ebooks, the book owner cannot do those errata fixes manually, but the author can :)

I hope Manning and you are fine and willing to keep the ebook/pdf versions up to date. Thanks!

dom96 commented 6 years ago

I will do my best to do that. Current plan is for the book to work with v1 though, so changes shouldn't be critical :)