Arc Forumnew | comments | leaders | submitlogin
2 points by akkartik 5103 days ago | link | parent

Rereading my original comment, my question "What does this level of openness buy programmers?" was too baldly stated. As I was writing it I was thinking something more like "can you give me an example where this would be useful?" (going back to aw's advice at http://arclanguage.org/item?id=14264) And you and others have since given examples.

When I said 'hack kludgily at', I was thinking, "can we find a better way?" So combining the two I'd rephrase my original statement as:

"Can you give some examples of where this is a problem? Assuming it's a problem, I'm sure we can come up with more elegant solutions."

That's closer to what I was thinking, and I don't think I'm revising history either. My apologies for the tone.



1 point by Pauan 5103 days ago | link

"Can you give some examples of where this is a problem? Assuming it's a problem, I'm thinking about more elegant solutions to the problem."

The reason I didn't give examples is because I didn't have any. It was just a, "oh hey we can make Arc more hackable if we do this" sorta thing. I figured we'd find use-cases for it later, and, well, we did.

As for a more elegant solution... this solution is using message passing. So to get the environment of the function `foo`, you would use this:

  foo<-environment
And to get the closure for foo, you'd use this:

  foo<-environment<-outer
How would you make that more elegant? Does it need to be more elegant, considering that accessing a function's closure is a pretty rare and special-case thing to do? Would you prefer to use `(get-closure foo)` instead? Oh, wait, you can do that:

  (def get-closure (x)
    x<-environment<-outer)
It's easy to write function wrappers that make message passing more palpable, but it's a lot harder to use functions to simulate message passing. So it makes sense for the low level things to be done with message passing, and then write wrappers for them.

---

"My apologies for the tone."

Mine wasn't exactly happy rainbows either, you know. I don't mind people saying that an idea of mine is kludgy, but I'd at least like some justification for it. You know, an example where my idea is noticeably kludgy, or perhaps a different solution that is demonstrably less kludgy.

-----

1 point by akkartik 5103 days ago | link

Yeah like I said at http://arclanguage.org/item?id=14418 I even withdraw my sense that there must be a better way. Next time, think before hitting submit :)

-----

1 point by Pauan 5103 days ago | link

It's perfectly understandable that you want a nice, sleek, shiny high-level thing that walks your dog and washes your dishes, but at some point you need the low-level stuff.

And because I'm sorta kinda writing an interpreter, not only am I thinking about low-level stuff, but I'm actually implementing it, so my posts and "great ideas" will probably be about low-level stuff for a while.

So, don't worry about it. You're up there in Arc-land thinking about high-level stuff, whereas I'm down here in low-level Python, thinking about low-level stuff. We both need to try to remember that better.

I'd still be interested in hearing if you come up with a better idea.

Oh! I know! We can write an Arc program that reads our minds, it would be the most elegant and concise language ever! :P

-----