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
