summary refs log tree commit diff stats
path: root/tests/nimdoc/trunnableexamples.nim
Commit message (Collapse)AuthorAgeFilesLines
* clean up SOME pending/xxx/issue link comments (#21826)metagn2023-05-111-7/+6
| | | | | * clean up SOME pending/xxx/issue link comments * great
* runnableExamples imports std/assertions by default (#21658)metagn2023-04-141-0/+4
| | | closes https://github.com/nim-lang/RFCs/issues/499
* fixes #19795; fixes #11852; fixes #19974; remove parsing pipeline, Nim now ↵ringabout2023-02-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parses the whole module at one time (#21379) * fixes #19795; remove parse pipeline * isScript * fixes nimscriptapi * don't touch reorder * check script * fixes tests * it seems implicit imports of system cause troubles * access the first child of `nkStmtList` * ignore comments * minor messages * perhaps increases hloLoopDetector * the module is a stmtList, which changes the errors * fixes nimdoc * fixes tlinter * fixes nim secret tests * fixes arc_misc * fixes nim secret tests again * safe; fixes one more test * GlobalError is the root cause too * fixes parsing errors * put emit types to the cfsForwardTypes section * fixes #11852; `{.push checks:off}` now works in procs * disable navigator * fixes nimdoc * add tests for JS * fixes nimsuggest
* fix #19580; add warning for bare except: clause (#21099)ringabout2022-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | * fix #19580; add warning for bare except: clause * fixes some easy ones * Update doc/manual.md * fixes docs * Update changelog.md * addition * Apply suggestions from code review Co-authored-by: Jacek Sieka <arnetheduck@gmail.com> * Update doc/tut2.md Co-authored-by: Jacek Sieka <arnetheduck@gmail.com>
* fix #16993, #18054, #17835 runnableExamples now works with templates and ↵Timothee Cour2021-06-021-2/+55
| | | | nested templates (#18082)
* typo: nonexistant => nonexistent (#17918)Timothee Cour2021-05-021-2/+2
| | | | | * typo: nonexistant => nonexistent * fix test (ordering differs because of https://github.com/nim-lang/Nim/issues/17910)
* fix #13491 #17279 runnableExamples now don't get lost in translation (#17282)Timothee Cour2021-03-091-0/+25
| | | | | * fix #13491 runnableExamples rendering * fix a runnableExamples thanks to this bugfix
* fix code-block test bugs: fix #17183, fix ↵Timothee Cour2021-02-261-0/+10
| | | | | | | https://github.com/timotheecour/Nim/issues/620 (#17184) * fix code-block test bugs: fix #17183, fix https://github.com/timotheecour/Nim/issues/620 * cleanup
* fix bug in semgnrc: runnableExamples should not semcheck, even with > 1 arg ↵Timothee Cour2020-06-231-0/+10
| | | | (#14768)
* fix #10731 ; `runnableExamples "-b:cpp --run:off": code` works (#14384)Timothee Cour2020-05-201-1/+34
| | | | * runnableExamples "-b:cpp -r:off": code
* close #12746; minor cleanup (#14379)Timothee Cour2020-05-171-0/+79
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-07-26 02:23:11 +0000
; <P>The three big ideas in this part are <EM>effect, sequence,</EM> and <EM>state.</EM> <P>Until now, we've been doing functional programming, where the focus is on functions and their return values. Invoking a function is like asking a question: "What's two plus two?" In this part of the book we're going to talk about giving commands to the computer as well as asking it questions. That is, we'll invoke procedures that tell Scheme to <EM>do</EM> something, such as <CODE>wash-the-dishes</CODE>. (Unfortunately, the Scheme standard leaves out this primitive.) Instead of merely computing a value, such a procedure has an <EM>effect,</EM> an action that changes something. <P>Once we're thinking about actions, it's very natural to consider a <EM>sequence</EM> of actions. First cooking dinner, then eating, and then washing the dishes is one sequence. First eating, then washing the dishes, and then cooking is a much less sensible sequence. <P>Although these ideas of sequence and effect are coming near the end of our book, they're the ideas with which almost every introduction to programming begins. Most books compare a program to a recipe or a sequence of instructions, along the lines of <PRE> to go-to-work get-dressed eat-breakfast catch-the-bus </PRE> <P>This sequential programming style is simple and natural, and it does a good job of modeling computations in which the problem concerns a sequence of events. If you're writing an airline reservation system, a sequential program with <CODE>reserve-seat</CODE> and <CODE>issue-ticket</CODE> commands makes sense. But if you want to know the acronym of a phrase, that's not inherently sequential, and a question-asking approach is best. <P>Some actions that Scheme can take affect the "outside" world, such as printing something on the computer screen. But Scheme can also carry out internal actions, invisible outside the computer, but changing the environment in which Scheme itself carries out computations. Defining a new variable with <CODE>define</CODE> is an example; before the definition, Scheme wouldn't understand what that name means, but once the definition has been made, the name can be used in evaluating later expressions. Scheme's knowledge about the leftover effects of past computations is called its <EM>state.</EM> The third big idea in this part of the book is that we can write programs that maintain state information and use it to determine their results. <P>Like sequence, the notion of state contradicts functional programming. Earlier in the book, we emphasized that every time a function is invoked with the same arguments, it must return the same value. But a procedure whose returned value depends on state--on the past history of the computation--might return a different value on each invocation, even with identical arguments. <P>We'll explore several situations in which effects, sequence, and state are useful: <UL> <LI>Interactive, question-and-answer programs that involve keyboard input while the computation is in progress; <LI>Programs that must read and write long-term data file storage; <LI>Computations that <EM>model</EM> an actual sequence of events in time and use the state of the program to model information about the state of the simulated events. </UL> <P>After introducing Scheme's mechanisms for sequential programming, we'll use those mechanisms to implement versions of two commonly used types of business computer applications, a spreadsheet and a database program. <P><A HREF="simply-toc.html">(back to Table of Contents)</A> </BODY> </HTML>