[racket] Pure functional Racket
Cesar Barata
--
Cesar Barata.
Matthias Felleisen
The HtDP teaching languages BSL, BSL+, ISL, and ISL+ are purely functional. There is a typed version of ASL on PLaneT; I am sure it would be trivial to adapt the type system to the purely functional ones. That's the best starting point we can offer. Not even Lazy is purely functional.
If you'd be interested in contributing a Functional Racket, we'd be happy to help you with advice. I think it is a great idea.
-- Matthias
p.s. Also look at frtime. It isn't functional but functional reactive.
> _________________________________________________
> For list-related administrative tasks:
> http://lists.racket-lang.org/listinfo/users
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
Eli Barzilay
How would it be useful? (Not a rhetoric question.)
The only thing I can think of is making it easy to refactor code, but
that doesn't look like it's enough of an advantage to make up a new
language.
Note, BTW, that making a language that is *completely* side-effect
free can be a little tricky. For example, you'd need to either forbid
`require' or implement one that cannot get any non-pure code in, since
you should forbid pure code from calling out to impure functions. As
Matthias said, the lazy language is impure too -- and it's related to
this: if you want it to be completely pure then you need to give up
being able to call out to non-pure code, which means that you lose
interoperability. (Or you need to somehow organize access to the
impure code as in monads or similar things.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Matthias Felleisen
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
Eli Barzilay
>
> 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".
[You mean:
Totally pure!
*wink* *wink* *nudge* *nudge* *cough* unless you^W^W
Nah, it's totally pure. (Watch out! there's a giant tiger behind
you!)
]
> It's decision mechanism. It appears to be elegant. It is an
> easily remembered design slogan.
But there you get the benefit of a compiler that can take advantage of
this, and we don't. (Even if it does, it would require even more
subtle points like avoiding struct definintions, threads, exceptions,
continuations...)
> 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 don't think I've seen that before... I remember Sam's "Racket is a
Programmable 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.
Yeah, that's what I was implying -- it would be interesting to have a
way to talk to an unpure world. In any case, if Cesar is aware of
this then that would definitely be an interesting experiment.
> 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
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Matthias Felleisen
On Jul 6, 2011, at 10:23 PM, Eli Barzilay wrote:
> But there you get the benefit of a compiler that can take advantage of
> this, and we don't. (Even if it does, it would require even more
> subtle points like avoiding struct definintions, threads, exceptions,
> continuations...)
No that's yet another challenge. Can we 'specialize' our backend so that it can take advantaged of purity?
Robby Findler
>
> 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.
FWIW, Jacob explored some of the subtlety relating to this in a
theoretical setting. His calculi might be useful as a guide if someone
wanted to look into it more.
Shriram Krishnamurthi
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
Matthias Felleisen
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