Mirror of forum.nim-lang.org

3664 :: generic proc not instantiated depending on calling syntax

• sflennik (orginal) [2018-03-18T04:05:36+01:00] view original

  The following program generates an error. Shouldn't it work?

  proc readMe[T](name: string): T =
    result = 123'u16
  var num = "test".readMe[uint16]()
  # var num = readMe[uint16]("test")
  echo num
  Run

  Here are the error messages:

  
  t.nim(5, 17) template/generic instantiation from here
  t.nim(2, 13) Error: cannot instantiate: 'T'
  Run

  The workaround is to use the commented out line instead.

---

• mashingan (orginal) [2018-03-18T09:17:45+01:00] view original

  This works

  proc identity[T](name: T): T =
    result = name
  
  var n1 = "test".identity
  var n2 = 123.identity
  
  echo n1
  echo n2
  Run

---

• mratsim (orginal) [2018-03-18T09:51:28+01:00] view original

  It's a known issue. It's hard to disambiguate "test".readMe[uint16]() with a bracket expression I suppose since at that time the compiler doesn't know if uint16 is a typedesc or an index I suppose.

  I think there is a RFC for that: https://github.com/nim-lang/Nim/issues/3502

---

• Araq (orginal) [2018-03-18T14:27:21+01:00] view original

  x.y[z] is (x.y)[z] and not x.(y[z]). There is nothing to disambiguate here, expression parsing produces a single consistent AST regardless of the involved symbols. There is no "partial call syntax with explicit generic types" in Nim's manual.

---

• Lando (orginal) [2018-03-19T09:25:09+01:00] view original

  Never liked using a special bracket character for generic type parameters.

  # this is not a "generic procedure", it's a procedure constructor.
  proc threeOf[A](a: A): array[3, A] =
    for i in 0 .. 2:
      result[i] = a
  
  # the procedure constructor is called with a type parameter to *produce* a proc.
  var p = threeOf[int]
  
  # then, the proc is called with a value parameter.
  echo p(5)
  Run

  The fact that the constructor call can happen at compile time and sometimes the type parameter can be implied doesn't change that. IMHO it would make more sense to use parentheses for type parameters, because that's what we use for parametrization anyway:

  proc threeOf(A)(a: A): array(3, A) = ...
  
  threeOf(int)(5)
  Run

  Type and value parameters are distinguishable by the case of the leading character or - for builtins - by syntax highlighting. Square brackets are reserved to indcate indexing, as they should.

  Edit: replaced the square brackets in array[3, A] with parentheses too.

---

• StasB (orginal) [2018-03-19T09:39:16+01:00] view original

  @Lando: that would create ambiguities:

  proc test(x: typedesc): proc(x: int) =
    (proc(x: int) = echo x)
  
  proc test(A)(x: int) =
    echo x
  
  test(int)(123) # which one is it?
  Run

  Personally, I also think it looks far uglier.

---

• Lando (orginal) [2018-03-19T10:22:14+01:00] view original

  @StasB: The first definition is just a complicated way to write the second one. typedesc parameters make a proc generic, just like square bracket parameters (apart from special binding behaviour). And yes, that's an ambiguity and therefore should result in a compiler error.

  About the ugliness: you have a point here, but I find consistency far more important (Haskell changed my mind quite a bit).

---

• StasB (orginal) [2018-03-19T10:51:40+01:00] view original

  The first definition is just a complicated way to write the second one.

  Huh. Looks like you're right:

  proc test(T: typedesc): proc(x: T) =
    (proc(x: T) = echo x)
  
  test(string)("foo")
  Run

  Never occurred to me that you can use it this way.

  I find consistency far more important (Haskell changed my mind quite a bit).

  Then you should be disturbed by the fact that Haskell's type system corresponds to an inconsistent logic. ;^)

---

• Lando (orginal) [2018-03-19T11:12:29+01:00] view original

  Never lost sleep over undefined and bottom. You are really lucky I'm not Libman, this could be a two page excursion. :)

---