Arc Forumnew | comments | leaders | submitlogin
1 point by akkartik 5103 days ago | link | parent

Yeah the toolchain-enhancement use cases make sense.

"If the library isn't designed well, the only way to do this might be to mutate a function, so calling `def` isn't an option. Or perhaps the library is designed well, but the particular situation the library is trying to solve requires mutating functions."

I don't follow this.

Adding features to a function is the whole point of extend. Can you think of an example where it wouldn't suffice?

"if I can't find a logical reason to disallow it, then I should allow it."

That isn't a defense to the question, "is this the right representation?" Even PG isn't allowing non-sexp syntax, as an extreme example. I think "is there a better way to do this" is a fine logical reason.

To summarize: I now agree there's value in making a language's constructs introspectable. I'm less convinced that this specific approach is the best one. But you've gotten me thinking about alternatives :)



1 point by Pauan 5103 days ago | link

"Adding features to a function is the whole point of extend. Can you think of an example where it wouldn't suffice?"

Hm... yes, actually. Imagine a function that is wrapped in a closure, to hide data:

  (let hidden-data ...
    (def foo ()
      (do-something hidden-data)))
How would you use `extend` on `foo`? Extend can't access the hidden data in the closure, but by making functions transparent, you could.

Technically speaking, you wouldn't need mutable functions, just the ability to see a function's closure. For instance, you could use this:

  (let closure foo<-environment<-outer
    (extend foo ...))
Aaand now your extension can access the hidden data. But that's only possible if closures are transparent. And it might be easier to just mutate the function directly:

  (= foo<-body ...)
Incidentally, <- would be ssyntax that lets you easily access an attribute. Thus, the following two would be equivalent:

  foo<-bar 
  (get-attribute foo 'bar)
---

"I think "is there a better way to do this" is a fine logical reason."

Sure, but I don't know of any better ways, nor has anybody presented them, so for now I'm focusing on whether the idea has merit. We can fix the implementation later.

P.S. If you consider this idea to be kludgy, then you probably consider message passing in general to be kludgy. :P How would you like to be able to access the data, then?

---

"But you've gotten me thinking about alternatives :)"

If you find a good one, I'd like to hear it. :P

-----

2 points by akkartik 5103 days ago | link

"Extend can't access the hidden data in the closure, but by making functions transparent, you could."

That's a great example, thanks.

"Sure, but I don't know of any better ways, nor has anybody presented them, so for now I'm focusing on whether the idea has merit."

Yeah that makes sense.

In fact, this is a fine implementation. Once I think of it as exposing the compiler's data structures to the language, separating arg lists and body makes a lot of sense.

-----

1 point by Pauan 5103 days ago | link

"In fact, this is a fine implementation. Once I think of it as exposing the compiler's data structures to the language, separating arg lists and body makes a lot of sense."

Well, yeah, how else would you do it? This is low-level stuff. :P

-----