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 think about
>> because the input is just a tree
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, at the very least, patent it a
On 16/10/2017 23:11, Matthias Felleisen wrote:
Lisp macros are easier than Racket’s in the same way that it
was so much easier to write procedures in ASM than in Pascal.
Having used both, I fully agree, but I also wonder if it is possible to
restore *some* of the simplicity of Lisp macros in
> 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 subscribed
> 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.
>
> George Neuner, you might want to look at Greg
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" (http://www.greghendershott.com/fea
> 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 easier to use correctly, be
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 i
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 pr
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 Firth wrote:
>>>
>>>
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 discover
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 that
>
> 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
13 matches
Mail list logo
