Re: Loop backward through array -- howto do it brachless
To mitigate negative numbers you need to add the length of the array: `i = ((i - 1) + 4) mod 4` leaving you with: `i = (i + 3) mod 4`
Re: Compiled with 0.18, not with 0.19
I wasn't being critical of your answer; please understand that. You were giving me the reason why I was having the experience I was, which was helpful. Perhaps I could have said it better, but my response was intended to convey that I feel this is a design error, an inconsistency in the language, a special case, that users have to remember. To me, the best languages are the ones with the fewest special cases. My canonical example is Scheme. I wish there were something statically typed that was as good.
Re: Loop backward through array -- howto do it brachless
`for i in 1..12: echo -i and 3 ` Run
Loop backward through array -- howto do it brachless
Assume we have an array with index 0 to 3, we want to print elements in a never ending loop. Start index is i. Looping forward is of course i = (i + 1) mod 4 #print element[i] Run I have no idea to do it branchless in backward order currently, this is wrong of course: i = (i - 1) mod 4 #print element[i] Run Should be easy I guess, but no idea currently :-(
Re: Drop RST and join the Markdown train?
Markdown and [HastyScribe]([https://h3rald.com/articles/hastyscribe/](https://h3rald.com/articles/hastyscribe/)) FTW!
Re: Compiled with 0.18, not with 0.19
> If one can assign 0 to an int8 variable, then I would argue that one should > be able to assign (0,"foo") to a (int8, string) variable. I consider too, it would be more intuitive and is something one can expect. My answer was only about documentation being consistent with current compiler behaviour.
Re: Compiled with 0.18, not with 0.19
> Because compiler doesn't treat it as a separate value, instead checks type > compatibility for the whole l-> value and r-value, i.e. of the type of the > variable (result) and the type of the value you assign to it, two > tuples. I understand that the compiler is doing the conversion in one case and not the other. That's obvious. What I question is whether it should be. If one can assign 0 to an int8 variable, then I would argue that one should be able to assign (0,"foo") to a (int8, string) variable. > For me it doesn't work with 0.18 either I just checked and you are right. The only thing that I can think of is that I have not been using Nim for the project I am working on and have only experimented with it sporadically. I may have changed the routine in question and then, without compiling it, went off to something else. While that's not consistent with how I usually work, it's the only explanation I can think of, because I know for certain that _a_ version of that file did compile with 0.18. I _thought_ it was this version, but apparently not. In any case, my mistake.
Re: Drop RST and join the Markdown train?
A few comments and questions from a newby. I started my project's documentation using markdown with pandoc. I couldn't get any of the TOC options I found to work correctly, so I had to write my own TOC generator. Then I noticed that nim supported rst with its doc and rst2html commands, so I painfully switched my doc files to that. At least that has a nice TOC generator - once you guess at the required directive. Since my main module html file as produced by doc needs to hyperlink to sections in another hand-written "user guide" file, I had to hack the rst notation and write an html modifier to translate section headings into the mangled labels produced by the nim command rst2html. So I have these questions: * How soon could an alternate docgen be available to produce nim module documentation? * Is that even likely? * Would this docgen reliably generate a TOC for nim modules? * Would this docgen generate (and use) an index file for easy hyperlink creation? I.e. like the --index:on feature currently in nim.
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
The problem is one thing is what you write here as Design in Theory, and other different is what happens in Practice in real life. Python also has this "Code on Comments", almost all IDE wont give you the features (highlight, lint, etc) on the code portion of the comments, basically they visually seen as flat comment inside IDE, even if in theory sounds like a great idea, in practice no one uses it, outside Python enthusiasts of it, Ive tried to used it, in the long run they always gets deleted, because "Pollutes the Comments/DocStrings". I think adding 1 line at bottom of the code with an `include examples` pointing to all the `runnableExamples` is tons more clean visually. You wont need to put the `runnableExample` inside the body of the `proc`. So basically you are killing the feature, making it useless in real life, I think worth having since you are not Forced to use it anyways.
Re: Compiled with 0.18, not with 0.19
> Changing it to 0'i8 fixes the problem (it's surprising to me that the type > suffixes are different from the types they denote). You can imitate it by `0.int8`, it's compile-time converted. > So that leaves me with the question of why the 0 literal as the first element > of the tuple was not converted to int8? Because compiler doesn't treat it as a separate value, instead checks type compatibility for the whole l-value and r-value, i.e. of the type of the variable (`result`) and the type of the value you assign to it, two tuples. The manual has an excelent section on [type relations](https://nim-lang.org/docs/manual.html#type-relations). Shortly: [Assignment compatibility](https://nim-lang.org/docs/manual.html#type-relations-assignment-compatibility) requires types be implicitly convertible (and missing there, equal types are assignment-compatible of coarse too). [isImplicitlyConvertible](https://nim-lang.org/docs/manual.html#type-relations-convertible-relation) says about number conversions, nothing about tuples. So, by the manual, they should not be implicitly converted. Even not explicitly (the next code block).
Re: Drop RST and join the Markdown train?
Another voice for Markdown on the forum.
Re: Drop RST and join the Markdown train?
[https://hackmd.io/features](https://hackmd.io/features) is a great document to explore what people have managed to do with markdown. Likewise, it's hard to say bad things about how the rust documentation turns out in practice: [https://doc.rust-lang.org/std/result/index.html](https://doc.rust-lang.org/std/result/index.html) \- it's all markdown-based, checked by the compiler, directly runnable in the browser etc etc.
Re: Compiled with 0.18, not with 0.19
@LeuGim Thanks -- you got me focused on the first element of the tuple when I thought the issue was the second (the compiler message is ambiguous, since both types are different in the 'got' and 'expected' parts of the message). I checked the language manual and the section on "Numerical constants" says "Literals without a type suffix are of an integer type, unless the literal contains a dot or E|e in which case it is of type float.". So the 0 I wrote is of type 'int'. Changing it to 0'i8 fixes the problem (it's surprising to me that the type suffixes are different from the types they denote). But changing this to let zero:int8 = 0 return (zero, @[]) Run also works (compiles without error). Which led me to the manual section on Pre-defined integer types: [https://nim-lang.org/docs/manual.html#statements-and-expressions-type-conversions](https://nim-lang.org/docs/manual.html#statements-and-expressions-type-conversions) This says that only widening conversions are implicit (and then in the immediately following table of examples, it says that myInt16 + 34 # of type ``int16`` Run ; I don't understand this; 34 is of type int, which is wider than int16, so why isn't the type of this expression int?) But it then goes on to say that narrowing conversions are 'implicit' under certain circumstances, which are met by my case, as demonstrated by the assignment of 0 to zero (which narrows an int to an int8). So that leaves me with the question of why the 0 literal as the first element of the tuple was not converted to int8? As was apparently the case with the previous version of the compiler?
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
I like the runnableExamples. It's a great feature that probably no other language has. > I wish Araq had chosen markdown instead RST, but that ship has sailed. I so wish that Markdown was picked instead too. RST is crazily limitations like not allowing nesting of bold inside italics and such. The Pandoc Markdown flavor is very mature and allows all kinds of structural syntax.
Re: Drop RST and join the Markdown train?
Supporting admonitions is easy. Pandoc style Markdown classes can do that. I also believe that's being added to the CommonMark spec.
Re: Overloading string representation for objects
Works perfectly, thanks. I had the impression I had tried exactly that but I must have made a mistake somewhere.
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
> 3\. The big difference between RST and Markdown is that the former is > structured If markdown is transformed into clean HTML5 with presentation aspects separated out into a style sheet, the HTML DOM might even be structured enough for documentation processing purposes.
Re: runnableExample considered harmful / good feature to deprecate before 1.0?
`runnableExample` is a bad idea and should die, here's why: 1\. It breaks separation of concerns. Code defines what a program does, comment gives information about that code. Two different concerns. Blurring the line by placing sample code for documentation purposes outside of a block comment and inside the actual code is therefore bad. It confuses people who are used to SOC and puts the compiler in a strange position: there's a standard lib proc which the compiler is supposed to ignore, but another entity (the doc generator) knows about. This makes `runnableExample` a unique case AFAIK, have fun explaining this to other tools / IDE code instrumentation. 2\. Comment has a higher semantic level than code, it is meta-information ABOUT code. Tools for a lower semantic level like the compiler should have to know as little as possible about higher semantic levels. Good old "ignore stuff that looks like a comment, everything else is for you" is a simple and proven rule for a compiler. We had "magical comments" that actually influence the compilation process in older languages, but this flaming nonsense with wings from hell has been abandoned in favor of annotations, Nim pragmas etc. for good reason. 3\. Nobody else does that. All other modern languages I know of keep sample code inside block comments. There may be other reasons for that than those given in this post.
Re: Drop RST and join the Markdown train?
With something like [https://python-markdown.github.io/extensions](https://python-markdown.github.io/extensions), class/id and other attributes could be defined for text entities. This could provide everything from formatting (e.g. admonitions) to functional annotations (like test compilation of example code in comments). The latter could also be achieved with fenced code blocks from Github Flavored Markup: the standard only uses the first word after the ``` for language detection, the rest of the string is permitted but unused and could be used for code block annotations.
