Thanks for constructive replies.<div><br></div><div>I'm taking a look at the teaching languages Matthias mentioned and some object-capability stuff. I've also found some literature on the Oz programming language and hopefully some of its concepts of multiparadigm integration will be applicable to Racket languages.</div> <div><br></div><div>--</div><div>Cesar<br><div><div><br><div class="gmail_quote">On Thu, Jul 7, 2011 at 10:13 AM, Matthias Felleisen <span dir="ltr"><<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> Here is a bunch of reactions:<br> <br> 1. You are correct.<br> <br> 2. My hunch is that a lot of people will explore the capability space because they see it like you do.<br> <br> 3. It is therefore more likely that an exploration of "pure, cbv, typed, macroized parenthesized language" will produce unique insights. That might be a problem or an advantage.<br> <br> No matter how you slice it, the point of Racket is that it is easy to explore both. -- Matthias<br> <div><div></div><div><br> <br> <br> On Jul 7, 2011, at 12:53 AM, Shriram Krishnamurthi wrote:<br> <br> > Just as E, etc. get a tremendous benefit by saying they are languages<br> > with no ambient authority, built instead around object capabilities.<br> > The more I study capability languages the more I see the parallels to<br> > Haskell's hair shirt. Frankly, for the modern world I think the<br> > object capability side is at least as interesting to explore as purity<br> > (and the two are not inconsistent at all).<br> ><br> > Shriram<br> ><br> > On Wed, Jul 6, 2011 at 9:55 PM, Matthias Felleisen <<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>> wrote:<br> >><br> >> On Jul 6, 2011, at 9:16 PM, Eli Barzilay wrote:<br> >><br> >>> How would it be useful? (Not a rhetoric question.)<br> >><br> >> I can think of two and a half ways:<br> >><br> >> 1. Haskell has had a tremendous benefit in putting a stake in the ground with "totally pure". It's decision mechanism. It appears to be elegant. It is an easily remembered design slogan. Try to come up with a slogan like that for Racket. (I still think we should say Racket is a programming language programming language.)<br> >><br> >> I suspect one would similar benefits from a call-by-value parenthesized macroized possibly typed Racket. I am sure monadic programming would be much easier with macros. I am also sure people will prefer call-by-value over lazy, especially if you bother with type classes or something like that.<br> >><br> >> In short, it is an unexplored point in the design space and you never know what you find.<br> >><br> >> 2. As you point correctly, it is a non-trivial task to ensure total purity: require is the first problem that comes to mind but I wouldn't be surprised if other reflection mechanism don't end up being in the way. It looks easy as in "require Racket, export only pure features" but for all we know, we may discover that we need to support other ways of restricting languages.<br> >><br> >> 3. It would also be another playing field in exploring interoperability.<br> >><br> >> ;; ---<br> >><br> >> The first exercise would be to define what purity is.<br> >> I/O anyone? Is the world model from big-bang acceptable? How about files? CPS-IO? Monads?<br> >><br> >> The second exercise would be to implement this core language.<br> >> How many of the macros do you want to allow in, can you afford to allow in?<br> >><br> >> The third one is probably to design a type system.<br> >><br> >> The fourth one calls for macros.<br> >><br> >> Someone go for it -- Matthias<br> >><br> >><br> >><br> >><br> >><br> >><br> >><br> >> _________________________________________________<br> >> For list-related administrative tasks:<br> >> <a href="http://lists.racket-lang.org/listinfo/users" target="_blank">http://lists.racket-lang.org/listinfo/users</a><br> >><br><br></div></div></blockquote></div> </div></div></div>