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
