Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: undeclared identifier: '|' #9540

Closed
narimiran opened this issue Oct 28, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@narimiran
Copy link
Member

commented Oct 28, 2018

This error is raised sometimes depending on the number of imports.

Working example

Taken from here:

import sugar

proc foo[T]: seq[int] =
    return lc[x | (x <- 1..10, x mod 2 == 0), int]

doAssert foo[float32]() == @[2, 4, 6, 8, 10]

Failing example

(Found out about it when I was doing this PR.)

Now change just the first line to: import macros, sugar, tables, typetraits and you get Error: undeclared identifier: '|'.

Ok, it must be one of the three new imports. Let's find out which one:

  1. If we do import macros, sugar and it compiles just fine.

  2. import sugar, typetraits also compiles just fine. So it must be tables, right?

  3. import sugar, tables and — compiles just fine!

  4. Also, any of the following also works: import macros, sugar, tables, import macros, sugar, typetraits, import sugar, tables, typetraits.

Once again, only when all four imports are present there is the error:

import sugar, typetraits, tables, macros

proc foo[T]: seq[int] =
    return lc[x | (x <- 1..10, x mod 2 == 0), int] # Error: undeclared identifier: '|'

doAssert foo[float32]() == @[2, 4, 6, 8, 10]

Expected Output

Compile without an error.

Additional Information

$ nim -v
Nim Compiler Version 0.19.1 [Linux: amd64]
Compiled at 2018-10-28
Copyright (c) 2006-2018 by Andreas Rumpf

active boot switches: -d:release
@krux02

This comment has been minimized.

Copy link
Contributor

commented Oct 28, 2018

List comprehension should be deprecated/removed as fast as possible. Don't use it.

As a note to myself I should update the documentation to say away from it.

@narimiran

This comment has been minimized.

Copy link
Member Author

commented Oct 28, 2018

List comprehension should be deprecated/removed as fast as possible. Don't use it.

I personally don't use it. But the example posted is in the tests, and depending on the number of the imports it fails.

And until lc is changed/removed, the stuff like this shouldn't happen.

@krux02

This comment has been minimized.

Copy link
Contributor

commented Oct 28, 2018

I just want to remove it. Without substitution. It will just solve problems. Nobody is or should use it.

@dom96

This comment has been minimized.

Copy link
Member

commented Oct 28, 2018

Yes, list comprehension should be removed. We are getting for loop expressions as a replacement (which also need better docs so please show an example of them when getting rid of lc).

@Araq Araq added Stdlib and removed Documentation labels Oct 28, 2018

narimiran added a commit to narimiran/Nim that referenced this issue Oct 28, 2018

narimiran added a commit to narimiran/Nim that referenced this issue Oct 28, 2018

@Araq Araq closed this in 680f5ee Oct 29, 2018

ianmcxa added a commit to ianmcxa/Nim that referenced this issue Oct 30, 2018

narimiran added a commit to narimiran/Nim that referenced this issue Oct 31, 2018

narimiran added a commit to narimiran/Nim that referenced this issue Nov 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.