I wonder if a std/units should exist too, for basic unit ops without converting twice to/from int/float, kinda 1.Hours + 55.Minutes or $(42.Microseconds) etc

https://github.com/SciNim/Unchained

I'm obviously a fan of this, but not sure if it should be a standard library feature to be honest.

that'd require a separate RFC

Do it.

For Vim you don't need any plugins, it has this built-in.

:help digraphs
:help i_ctrl-k

I wonder if a std/units should exist too,

I've implemented std/units in a private branch, see https://github.com/timotheecour/Nim/issues/760 which allows user defined units as distinct float and automatically computes arbitrary powers from those in expressions, eg:

runnableExamples:
  type
    Length = "m".makeUnit # can be also defined from other powers of other units
    Time = "s".makeUnit
    Mass = "kg".makeUnit
  assert $(Time(1.2)/Length(3.2)*Mass(5.4)*Mass(5.4)) == "10.935's*1/m*kg²"

but that'd require a separate RFC and isn't needed for this RFC (in particular, durations should be integral, not FP, whereas units are more useful as FP in most applications)

for basic unit ops without converting twice to/from int/float,

what do you mean twice? the conversion should be 1-way and propagated throughout stdlib until the point where it's consumed by final OS call into the unit it needs; the goal would be to only consume Duration through and through.

The only problem I'm facing to implement this is that I'm not sure the implementation of Duration is the right one, as it uses this:

type Duration* = object
  seconds: int64
  nanosecond: range[0..999_999_999]

which doesn't lend itself for efficient operations.

So I'm instead considering introducing a different type to represent durations that doesn't incur performance penalty, eg:

# in system:
type int128* {.magic: Int128.}
  # in C backend, uses `__int128` if `#ifdef __SIZEOF_INT128__` is defined,
  #   else falls back to software emulation as implemented in compiler/int128.nim
  # in VM, uses compiler/int128.nim
  # in js, uses jsbigints or a wrapper around it if we care about preserving bounds checking
  type Int128* {.importc: "__int128", nodecl.}

# in std/durations:
type TimeUnit* = distinct int128

The name can be bikeshedded, eg: Nanoseconds, Timespan, Dur etc...

The alternative would be to use int64 but it can "only" represent ranges +- 292 years in nanoseconds, which can be a problem if doing math involving calendar year (eg 2021) + offset operations.

@konsumlamm , @HugoGranstrom ,

There is at least 2 types of Latex-inspired input methods:

• Various editor plugins for Vscode, Vim, Emacs and other editors. One can also install Julia plugin for all those editors, it works for non-Julia files also!
• Use OS input methods
  • For Windows you can use https://github.com/clarkgrubb/latex-input#windows-install. I've just checked it, it works. It's claimed to work for Mac OS X also (i did not check)
  • For Linux there is ibus-table-latex already in repositories, it's always working for me: \otimes → ⊗. There is also similar fcitx-table-latex

Usually you just start typing sequence \ot and then press space or tab and the symbol is input!

Memoization for functions should be in stdlib.

Basic Memoization is relevant in a function oriented lang like Nim.

Does not have to be the fastest in the world, an average memoization is still better than no memoization, can start with a Table-based implementation or similar, can be a macro too.

Should take few lines (~500 lines at most), including a runnableExample.

Memoization should work for JavaScript targets too.

Can provide good performance improvements for very few lines.

Why not implement your own ?

Yes, users can implement a custom one, but then each lib author will do their own, then in a project with multiple libs the implementations will not be compatible, that kinda defeats the whole purpose of memoization, 9 caches instead of 1.

How is it done in other langs ?

• https://devdocs.io/python~3.9/library/functools#functools.lru_cache

I wonder if a std/units should exist too, for basic unit ops without converting twice to/from int/float, kinda 1.Hours + 55.Minutes or $(42.Microseconds) etc

Maybe this can become some kind of source code filter?

#? unicodeops
echo a ∧ (b ∨ c)
echo a ± b
echo a ⊗ b

var a, b, c: bool
echo `and`(a, `or`(b, c))
echo plusMinus(a, b)
echo kronecker(a, b)

Each operator would translate to a call to a name, so you don't have to define procs using the operators. I don't know if it's fine for the compiler to decide this operator-to-name table. It's also not really like the other source code filters in the changes it makes, so I don't know if it's the best fit.

a ⊗= b could also get translated to a = kronecker(a, b) instead of kroneckerAsgn(a, b), but I think it should just not be supported since it's not fully unicode. It could cause a lexer error on these operators, as well as ∧∨ and ∨+.

It exists as a package already; https://github.com/treeform/print, I don't think absorbing/obsoleting packages into the stdlib is healthy for the ecosystem at whole. We should simply ship a bunch of packages with the installation to give them exposure and use.

treeform/print could be a great addition to fusion?

a ∧ (b ∨ c) won't ever make it into Nim's stdlib/core for the simple reason that and / or are more readable and very special: They are control flow, in a or b the b is not evaluated if a is true. This means they are not the common logical operators.

I personally don't care if it goes into stdlib, but with regards to the special treatment / short circuiting you mention: Why would something like this not do it?

template `∧` (a, b: untyped): untyped =
  a and b

thoughts about unicode editor support: one option that comes to mind and which should be easy is replicating what Julia does i.e. expanding e.g. \pm to ± on tab or automatically. ultisnips for nvim comes to mind, or hypersnips for vscode - should be straightforward and useful for the mathy crowd which already knows latex.

I agree with @konsumlamm that there should be ascii alternatives offered by libraries for the base functions at least so that you could write code that performs the same tasks (although in slightly different ways) witg both the Unicode and ascii alternatives. For example the a ⊗= b is equivilent (although more efficient perhaps) to a = kronocker(a, b). So both kinds of users would be able to use the library.

A note on inputting unicode charcters on Windows. Several options like Windows + . and WinCompose hs been brought up that aren't too convoluted to use. Although I haven't checked whether they support all of the proposed symbols in the RFC.

IMO it's the opposite. If you offer ⊗, only offer ⊗, aliases are frequently more confusing and don't scale well. "Is there a difference between ⊗ and kronecker?" Now that we have ⊗= we also need kroneckerAsgn...

I disagree. Many people (including myself) wouldn't want to use unicode operators, simply because it's not easy to type. You either need some keyboard layout that supports unicode operators, or copy-paste them from the docs every time you wanna use them. So as a result, they probably just wouldn't use libraries that only provide unicode operators (without ASCII alternatives), which could be avoided very easily.

@beef331 This is true but completely unrelated to the enum situation. This RFC should be split up into different parts. This RFC should be called "Overloadable enum names"

No one ever said unsafeAddr was badly named in being exactly as safe as addr. Quantifying this is hard because it is NOT about examples of "how it works" as you seem above to think are somehow persuasive. Rather, you want software lifecycle examples where the complicating distinction prevented many programmers from making important mistakes instead of just reflexively changing addr to unsafeAddr, as @Araq explained in his opening comment. In short, since you aren't really even arguing from the same perspective, disagreement is unsurprising. The benefit was, again explicitly, language simplicity which it is true may be subjective not "tangible", but many/most benefits are!

It may clarify to discuss the opposite direction of this RFC which relates to this benefit. If unsafeAddr is helpful, ptrs remembering how they were created might be even more helpful, no? By default blocking writes to memory in some far removed part of the call stack from ptrs that came from unsafeAddr is "safer". This move opens up a whole "const correctness" can of worms {Nim gets a shout out in today's version! }. Do we go all the way, even past FFI boundaries for the C/C++ backends that have const pointers? How many programmers just cast away constness in const-correct languages? Should they? Maybe not. Would Nim programmers? This is the "same perspective playing field" upon which you should argue. It is admittedly quicksand.

Since it is very hard to assess all this objectively (or even systematically) people mostly argue by bald assertion. Here's one - it's already a very bad sign that long-time Nim users need to ask about the distinction. Maybe that happens because pointers are needed so rarely and keeping up that good work however/wherever & making it more rare rather than adding new ones is what matters in the end?

A couple of remarks:

a ∧ (b ∨ c) won't ever make it into Nim's stdlib/core for the simple reason that and / or are more readable and very special: They are control flow, in a or b the b is not evaluated if a is true. This means they are not the common logical operators.

Unicode based operators should be reserved for other math heavy packages and the stdlib should avoid them. At least for the first couple of years.

Libraries offering for example ⊗(x,y) but not kronecker(x,y). This should be discouraged

IMO it's the opposite. If you offer ⊗, only offer ⊗, aliases are frequently more confusing and don't scale well. "Is there a difference between ⊗ and kronecker?" Now that we have ⊗= we also need kroneckerAsgn...

Unicode support for infix operators

Abstract

Allow certain unicode characters to be used as infix operators akin to but more restricted than Julia allows it.

Motivation

Allows for beautiful linear algebra code, can be helpful in using code to show off algorithms in a Computer Science kind of setting, is a very much loved feature of Julia, etc. The initial idea for this came from https://forum.nim-lang.org/t/2968

Description

I propose to allow the following characters to be used as infix operators:

Parsed with the same precedence as +

± ⊕ ⊖ ⊞ ⊟ ∪ ∨ ⊔

Parsed with the same precedence as *

⋅ ∘ × ⊗ ⊘ ⊙ ⊛ ⊠ ⊡ ∩ ∧ ⊓ ∙ ⋆

which is a quite small subset taken from what Julia allows: cf. https://stackoverflow.com/a/60321302/4038300 Note: This RFC should not fail on the grounds of one character here. It's just my initial proposal, feel free argue why some characters should be additionally included or which ones to be omitted.

There should be no confusion about precedence here!

Potential downsides: Libraries offering for example ⊗(x,y) but not kronecker(x,y). This should be discouraged, as to not hinder people using a library just because they cannot easily type these unicode glyphs - it should always be optional, I guess we cannot enforce this but to put it in the docs / a style guide.

Examples

So for example consider the hadamard kronecker mixed-product property:

Before

doAssert hadamard(kronecker(A,B), kronecker(C,D)) == kronecker(hadamard(A,C), hadamard(B,D))

After

doAssert (A ⊗ B) ∘ (C ⊗ D) == (A ∘ C) ⊗ (B ∘ D)

Or for people that love the brevity of math notation for logic consider:

Before

let truth = a and (b or c)

After

let truth = a ∧ (b ∨ c)

Implementation

I am not a Nim contributor yet, but I imagine the implementation would be rather easy :)

Further thoughts?

This makes all code unreadable ??? No it does not. It is optional, we choose a subset of unicode characters that are distinguishable and whose precedence is obvious. Consider also in your argument against it that we have things like the %* macro already in json.nim

@Araq suggested adding additional unicode parentheses to Nim. It's probably wiser to make a separate RFC about that? In any case it is better, if he suggests which symbols he wants and his general thoughts on it, since its his idea! :)

I could imagine lots of cool mathy things to take life in the sugar.nim package or perhaps more wisely (?) a separate package, since sugar.nim also provides these pretty abbreviations for people that appreciate that.

Another place this could be useful is in expressions, take the following into consideration.

proc bar = discard

proc foo: proc() =
  result = proc() =
    discard

proc doSomething: proc() =
  case true:
  of true: bar
  of false: foo()

Presently this errors at of false: foo() due to it being a closure and bar not being one as the case statement is looking for proc(). Given the information that the expression needs to be a proc(){.closure.} the error would be moved to the correct line which is the of true: bar there is no converter or way for it to presently be turned into the correct return type.

I'm against this RFC, even if everyone else seems to think it's a good idea. addr is unsafe, in large part because it allows stack addresss escaping their stackframe. This is actually actually a solvable problem, which I solved in https://github.com/nim-lang/Nim/pull/14976 (see extensive tests).

But unsafeAddr is strictly less safe than addr, violating type safety guarantees in more severe ways (eg const-ness or even ROM).

example 1

nim r main

when true:
  let s = "abc".cstring
  # s[0].addr[] = 'x' # CT error
  s[0].unsafeAddr[] = 'x' # RT error: SIGBUS
  echo s

example 2

nim r -b:js main

when true:
  type Foo = object
    counter: int
  proc fn(a: Foo) =
    # let b = a.addr # CT error
    let b = a.unsafeAddr # RT error below in js: TypeError: Cannot read property 'counter' of undefined
    echo b[].counter
    echo a
  var f: Foo
  fn(f)

example 3

nim r main with addr, it'll give CT error with unsafeAddr, you'll get different values at CT vs RT: CT: prints 5 RT: prints 3

what worse, this depends on Foo.sizeof; eg with -d:case2a you'd get RT: prints 5 instead

when defined case2:
  type Foo = object
    counter: int
    when defined case2a:
      data: array[100, byte]
  proc fn(a: Foo) =
    # let b = a.addr # CT error
    let b = a.unsafeAddr
    b[].counter += 2
  proc main =
    var f = Foo(counter: 3)
    fn(f)
    echo f.counter
  static: main()
  main()

In practice, I think the distinction never found a bug, you use 'addr', the compiler complains, you use 'unsafeAddr' instead, "problem solved".

I just showed 3 simple examples above where addr would give CT error and unsafeAddr would give runtime errors or inconsistent results; each backend is affected, in different ways: c, js VM.

unsafeAddr is a useful escape hatch when you know what you're doing, but at least the compiler tells you you're in uncharted territory. If we started to conflate addr and unsafeAddr, you'd lose this distinction.

In summary, conflating addr and unsafeAddr doesn't fix any bugs or enable any new features, and it does make the langauge less safe.

Bumps postcss from 7.0.35 to 7.0.36. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/postcss/postcss/releases">postcss's releases</a>.</em></p> <blockquote> <h2>7.0.36</h2> <ul> <li>Backport ReDoS vulnerabilities from PostCSS 8.</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/postcss/postcss/blob/main/CHANGELOG.md">postcss's changelog</a>.</em></p> <blockquote> <h2>7.0.36</h2> <ul> <li>Backport ReDoS vulnerabilities from PostCSS 8.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/postcss/postcss/commit/67e3d7b3402c5d3d036ab7c1e781f86910d6ca72"><code>67e3d7b</code></a> Release 7.0.36 version</li> <li><a href="https://github.com/postcss/postcss/commit/54cbf3c4847eb0fb1501b9d2337465439e849734"><code>54cbf3c</code></a> Backport ReDoS vulnerabilities from PostCSS 8</li> <li>See full diff in <a href="https://github.com/postcss/postcss/compare/7.0.35...7.0.36">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

proposal 1

• add a type to represent a raw TLineInfo as used by the compiler (eg: NimLineInfo); unlike LineInfo it doesn't interpret the filename and just faithfully represents it; add macros.nimLineInfo API analog to macros.lineInfoObj to retrieve it from a NimNode

proposal 2

in macros, make proc error(msg: string; n: NimNode = nil) also accept NimLineInfo instead of just n; NimLineInfo can be used when the n is not available ditto with some other APIs eg warning

proposal 3

add proc callsiteNimLineInfo() which just retrieves the NimLineInfo instead of callsite which retrieves the full NimNode and requires copyTree

proposal 4 (independent of proposal 1, 2, 3)

add callTree which works exactly like the deprecated callsite except it requires the macro where it's called from to be annotated with a new pragma {.callTree.}, otherwise it gives an error

migrate existing calls to callsite to use the new callTree, and turn callsite into an error unless -d:nimLegacyCallsite is used; when -d:nimLegacyCallsite is not used, we can now avoid the expensive calls to copyTree in all places except ones that use {.callTree.}

note

callsite has its uses so outright removing it is not good, however the proposed callTree should address all concerns, in particular avoiding copyTree on each call except the few that are enabled via {.callTree.}

I just wanted to chime in and say that I've been really happy using the IntelliJ plugin that @piotrtomiak wrote, along with the CLion IDE. Indexing is fast, highlighting is flawless as best as I can tell, and completion/code navigation works well for simple cases. There's plenty that it can't handle currently, but it works often enough to be useful, and when it fails it's pretty graceful about it.

One major limitation is the lack of toolchain support. It seems to use the first Nim compiler that it finds on the path, and doesn't support building with nimble. However, CLion helps a lot here, as it makes it pretty easy to throw together a custom build using whatever commands you want, which can then be debugged from inside the IDE if built using --debugger:native. There's also a File Watcher plugin that I'm using to automatically run nimble c check ... on each change, which will properly highlight warning/errors, as well as creating clickable links to navigate directly to errors. It also automatically runs my tests whenever I change them, again with error highlighting and the ability to navigate directly to errors.

The whole thing was a bit of a pain to setup, but it's definitely my favorite nim development environment now that I mostly have the kinks worked out. At some point I'm going to try to release a project template that has the custom build and file watcher stuff pre-configured.

For folks who already use Jetbrains IDEs it's definitely worth a look. For everyone else it's probably a bit early, but it should be a 1st class experience soon enough if @piotrtomiak is able to keep working on it.

Yeah, personally I'll just revert back to an old regexp based syntax highlighter and that's it. I'm fine with that and just using the Nim compiler from the command line. It has worked well enough for all those millions of C devs in the past 50+ years :)

I am getting used to it, but the big problem is for beginners it just highers the bar for entry significantly.

The LSP stuff is cool in theory, but if it's not 100% reliable, then it just gets in the way. Autocomplete would also be cool, but it's not a must. A beneficial side effect of NOT having it is that you'll remember a bit better where things are in your project exactly :)

When one browses the issues on nimlsp or nim.nvim they'll see that it eventually comes down to a hard to debug problem that most likely resides in nimsuggest. But yeah I found this spartan way of programming very insightful, but this RFC makes plenty of arguments why the current state is not desireable.

Tooling is hard though, I'm glad this RFC exists and that IC might mean more reliable tooling. Exciting times ahead!