Lazy Racket guidelines

Questions & Answers
1

Hi,

I've seen just the docs, not much else on the Web. It says that I can use #lang lazy on per module basis. Does it mean that I can conveniently put all the laziness I need in my app in a separate file and get away with it?

What are pros and cons? I mean, with Haskell everything is lazy, so one has to get used to it, period. Here there's an option, which is always a bit of the tyranny of choice. I haven't been able to find any review on the feature, much less guidelines. Any relevant opinion or link is welcome.

2

  1. General laziness is a bad idea. It also automatically cuts back on expressiveness (just a small bit but that’s why ! is such a popular Haskell feature — the antithesis of laziness.)

  2. Lazy data constructors are a good idea, because they help you deal with very large pieces of data on an incremental basis.

  3. What you really want is a tool that determines where to inject lazy constructors and where to force them. See Stephen Chang’s dissertation or his papers on this topic.

  4. #lang lazy was conceived as a teaching language so we could expose students to general laziness w/o switching syntax. See 1.

  5. Yes, you can use laziness on a per module basis. Importing to and exporting from such a module may occasionally create strange effects or, worse, obscure error messages.
    (It is an approximation to 3.)

2 Likes
3

So,

  1. Don't use Lazy Racket unless you know what you are doing. You can get explicit laziness with vanilla Racket, if you want it bad enough.

  2. If you do know, think twice anyway.

Would you endorse this?

3 Likes
4

I was about to reply but @EmEf beat me to it!

#lang lazy is a just demonstration of what you can do with Racket's language-creation capabilities.

To turn it into something practical would require adding something similar to ghc's strictness analyzer to remove most of the laziness (as a first step).

1 Like