Re: [racket] set!: eval-ing to lvalues

2014-04-23 Thread Sean Kanaley
It appears I have subconsciously plagiarized something I must've read a long time ago? Well I'm citing that blog then. On Wed, Apr 23, 2014 at 5:04 PM, Prabhakar Ragde wrote: > Stephen Chang wrote: > > Reminds me of this: >> http://james-iry.blogspot.com/2009/05/brief-incomplete-and- >> mostly

Re: [racket] set!: eval-ing to lvalues

2014-04-23 Thread Prabhakar Ragde
Stephen Chang wrote: Reminds me of this: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html 1990 - A committee formed by Simon Peyton-Jones, Paul Hudak, Philip Wadler, Ashton Kutcher, and People for the Ethical Treatment of Animals creates Haskell, a pure, non-strict,

Re: [racket] set!: eval-ing to lvalues

2014-04-23 Thread Stephen Chang
>> > a hylomorphism is just an endofunctor in the Hask category of >> > profunctorally-dual product monoids with just a hint of commutative free >> > applicative comonads and a dash of F-algebra, >> >> >> Do you have citations for that? Reminds me of this: http://james-iry.blogspot.com/2009/05/br

Re: [racket] set!: eval-ing to lvalues

2014-04-23 Thread Sean Kanaley
Unfortunately I forgot which site it was and I deleted my browsing history as I always do after looking at functional porngramming. On Wed, Apr 23, 2014 at 9:26 AM, Matthias Felleisen wrote: > > On Apr 22, 2014, at 10:10 PM, Sean Kanaley wrote: > > > a hylomorphism is just an endofunctor in th

Re: [racket] set!: eval-ing to lvalues

2014-04-23 Thread Matthias Felleisen
On Apr 22, 2014, at 10:10 PM, Sean Kanaley wrote: > a hylomorphism is just an endofunctor in the Hask category of > profunctorally-dual product monoids with just a hint of commutative free > applicative comonads and a dash of F-algebra, Do you have citations for that?

Re: [racket] set!: eval-ing to lvalues

2014-04-22 Thread Sean Kanaley
I'm slightly late to the lens party but Haskell seems to have a solution to this problem that simultaneously solves another--pattern matching--the location of a value shouldn't be hard-coded similarly in 50 different places that deconstruct a struct just to save typing on an accessor, god forbid th

Re: [racket] set!: eval-ing to lvalues

2013-06-09 Thread Carl Eastlund
There are a lot of tradeoffs in decisions like this. Personally, for instance, I've never found the desire for a generic set!; I just use a specific set! or store a box (mutable reference cell) wherever I need to mutate something. The impact of an lvalue system is going to be different for each S

Re: [racket] set!: eval-ing to lvalues

2013-06-09 Thread Sean Kanaley
Thanks for the explanation. I suspected it was for efficiency reasons, but as I've never implemented a "real" scheme, I don't know the trade off. I wonder how bad it is. Way back, they invented lisp. Then they said it was too slow for real stuff. Now they say other languages are too weak f

Re: [racket] set!: eval-ing to lvalues

2013-06-09 Thread Carl Eastlund
Sean, Not every Scheme uses an interpreter with an eval function as its primary method of execution, or even at all. Racket uses a bytecode interpreter and a JIT native-code compiler; the eval function simply triggers compilation to bytecode. These give a great deal more efficiency than running

[racket] set!: eval-ing to lvalues

2013-06-06 Thread Sean Kanaley
Hello all, I was curious why Scheme and now Racket does not inherently support a generic set!. I found an SRFI http://srfi.schemers.org/srfi-17/srfi-17.htmlthat suggests a generic method solution requiring a lookup for the "real" setter (and so needing a special setter for every data type. What