[☯]: Inferring the names of procedures created by ☯.

[NoahStoryM]

Summary of Changes

Inferring the names of procedures created by ☯.

Welcome to Racket v8.6 [cs].
> (require qi)
> (object-name (☯ add1))
'add1
> (object-name (☯ (esc (lambda _ _))))
'flowed
> (define f (☯ (~> + + add1)))
> (object-name f)
'f
> (define g (☯ (esc (lambda _ _))))
> (object-name g)
'g

Public Domain Dedication

• [x] In contributing, I relinquish any copyright claims on my contribution and freely release it into the public domain in the simple hope that it will provide value.

(Why: The freely released, copyright-free work in this repository represents an investment in a better way of doing things called attribution-based economics. Attribution-based economics is based on the simple idea that we gain more by giving more, not by holding on to things that, truly, we could only create because we, in our turn, received from others. As it turns out, an economic system based on attribution -- where those who give more are more empowered -- is significantly more efficient than capitalism while also being stable and fair (unlike capitalism, on both counts), giving it transformative power to elevate the human condition and address the problems that face us today along with a host of others that have been intractable since the beginning. You can help make this a reality by releasing your work in the same way -- freely into the public domain in the simple hope of providing value. Learn more about attribution-based economics at drym.org, tell your friends, do your part.)

[NoahStoryM]

I noticed that the name of (flow (~> + add1)) on its own is composed. That might be because compose internally ends up naming the result composed, and "names closer to an expression take precedence". Do you think this case would be worth handling and renaming to compiled-flow?

I forgot to mention some issues with this PR a while ago. Currently I feel that renaming via procedure-rename might cause some problems.

For example:

Welcome to Racket v8.6 [cs].
> (struct doc-procedure (doc f)
    #:property prop:procedure (struct-field-index f))
> (define f (doc-procedure "f" (lambda () 123)))
> (doc-procedure? f)
#t
> (doc-procedure? (procedure-rename f 'g))
#f

qi/sum redefines ~> in this way, so if we use procedure-rename, some redefined forms may not work.

[countvajhula]

qi/sum redefines ~> in this way, so if we use procedure-rename, some redefined forms may not work.

In what way would they not work? Could you give an example -- would it just be a naming issue or would it affect the functionality as well?

In general, I wonder if that should be considered a bug in procedure-rename. Seems like renaming a callable struct should preserve its type.

[countvajhula]

Also, I'm assuming the procedure-rename issue affects #70 as well?

[NoahStoryM]

In general, I wonder if that should be considered a bug in procedure-rename. Seems like renaming a callable struct should preserve its type.

Yeah, I've reported it (https://github.com/racket/racket/issues/4455).

In what way would they not work? Could you give an example -- would it just be a naming issue or would it affect the functionality as well?

For example, I redefined ~> in qi/sum:

(struct coprocedure (coarity result-coarity))
(struct composed coprocedure (f)
#:property prop:procedure (struct-field-index f))

(define (make-composed . f*) ...)

(define-qi-syntax-rule (~> flo ...)
  (esc (make-composed (☯ flo) ...)))

If we rename the procedure made by ~>, then the renamed procedure isn't a coprocedure, which makes some functions dealing with coprocedure not work properly.

Also, I'm assuming the procedure-rename issue affects https://github.com/drym-org/qi/pull/70 as well?

https://github.com/drym-org/qi/pull/70 currently only renames some curried functions (they are not structs), so I guess it should have no effect.