Lazy iterators/enumerables

Translating some Ruby code and wondered is there a plan to implement lazy iterators?

They already exist, they are called Iterator in Crystal. And there are no eager iterators in Crystal.

What do you need to translate?

I was trying to do a direct translation of this:

specs.each do |start, num|
  puts "first #{num} gapful numbers >= #{start}:"
  p (start..)

And settled for doing this:

specs.each do |start, count|
  puts "first #{count} gapful numbers >= #{start}:"
  i, gapful = 0, [] of Int32
  (start..).each { |n| n.gapful? && (gapful << n; i += 1); break if i == count }
  puts gapful, "\n"

Maybe it has more to do with not having a take() method, that consumes the lazy values?

Once you told me the keyword iterators were (my interpretation) to lazy I looked at the docs (which doesn’t return anything for a search on ''lazy").

This works!

specs.each do |start, num|
  puts "first #{num} gapful numbers >= #{start}:"
  p (start..)

I really do hate to keep harping on this, after you said iterator I went here:
and figured out what to do.

But I initially went here:
where there’s no mention of iterators or lazy.

Ruby is the only language I know where iterators are not lazy by default. You won’t find lazy in any other language either.

1 Like

That may be true, but the github book still mades no mention of iterators and how they work and how to use them.

Again, users coming to Crystal won’t know any of this without sufficient documentation, especially coming from Ruby.


The gitbook is primarily a language reference. Iterators are not part of the language, but the standard library which is documented at
We have planned to improve the documentation and also add more guides. A guide about collections would certainly be helpful. But nobody has written it yet.

1 Like

My emphasis, again, is to point out, a person going to Crystal’s website, and looking under the Docs menu for official examples of use, is given only two (2) choices, a Language Reference or API Docs. The Reference provides information on typical language use, while the API provides specifics on the language components. But if you don’t know what the components are, or are named, you have no clue what to look for on how to do/code something.

Once the iterator -> lazy connection was provided I could go to the API for the specifics in their use. But the natural path a person will take is to first goto the Language Reference to see how to apply components in general coding use, as it should provide that idiomatic basis and understanding to potential users for writing code in this language.

1 Like

But the natural path a person will take is to first goto the Language Reference

The Language Reference is a reference to the language, not a tutorial. As @straight-shoota said, we are missing a tutorial or some guides, but doing that requires a lot of time and effort.

For example, when you learn Japanese, if you go to the grammar guide you will have some examples, but you can’t expect the grammar guide to include a basic conversation between two people, or vocabulary for a hotel situation, etc.

Or go to Go’s language reference: no mention to buffered IO, compression methods, etc.

I think the natural path to take, or the one that I take and I see my coworkers take, is to search in Google, StackOverflow, or the language forum if no result arrives. Then usually the answer will be there… at least with languages with enough time. But Crystal is not such case. As time passes, more and more answers will be asked.

And this is what I’m trying to get you all to do, dedicate the time and effort to make your docs better.

Rust has excellent docs, with an online book, because they know its paradigm is hard to learn, so they try real hard to give potential users the tools to learn it. Rust would have far fewer users if it wasn’t for its docs and forum so people can get answers to questions quickly totally within its own ecosystem, without seeking third party help. Elm also has good docs, a good online book and forum too.

I, and others, have offered to help making the docs better. But until you all actually make it a priority, create a framework people can hook into to help, and create a timeline to get it done, nothing is going to happen.


Because it’s supported by Mozilla.

Elm also has good docs

The Elm author works at NoRedInk (where I work) and he gets a salary to work on Elm.

Crystal is different: it’s mostly volunteer work and donations that go to the project, but there’s no guaranteed monthly income.

Again, I agree that docs are needed, but it’s not feasible to stop fixing bugs, improving the standard library and taking care of PRs and just write docs. There’s just no time and manpower.

1 Like

Adding a new section to somewhere near here: might be nice, to help people know what’s going on…they accept PR’s :slight_smile:


OK @asterite, how about considering this. It’s clear you personally would rather just do code, and that’s what brings you joy. So set up a GoFundMe, et al, project to raise money to pay someone(s) some $$, so they can work XX weeks/months/time to create better docs! If you believe $$ is THE deterrent to creating better docs (which it isn’t) then solve that problem first.

Until you stop coming up with reasons not do it (which you don’t do for writing code), and begin to envision how the goal can be accomplished (not by you), it won’t be.

Rust, Elm, et al, are not one-person/company projects, they are a community of people.

Use the Force Luke! :man_superhero:

1 Like

I would really love to fund a specific goal. I think we need to fund another compiler dev.
I think the generic “donation” does not work because people dont know where the money goes to.

How about setting up gofundme / patreon just to hire a new compiler guy?

Just for reference: I wrote the initial entire language reference :slight_smile: So I do think documentation is needed. But I’m a bit tired after so many years.

I think what we need first is someone that knows the language and can volunteer to write it, assuming people will sponsor that.

What do you think the problem is? You seem to say that it is not money?

Steve Klabnik was probably the keystone to get good docs for Rust, but as said previously he was paid full time by Mozilla.

Writing docs, especially good docs isn’t everyone’s jam, and it does get tiresome after a while it feels more like a chore, also not very rewarding when the API’s aren’t stable due to increased churning.

$$ are a deterrent for sure, if we could get enough money to pay for full time developers crystal would advance must faster, it’s still amazing how far it has come with the incredible gifts by a few great gentlemen.

1 Like

Money is an artificial mentally imposed impediment.
The most important factor is the willingness to do what’s necessary to accomplish the goal.
Everything else are implementation details.

A journey of a thousand miles must begin with the first step. - Lao Tzu

It does not matter how slowly you go as long as you do not stop. - Confucius

If you want to go fast go alone. If you want to go far go together. - African Proverb

1 Like

Are you willing to do what’s necessary to accomplish your goal? If you want the docs to be a certain way, sending PRs would be a great use of your time.


@jzakaiya, thank you for pointing out a way in which the documentation can be improved. This can be a very helpful contribution to an open source project.

While you are not alone in wishing that someone was able to take up the effort to implement your recommendations, it is probably more effective to thank people like @asterite for the work and effort they are able to make, and from which we all benefit, than it is to focus on how much more they could do to help you. It is difficult for someone contributing to a project to interpret an accusation that they should be doing more, as a positive contribution in itself. It’s safe to say that no one could be expected to respond well to that approach, and so it’s not likely to improve the language or its documentation.

I think everyone would welcome a constructive discussion about how the documentation might be improved. I think a list of specific changes for “someone” to make is of some value, but that’s usually the easiest part of documenting a project. The hard part is to design a realistic approach that will take advantage of the resources that are actually available to accomplish the goal.

I know that I cannot contribute much to the process, as I have obligations that take most of my time, and lack any skill at all in writing documentation. Knowing this, I limit my own participation to thanking @asterite for all the amazing work, and taking action whenever I see a practical, effective way to contribute.

Paul M. Lambert