[racket] Pure functional Racket

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 <matthias at ccs.neu.edu>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 <matthias at ccs.neu.edu>
> 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
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110708/f921be78/attachment.html>