I wish so badly that there were a statically typed, pure, and lazy Scheme.
What would distinguish this from existing statically typed, pure, and lazy functional languages such as Haskell?
Scheme Reports at Fifty
11–20 of 27 posts
Re: Scheme Reports at Fifty
#12I wish so badly that there were a statically typed, pure, and lazy Scheme.
> lazy
Why? What are the advantages, in practice, of lazy evaluation as the default?
Re: Scheme Reports at Fifty
#13I wish so badly that there were a statically typed, pure, and lazy Scheme.
3/4 for Shen. It's a Lisp-2 but typed, pure and lazy.
Re: Scheme Reports at Fifty
#14Re: Scheme Reports at Fifty
#15I wish so badly that there were a statically typed, pure, and lazy Scheme.
> lazy Why? What are the advantages, in practice, of lazy evaluation as the default?
If you have immutable data and want code reuse, you need laziness otherwise you give up a lot of performance. In Haskell, a careful choice of implementation for `sort` means that `take 10 (sort someList)` will only do enough work to return the first ten elements.
Having laziness by default means that functions compose properly by default; you don't have to worry about libraries providing an interface to your chosen incremental streaming library or whatever. I've seen friends working in strict dialects of Haskell forced to write out each combination of list functions by hand because otherwise they'd have to materialise large intermediate data structures where regular lazy Haskell simply wouldn't.
Ed Kmett has a couple of great posts about the value he's realised from laziness:
https://www.reddit.com/r/haskell/comments/l98v73/can_you_sha...
https://www.reddit.com/r/haskell/comments/5xge0v/today_i_use...
Re: Scheme Reports at Fifty
#16Earlier quoted context omitted.
> lazy Why? What are the advantages, in practice, of lazy evaluation as the default?
If you have immutable data and want code reuse, you need laziness otherwise you give up a lot of performance. In Haskell, a careful choice of implementation for `sort` means that `take 10 (sort someList)` will only do enough work to return the first ten elements. Having laziness by default means that functions compose properly by default; you don't have to worry about libraries providing an interface to your chosen i…
What works for Kmett most often does not work for mere mortals.
As for your first point, I think it's self-defeating: You claim "you don't have to worry about libraries providing an interface to your chosen incremental streaming library", but this requires "a careful choice of implementation" in those libraries with your chosen incremental streaming semantics in mind, which is the same thing but less explicit! And as long as mere mortals can't figure out the magic implementation of `sort` which makes incremental streaming work without explicit bindings, then what's the point?
Haskell is a great language for consuming libraries written by Ed Kmett, as your link demonstrates. Otherwise, it's difficult to work with.
Re: Scheme Reports at Fifty
#17I wish I saw what these guys do in scheme. I only barely know what is happening and it seems interesting. The parens are so hard for me to follow and always have. I have yet to find an editor that fixes that. Perhaps I did not try enough or am not smart enough to acutally use the editors correctly. Anyway interesting read I think
The "such parens, much overwhelm, so confuse" attitude of non-Lispers always baffled me. Especially since when working in C-syntax languages, I'm cautious enough to enforce an explicit order of operations (to avoid confusion that can lead to errors) that I put nearly as many parens in my C or Java code as I do in my Lisp code. What's a few more pairs of round brackets among friends, eh? Emacs was purpose-built for wo…
I had a talk with someone very much allergic to lisp (a college trauma for him iirc). For people like him, extra distinction through syntax is a mental benefit while I assume lisp fans need the opposite, removing 90% of syntax makes things easier (sexps and fp composability being key too)
Re: Scheme Reports at Fifty
#18Tangent, but wow did I find the typography and font-face on that blog post pleasant to read.
Re: Scheme Reports at Fifty
#19Re: Scheme Reports at Fifty
#20Earlier quoted context omitted.
If you have immutable data and want code reuse, you need laziness otherwise you give up a lot of performance. In Haskell, a careful choice of implementation for `sort` means that `take 10 (sort someList)` will only do enough work to return the first ten elements. Having laziness by default means that functions compose properly by default; you don't have to worry about libraries providing an interface to your chosen i…
What works for Kmett most often does not work for mere mortals. As for your first point, I think it's self-defeating: You claim "you don't have to worry about libraries providing an interface to your chosen incremental streaming library", but this requires "a careful choice of implementation" in those libraries with your chosen incremental streaming semantics in mind, which is the same thing but less explicit! And as…
I had Ed's posts on hand, but I don't think that's true. It works at mortal levels too. If you write `map f (map g someList)`, laziness means you'll materialise at most one cons of the intermediate list (although GHC will probably fuse it outright). A strict language would materialise the entire intermediate list, and mortal developers would have to know to write `map (f . g) someList` to avoid that.
This all assumes that you're willing to buy into a language that does immutable data structures by default, and are willing to rely on the work of people like Okasaki who had to work out how to do performant purely functional data structures. If you're willing to admit more mutability (I'm not), then you sit at different points in the design space.