A constant reference/alias or pointer jut like as it is of C++ parameter

In Nim, `const int` is a compile time error. But it's OK to import from C. type ConstInt {.importc: "const NI".} = int ConstCInt {.importc: "const int".} = cint Run They can be used for parameters or pointers. var p: ptr ConstCInt #is translated

Can Nim be made more "purely functional""...

@Araq: > import compiler / ast.nim, produce an AST, use renderer.nim to produce source > code or use the rest of Nim's compilation pipeline. Thank you very much for that, as it would seem to be useful for any language that wanted to use Nim for its back end; it would also be useful if I decided

NimForum 2.2.0 - Fixes a big CVE!

I would like to add my thoughts about my experience in contributing to the forum. Overall, I really liked adding features and would have liked to add much more, including much of the basic functionality that is missing mentioned in this thread. However, the review process was very very slow and

Can Nim be made more "purely functional""...

> tail recursions with lots of accumulator parameters is procedural programming > in denial Pithy! :)

import from url

> would you like to see them in Nim? i just answered the question

NimForum 2.2.0 - Fixes a big CVE!

why cant we delete our messages still?

NimForum 2.2.0 - Fixes a big CVE!

> Pretty sure that's a Karax bug, fix welcome :) Also, classic.

import from url

The way you dismissed the idea sounded rude. If you have constructive criticism, it's better to express it like: “I don't think this is a good idea because…”

Stumped! Extending futures with addition context info

>From this code it does: # Background: # - Test harness to check out how to extend a httpclient future to include # additional context information (in this case the source url which could be # usefull in reporting failures) import std/[asyncdispatch, httpclie

import from url

> Did I hurt your feelings? If yes, I'm very sorry for them. what?

Nim devroom at FOSDEM this weekend

Try both `webm` and `mp4`, `webm` worked for me.

import from url

This feels like unnecessarily combining dependencies and code. If I use the same package in multiple files, and I want to update it, would I have to go through each file to do so? It just clutters up the top of my code and scatters dependencies everywhere. Perhaps this is only useful in one-off

import from url

Did I hurt your feelings? If yes, I'm very sorry for them. Anyway... > But without a "safe by default" runtime, like Deno, there's no much sense > doing it, too dangerous... This is legitimate concern, but the same can be said about installing via Nimble. Or npm.

A constant reference/alias or pointer jut like as it is of C++ parameter

I just know that Nim can't be as C++ way so do we think the alias one would work, how'd it actually happen runtime error ?

error C2440: '=': cannot convert from 'const char *' to 'NCSTRING'

Try: result = $cast[cstring](cresult) Run

Can Nim be made more "purely functional""...

> Back to the major topic: For "better FP" to emerge inside Nim you need more > restrictions to the mutability aspects but the solution IMHO is not "more > immutability", it's "single owner mutability". Immutability simply throws > away too many good things, I cannot imagine what an "immutable"

import from url

Really like it for Deno, it's basically an command line browser, you can execute any program from the web, by just typing its address, like opening a site. And totally safe (unless you get used to typing such kind of commands in terminal, and some day accidentally type something wrong). But wit

Can Nim be made more "purely functional""...

> But please don't invent yet another FP language. We have enough of these > already and they are all pretty bad. Haven't followed the rest of the discussion but just read this and wanted to chime in. It's such a broad and odd statement. There are many functional languages, but not more than im

Can Nim be made more "purely functional""...

Import `compiler / ast.nim`, produce an AST, use `renderer.nim` to produce source code or use the rest of Nim's compilation pipeline. But please don't invent yet another FP language. We have enough of these already and they are all pretty bad. Recursions easily introduce performance problems an

import from url

Or her ...

import from url

You gotta tell him nicely...

NimForum 2.2.0 - Fixes a big CVE!

We can probably render these as raw rst, I implemented this quickly as the new rst parser was failing to render a particular quirk of how some people write their posts. But it's easily fixable by the mods by just editing the post, so feel free to report these if you see them.

A constant reference/alias or pointer jut like as it is of C++ parameter

`const` is a keyword in Nim. So we can't simply define: type ConstInt = const int #error Run But we can import it. When translated into C, Nim int is defined as `NI`, so we can import `const NI`. type ConstInt {.importc: "const NI".} = int Run After

Can Nim be made more "purely functional""...

@Araq: > Sure, plenty of people disagree with me. That doesn't worry me and it's good > that plenty of experiments are done. Sure, let's agree to disagree ;-)... > Back to the major topic: For "better FP" to emerge inside Nim you need more > restrictions to the mutability aspects but the solut