Anon proc generator from a typedesc

[beef331]

Presently if one wants to use anonymous procedures they either have to write the entire definition out or use sugar.=>. This is proposing a new macro to be added to the stdlib and heavily encouraged to be used. Solving the following issues:

• Non inferred pragmas have to be manually annotated(E.g calling conventions)
• When an anonymous proc infers different effects(E.g nosideeffect) it results in a type mismatch instead of helpful diagnostics
• Adding parameters to the procedure requires all existing procedures to be updated though they do not use the new parameter

The basis for this would be roughly

import std/macros
macro anon*(p: typedesc[proc], paramNames: varargs[untyped]): untyped =
  ## Instantiates a new proc naming the parameters the same as the type definitions
  ## This allows making anonymous procs in a nice format
  let 
    def = p.getTypeImpl[^1].getTypeImpl.copyNimTree
    body = paramNames[^1]

  for i, x in def[0]:
    if i > 0:
      x[0] =
        if i - 1 < paramNames.len - 1:
          paramNames[i - 1]
        else:
          ident $x[0]

  result = newProc(newEmptyNode())
  result.params = def[0]
  result.body = body
  result.pragma = def[1]

Which would allow:

type MyProc[T] = proc(i: T) {.nimcall, raises: [].}
var a = MyProc[int].anon: echo i
a = MyProc[int].anon(theFirstParameter): echo theFirstParameter
# a = MyProc[int].anon: raise (ref Exception)() # Compile error as it raises an exception

[zerbina]

As is, the macro relies on procedure types to have identified (read, named) parameters.

This is a separate topic, but I'm of the opinion that procedure types should not have identified parameters. They don't contribute to type equality, and having them do would complicate the type system and implementation, as now there needs to be a distinction made between "proc type with identified parameters" and "proc type with unidentified parameters", with the former having to have a subtype relationship with the latter, etc.

I'd like for tyProc types to no longer store any symbols, but the proposed macro at least partially conflicts with that.

[saem]

I agree that the dropping identified parameters would simplify things, but what's tricky about this at present is that we allow overload resolution based on keyword arguments -- not an issue for anon routines, but is for a general type API.

I guess a corollary to what you're saying is we would probably consider such procedures as ambiguous? It does diminish some of the power of keyword arguments.

[beef331]

Having the names generated off the type is nice, but it's not exactly a deal killer. The present solutions already forces naming them. For ones not named they can just be gensym'd instead.

I will say that having parameters inside the pointer procedures is a way of documentation. It allows the library developer to explicitly state what the parameter is for without relying on doc comments. type SomeCallback = proc(UIElement, UiElement) ## First parameter is parent, second is child vs. type SomeCallback = proc(parent, child: UiElement)

[zerbina]

I guess a corollary to what you're saying is we would probably consider such procedures as ambiguous? It does diminish some of the power of keyword arguments.

No, parameter name based overloading would continue to work, as overload resolution can look at callee's symbol for fetching the parameter names, not its type. What wouldn't continue to work, however, is using named parameters with procedure values:

type Type = proc(x: int)
var p: Type
p(x = 1) # this type checks
p(a = 1) # this does not

Right now, the parameter names in a tyProc type do not contribute to type equality in any way:

type A = proc(x: int)
type B = proc(a: int)

doAssert A is B # succeeds
doAssert B is A # succeeds

var a = default(A)
var b = default(B)

a = b # works
b = a # works

Since call analysis does consider the proc types' parameter names, two proc types with differing parameter names but otherwise equal parameter types are not isomorphic (the types and values inhabiting them cannot be used interchangeably), yet they're considered equal by the type system, and I think that's wrong.

Making two proc types with differing parameter names not equal would address this, but also create multiple new problems at the same time, and I personally think the small convenience of being able to use named parameters in calls with non-static callees is not worth those troubles.

To reiterate, removing parameter names from procedure types would not prevent parameter-name-based overload resolution.

[zerbina]

I will say that having parameters inside the pointer procedures is a way of documentation. It allows the library developer to explicitly state what the parameter is for without relying on doc comments. type SomeCallback = proc(UIElement, UiElement) ## First parameter is parent, second is child vs. type SomeCallback = proc(parent, child: UiElement)

Should the parameter names be removed from the PType, it wouldn't require the concrete/abstract syntax to reflect this. That is, type P = proc(a, b, d, e: int) would still very much be valid syntax -- there's just no longer a way to retrieve them from the produced type.

[saem]

Making two proc types with differing parameter not equal names would address this, but also create multiple new problems at the same time, and I personally think the small convenience of being able to use named parameters in calls to non-static callees is not worth those troubles.

Ah, this is where I thought things might lead to, but not doing it is pragmatic, thanks for clarifying.

---

From an explanation to the user perspective, dynamic calls resolve using type information, while static calls resolve using symbol+type information, seems pretty easy to digest.