[racket-users] Re: code reflection

On Mon, 16 Oct 2017 17:11:53 -0400, Matthias Felleisen wrote: >> On Oct 16, 2017, at 2:17 PM, George Neuner wrote: > >> Lisp's macros are ... I won't say easier to use correctly, because >> they aren't ... but IMO they are easier to understand and

Re: [racket-users] Re: code reflection

On Tue, Oct 17, 2017 at 2:36 AM, Konrad Hinsen wrote: > I never got > around to work on this seriously, both because of the 24-hour-per-day limit > that I cannot seem to get rid of, When you figure that one out, don't forget to open source your solution, okay? Or,

Re: [racket-users] Re: code reflection

> Greg, if you're reading this...any chance you might expand FoM? In the meantime, the "Syntax Parse Examples" package is always accepting contributions: http://docs.racket-lang.org/syntax-parse-example/index.html#%28part._.The_.Examples%29 -- You received this message because you are

Re: [racket-users] Re: code reflection

> On Oct 16, 2017, at 5:26 PM, David Storrs wrote: > > On Mon, Oct 16, 2017 at 5:11 PM, Matthias Felleisen > wrote: >> >> You speak of personal failing, and I think that’s incorrect. >> We are missing a good introduction to syntax and friends. >

Re: [racket-users] Re: code reflection

On Mon, Oct 16, 2017 at 5:11 PM, Matthias Felleisen wrote: > > You speak of personal failing, and I think that’s incorrect. > We are missing a good introduction to syntax and friends. George Neuner, you might want to look at Greg Hendershott's "Fear of Macros"

Re: [racket-users] Re: code reflection

> On Oct 16, 2017, at 2:17 PM, George Neuner wrote: You speak of personal failing, and I think that’s incorrect. We are missing a good introduction to syntax and friends. But having said that, I need to contradict this one: > Lisp's macros are ... I won't say

[racket-users] Re: code reflection

Hi all, Thanks to everyone who replied. I apologize for posting and vanishing ... a family emergency on Saturday took me away for the weekend. David: Thank you for the exposition about your task scheduler. I have something similar, a (thread safe) priority queue based on data/heap, although

Re: [racket-users] Re: code reflection

Given the quality and depth of prior comments in this thread, I'm a little reluctant to chime in. I suppose, however, that people on this list tend to be forgiving and maybe my much less elegant solution will be helpful, at least as inspiration. This solution is not originally intended for the

Re: [racket-users] Re: code reflection

Lovely! I was thinking along these lines, but you hit it out of the park. Sounds like you must be avoiding some really important task! John > On Oct 14, 2017, at 11:31, Ryan Culpepper wrote: > > On 10/14/2017 05:01 AM, George Neuner wrote: >> On 10/14/2017 3:00 AM, Jack

Re: [racket-users] Re: code reflection

On 10/14/2017 05:01 AM, George Neuner wrote: On 10/14/2017 3:00 AM, Jack Firth wrote: So is there a way ... from normal code ... to get at the locals of functions higher in the call chain?  Or at least the immediate caller? Some reflective capability that I haven't yet

Re: [racket-users] Re: code reflection

On 10/14/2017 3:00 AM, Jack Firth wrote: So is there a way ... from normal code ... to get at the locals of functions higher in the call chain?  Or at least the immediate caller? Some reflective capability that I haven't yet discovered? I'm not sure if there's a way to do

[racket-users] Re: code reflection

> > So is there a way ... from normal code ... to get at the locals of > functions higher in the call chain? Or at least the immediate caller? > Some reflective capability that I haven't yet discovered? > I'm not sure if there's a way to do that, but I'm wondering if what you want to do can