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

List comprehensions do not work with generic parameter #5707

Closed
mratsim opened this issue Apr 14, 2017 · 11 comments

Comments

Projects
None yet
7 participants
@mratsim
Copy link
Collaborator

commented Apr 14, 2017

This compiles:

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

This doesn't

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

Error: undeclared identifier: '|'

@Araq Araq added the Stdlib label Apr 19, 2017

@Araq

This comment has been minimized.

Copy link
Member

commented Apr 19, 2017

This is stdlib problem, the language works as expected here. The following compiles:

import future

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

The lc macro needs to be redesigned.

@marcotama

This comment has been minimized.

Copy link

commented Aug 23, 2017

Not sure if my comment is out of place, but I encourage fixing this. I was trying to write an iterator over combinations (like the one in Python's itertools module) and I encountered this problem. It would be nice if I were able to use lc with generics in this case.

@dom96

This comment has been minimized.

Copy link
Member

commented Aug 25, 2017

In addition to this: IMO, and I think @Araq agrees, the list comprehensions should be made more Pythonic.

@dom96

This comment has been minimized.

Copy link
Member

commented Nov 26, 2017

I think in the long run we want to obsolete this macro and allow a for loop as an expression.

@dom96 dom96 added the High Priority label Nov 26, 2017

@dom96

This comment has been minimized.

Copy link
Member

commented Nov 26, 2017

High priority because we need to make a decision (if we decide to remove then this will be a breaking change)

@blaiseli

This comment has been minimized.

Copy link

commented Jan 24, 2018

I don't understand the difference between the following two cases:

This one doesn't compile:

proc dist(bc1, bc2: string): int {.inline.} =
  mixin `|`, `<-`  # Error: invalid expression: 'mixin `|`, `<-`'
  sum(lc[int(pair.a != pair.b) | (pair <- zip(bc1, bc2))])

This one does:

  proc matchToAllowed(fastq: Fastq): (string, string) =
    let bcSeq = fastq[1][(bcStart-1)..<(bcStart + bcLen - 1)]
    let bcQuals = fastq[2][(bcStart-1)..<(bcStart + bcLen - 1)]
    let bcProbs = nucProbs(bcSeq, bcQuals)
    proc likelihood(barcode: string): float =
      var letter: char
      var errProb: float
      result = 1
      for i, np in bcProbs.pairs():
        (letter, errProb) = np
        if letter == barcode[i]:
          result = result * (1 - errProb)
        else:
          result = result * (errProb / 3)
    mixin `|`, `<-`  # No problem here
    let likelihoods = lc[likelihood(allowed) | (allowed <- barcodes), float]
    var maxLike = likelihoods[0]
    var bestIdx = 0
    # https://stackoverflow.com/a/48123056/1878788
    for idx, like in likelihoods:
      if like > maxLike:
        maxLike = like
        bestIdx = idx
    let candidate = barcodes[bestIdx]
    let theDist = dist(bcSeq, candidate)
    let annot = join([
      candidate,
      formatFloat(maxLike, ffScientific),
      theDist.intToStr], ":")
    if theDist > maxDiff:
      result = ("Undetermined", annot)
    else:
      result = (candidate, annot)

I have import future in both cases.

@Araq

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

mixin is only valid in a generic proc or a template.

@blaiseli

This comment has been minimized.

Copy link

commented Jan 24, 2018

@Araq It doesn't seem to me that my second example is generic, or is a template. Did I miss something?

@Vindaar

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2018

Ran the code in the OP on current devel 91b3731 and it works fine now.

@narimiran

This comment has been minimized.

Copy link
Member

commented Oct 13, 2018

Ran the code in the OP on current devel 91b3731 and it works fine now.

Can confirm for 0.19.

I think in the long run we want to obsolete this macro and allow a for loop as an expression.

We now have for-loop macros.

Can we close this one?

@Araq

This comment has been minimized.

Copy link
Member

commented Oct 13, 2018

Can we close this one?

Requires a test case.

Vindaar added a commit to Vindaar/Nim that referenced this issue Oct 13, 2018

Araq added a commit that referenced this issue Oct 14, 2018

@narimiran narimiran closed this Oct 14, 2018

krux02 added a commit to krux02/Nim that referenced this issue Oct 15, 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

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

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

add issue #5707 as test case (#9361)
(cherry picked from commit afd5abd)
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.