Re: Nim syntax Quiz
not cool compiler message: [https://imgur.com/a/AcANV](https://imgur.com/a/AcANV) it'd be way better: "not nil only applies to ref types" maybe we should have a pinned threads about those.
Re: Nim syntax Quiz
Some musings; Beware, I edited title and original post to better reflect the point of the thread. \-- When I first installed Nim 0.13, I accepted that there will be "wtf-moments" because I knew that it is work-in-progress. When press release of 1.0 will eventually hit the fan, I surely hope there will be flocks of people installing Nim just to try it out - just for the evening, for a work day or a weekend. But the same amount of tolerance may not be expected then. That's why I think progress toward better error messages is very important just now. \-- Steep entry slope may have been also a blessing so far in the sense that forums are not flooded with us beginners, newbies, novices, newcomers, noobies and whatnot, but it's not a long-term strategy. As long as Nim syntax and libraries keep changing, it's also good that www has not been filled with outdated solutions. Modern programming is much about first finding code and libraries from web and then spending X hours getting the versions and dependencies right. Rosetta code was indispensable for me when learning (and of) Nim - when 1.0 comes out, make sure that code there is up-to-date. \-- Sorry about the pathos, I just tried to conjure the exasperation of a Nim beginner (whose voice may be underrepresented on these forums). It's a privilege that even beginners get answered by core devs, but I don't expect this to last forever. Hard to imagine Linus reading some beginner forums, let alone answering, and if he did, I wouldn't mind the tone.
Re: Nim syntax Quiz
I may be weird, but I find the above error message perfectly clear. Let me show how to read it. It says it has various overloads for `[]=`, I don't care for their type, but they all seem to take a `t`, a `key` and a `val`. Now the type mismatch happens between the provided values, which the compiler says have the following types * `t` -> `Table[comp.XchgSym, system.int]` * `key` -> `tuple[xchg: string, sym: string]` * `val` -> `RetTofTryInsert` A rapid comparison shows that `RetTofTryInsert` is the wrong type here. Unlike with some syntax errors, which may sometimes be unclear, when the compiler gives a type error, it usually tells you everything you need to know to figure out your issue.
Re: Nim syntax Quiz
Hey I have another good one in the category "ignore the compiler and just go
back to the code".
import db_mysql, tables
type XchgSym = tuple[xchg: string, sym: string]
var xchg_symbol2id = initTable[XchgSym, int]()
# real code:
#let id = db.tryInsertId(sql(qs), m.xchg, m.sym)
# simulation of the result for a stateless environment:
type RetTofTryInsert = type(tryInsertId(open("", "", "", ""), sql""))
let id: RetTofTryInsert = 1
xchg_symbol2id[(xchg:"", sym:"")] = id
change the last line to:
xchg_symbol2id[(xchg:"", sym:"")] = int(id)
and now it builds.
the compiler output is unhelpful:
comp.nim(11, 15) Error: type mismatch: got (Table[comp.XchgSym,
system.int], tuple[xchg: string, sym: string], RetTofTryInsert)
but expected one of:
proc `[]=`(s: var string; x: Slice[int]; b: string)
proc `[]=`[T](s: var seq[T]; x: Slice[int]; b: openArray[T])
proc `[]=`[I: Ordinal; T, S](a: T; i: I; x: S)
proc `[]=`[Idx, T](a: var array[Idx, T]; x: Slice[Idx]; b: openArray[T])
proc `[]=`[Idx, T](a: var array[Idx, T]; x: Slice[int]; b: openArray[T])
proc `[]=`[A](t: var CountTable[A]; key: A; val: int)
proc `[]=`[A](t: CountTableRef[A]; key: A; val: int)
proc `[]=`[A, B](t: TableRef[A, B]; key: A; val: B)
proc `[]=`[A, B](t: var Table[A, B]; key: A; val: B)
proc `[]=`[A, B](t: OrderedTableRef[A, B]; key: A; val: B)
proc `[]=`[A, B](t: var OrderedTable[A, B]; key: A; val: B)
Because the type it expects, is in fact not listed here. otherwise we'd have my
tuple showing up.
The red tilda in VS code (and the column number in the compiler output) points
to the first [ bracket of the key.
The only clue that got me to save the day, was that it was not showing
RetTofTryInsert but i64, (I introduced RetTofTryInsert just for the sake of the
argument). In fact the problem was on the other side of the assignment. Because
it's NOT an assignment, it's an []= operator and that is very surprising. I
have no i64 in my types, so changing to int was the fix.
Re: Nim syntax Quiz
Unfair quoting IMO, I said > Or better yet, you ask a beginner who can read a tutorial again to look at > some valid syntax. **I 'm not a fan of pathos.** A friendlier tone would have produced a friendlier answer. But I'm changing this to "just always be nice anyway", trying to listen to complaints. Independent of the tone I tried my best to improve the situation. > Because that's what we do, we copy paste a compiler's complaint in google and > see if we're not faced with a common mistake, that is solved by checking the > first answer on SO as first result in the google response. I've been out of > misery in 10 seconds like that for lots of things. Never with nim. "Nim is not Google friendly" is definitely Nim's problem number one for learners, agreed.
Re: Nim syntax Quiz
I'm also a beginner and I'm also exasperated by error messages just like you. Let's take C#, it's a language that was designed on purpose to be beginner friendly, and the compiler outputs messages that are incredible and spot on. This makes it frustration-free, and that's one key to adoption. nim has a steep entry slope, I'm climbing it slowly but it's not without frequent requestioning "should I just scrap my proto and move to C# and redo it all in 2 days ?" @Araq your attitude doesn't help with this feeling I'm afraid :'( you often are rough with your tone, and stuff like "a beginner who can read a tutorial again" that's... hmm Ok, so the last way too long-lasting head scratching I had (I'll start collecting them like you @Allin lol) was when using ".items" and ".keys" iterators, it gives out weird errors about fields. I mentioned it in this SO question [https://stackoverflow.com/q/49407160/893406](https://stackoverflow.com/q/49407160/893406). I'm trying to flood SO with everything I can ask that meets the SO standards. Because right now, google returns few useful stuff for common beginners queries, or the compiler's error messages Because that's what we do, we copy paste a compiler's complaint in google and see if we're not faced with a common mistake, that is solved by checking the first answer on SO as first result in the google response. I've been out of misery in 10 seconds like that for lots of things. Never with nim. I hope this improves.
Re: Nim syntax Quiz
"Error: Not all cases are covered" when you have one ')' too much? "Invalid indentation" when you have one ')' too much? Your "quiz" has quite some potential still.
Re: Nim syntax Quiz
On behalf of future Nim beginners I say that is a great reply to my rants. Correct and helpful feedback from compiler is even more important than correct and helpful feedback from community. When next version comes out, I'll check if there's room left for another syntax (error) "quiz".
Re: Nim syntax Quiz
The only remaining issue is `var myTuple: MyTuple = [a: 10, b: 10]` which is hard to fix. All the others have better error messages now.
Re: Nim syntax Quiz
Ok, correct answer to the quiz is: 8
You'll find the corrected code below.
As any decent quiz should, one trick question was included: although "
_inheritance only works with non-final objects_ " is reported as syntax error,
there's no syntax error at that line; _MyObject_ just should have been declared
as " _of RootObj_ ".
type MyTuple = tuple[a: int, b: int]
var myTuple: MyTuple = (a: 10, b: 10)
type MyObject = ref object of RootObj
a: int
var myObject: MyObject = MyObject(a: 5)
type MySpecialObject = ref object of MyObject
var seqOfStrings: seq[int] = @[]
proc silentProc*() = discard
proc inc(a: var int) = a += 1
Btw1. This discussion is also relevant:
[https://forum.nim-lang.org/t/3647](https://forum.nim-lang.org/t/3647) It's a
fact that when the parser gets carried away, it may state some irrelevant line
as the source of your error. (Due to what StasB stated above).
Again, use the error message line number as a hint, not as a fact.
Btw2. Below is an example of a program that produces - while being a
pedantically correct error message - quite scary output for a newcomer. A
friendlier (and admittedly unrealistic to achieve) alternative would be
something like: _The & operator concatenates two strings, but the procedure
debug does not return a string. Did you mean: debug("foo" & "bar")_
import logging
debug("foo") & "bar"
The lesson to be learned: Just take nim error messages with a grain of salt (at
least until Nim 1.x). After all, nim is more programmer-friendly language than
it's error messages might first suggest.
Re: Nim syntax Quiz
`nimsuggest` doesn't help?
Re: Nim syntax Quiz
I think what it boils down to is that syntactic flexibility and good error messages are at odds, simply because the parser can keep going quite a long way past the point where it's already clear from the context that the result will be semantically invalid, as long as the code happens to be syntactically valid. The further it gets from the root cause, the more baffling an error message you will get.
Re: Nim syntax Quiz
To drive my point home, I shall now reveal what the compiler tells the errors are. And boy, they are bogus. type MyTuple = tuple(a: int, b: int) # syntax...Error: invalid indentation var myTuple: MyTuple = [a: 10, b: 10] # syntax...Error: invalid indentation type MyObject = ref Object a: int # syntax...Error: undeclared identifier: 'a' var myObject: MyObject = MyObject(a = 5) # syntax...Error: invalid expression: 'a = 5' type MySpecialObject = ref object of MyObject # syntax...Error: inheritance only works with non-final objects var seqOfStrings: seq[int] = @[int] # syntax...Error: internal error: expr(skType); unknown symbol proc silentProc()* = discard # syntax...Error: invalid indentation proc inc(var a: int) = a += 1 # syntax...Error: ')' expected The issue comes down to 3 problems for a nim novice: * How can he trust the compiler (in production) when he cannot trust the compiler error messages * What's the use of top quality documentation when the compiler tells him to search for the solution at wrong place * How can he not be scared when a simple error triggers the compiler to produce something like core dump (no example on this behaviour above) Because there is no 1:1 correspondence between syntax errors and their semantic consequences, this cannot be simply fixed by search/replacing existing error messages. This also should/could not be fixed by complicating the parser (but tinkering nimsuggest might be ok, I guess), because looking at the larger context is not it's job. That's why I proposed a separate " _common syntax error pattern detection tool_ ". I agree that this not something that the core devs should be doing at the moment, but this would be a nice project for some wannabe core dev out there. (And, eventually, a _quickfix on|off_ compiler switch would be nice). Fortunately detecting all random permutations is not necessary; I believe that giving valid quick fix suggestions for the most common 20 syntax errors would keep 80% of the beginners happy. Let me propose a simple short term fix: When the error message is not to be trusted, add a question mark to the error message. Instead of stately asserting "Invalid intendation", the compiler should politely suggest: "Invalid indentation?". This would save our beginner from spending his evening trying to fix the error by prefixing/removing leading whitespace (been there, done that). > But if you do find a crash please at least make sure you report it on GitHub. Did that. Yesterday my first forum post, today my first issue, tomorrow the world? When it comes to nim, I guess I'm now all in. > the compiler's error message are constantly improving True. To be honest, most of my beginner syntax errors I have collected long ago produce valid error messages now as of 0.18. For example, one of my pain points was confusing the usage of : and = operators. That the compiler now gives relevant feedback on this confusion is to be highly appreciated by nim beginners. **Quiz 4** , strictly off-topic: try to guess the output for x in [0..100]: echo x
Re: Nim syntax Quiz
> Quiz 2: Now, imagine that you are a nim newbie. Try to fix the errors with > the help of nim manual and compiler error messages. Or,better yet, ask a nim > beginner to fix the code and watch the frustration grow. Or better yet, you ask a beginner who can read a tutorial again to look at some valid syntax. I'm not a fan of pathos. > The errors in the code were not invented by hand, they are real mistakes I > admit I have made when learning to nim. Therefore I expect that other > beginners will make the same mistakes. The point is that the compiler error > messages for these examples are not only unhelpful, they are misleading - if > you blindly follow them, you'll end up with even more confusion. A compiler is not some interactive programming language teacher. That's certainly where the future is heading, but currently that is not what a compiler is. The compiler's error messages are about pointing out errors. Not about guessing what the beginner might have meant instead. For example, in `[a: 10, b: 10]` that is a valid array construction, but `a` is an undeclared identifier. The compiler doesn't look at the larger context to see that you use the wrong syntax for tuple creation. Having said that, the compiler's error message are constantly improving. "Imagine somebody trying all sort of token permutations to create tuples" wasn't on my radar, but probably for the next version we can improve some of these error messages.
Re: Nim syntax Quiz
I guessed `var a: int`, but it turned out to be `@[int]`, which is the mistake I thought I'd least likely make
Re: Nim syntax Quiz
The error messages improvements is something that is easy to contribute to Nim compiler codebase. Pull Requests are welcome.
Re: Nim syntax Quiz
> Bonus Question: One of lines crashes the compiler (as of 0.18). Can you > detect it? My bet is `var myObject: MyObject = MyObject(a = 5)`, although it could actually be a lot of the lines. You have covered different permutations of invalid code quite well. > I see development of better syntax error messages as one of the high priority > tasks in order to make nim more beginner-friendly. I'm namely worried that > scary and misleading error messages will intimidate some newbies away from > nim before they start to see the light. I totally agree. But I don't think there is a high chance of serious effort being put into it before 1.0 is released. I hope to push a serious documentation and usability improvement initiative once 1.0 is released, it will be one of the major things that we will work on in versions post-1.0. Some things are easier to fix than others of course. Crashes in particular should be relatively easy to fix. Making errors better is a bit more involved. But if you do find a crash please at least make sure you report it on GitHub. > Do you know other "easily made" syntax errors that produce misleading error > messages? Help nim newbies by publishing your cautionary example here (or > somewhere). I don't off the top of my head. But thank you asking people to share theirs. It's easy for us to become accustomed to writing code in always the same way, and we don't have the time to fuzz the compiler to find strange crashes when code is written incorrectly. We definitely rely on newcomers to report these issues so we can fix them.
