Thanks for constructive replies. 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.
-- Cesar On Thu, Jul 7, 2011 at 10:13 AM, Matthias Felleisen <[email protected]>wrote: > > Here is a bunch of reactions: > > 1. You are correct. > > 2. My hunch is that a lot of people will explore the capability space > because they see it like you do. > > 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. > > No matter how you slice it, the point of Racket is that it is easy to > explore both. -- Matthias > > > > On Jul 7, 2011, at 12:53 AM, Shriram Krishnamurthi wrote: > > > Just as E, etc. get a tremendous benefit by saying they are languages > > with no ambient authority, built instead around object capabilities. > > The more I study capability languages the more I see the parallels to > > Haskell's hair shirt. Frankly, for the modern world I think the > > object capability side is at least as interesting to explore as purity > > (and the two are not inconsistent at all). > > > > Shriram > > > > On Wed, Jul 6, 2011 at 9:55 PM, Matthias Felleisen <[email protected]> > wrote: > >> > >> On Jul 6, 2011, at 9:16 PM, Eli Barzilay wrote: > >> > >>> How would it be useful? (Not a rhetoric question.) > >> > >> I can think of two and a half ways: > >> > >> 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.) > >> > >> 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. > >> > >> In short, it is an unexplored point in the design space and you never > know what you find. > >> > >> 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. > >> > >> 3. It would also be another playing field in exploring interoperability. > >> > >> ;; --- > >> > >> The first exercise would be to define what purity is. > >> I/O anyone? Is the world model from big-bang acceptable? How about > files? CPS-IO? Monads? > >> > >> The second exercise would be to implement this core language. > >> How many of the macros do you want to allow in, can you afford to allow > in? > >> > >> The third one is probably to design a type system. > >> > >> The fourth one calls for macros. > >> > >> Someone go for it -- Matthias > >> > >> > >> > >> > >> > >> > >> > >> _________________________________________________ > >> For list-related administrative tasks: > >> http://lists.racket-lang.org/listinfo/users > >> > >
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
