REP 101 notes 2016-10-01

REP 101 notes 2016-10-01.md

Setup

First, thanks to everyone for taking time to read the proposal, do their own research, and offer suggestions. I don't know how to export messages from Gitter, so I'm afraid comments there may be lost to time. The REP is a wiki, so you can post your thoughts there. Wiki conversation isn't effective, but if we each have a comment section, we can put our interim and final thoughts there as we move forward. Or Peter can say if we would prefer to have people post things here for him to curate there.

Second, it's clear there is no consensus; not just about the proposal, but about what makes a good loop function.

Third, any comments we make about ease of use (or misuse) are anecdotal. I haven't found any studies or hard data. This is a subjective design call.

Why for?

More than one person commented that the motivation is to ease adoption. That is one motivation, but not the only one and not the most important in my mind.

Without for, how do you:

• Increment by a value other than 1
• Start at a value other than 1
• Use date!, money!, and other non-integer values
• Get detailed control when you need it

That's right, you use while. Is that an acceptable solution for those cases? It comes with a cost. More work and things to get wrong. Here there is, I believe, hard data in support of higher level loop funcs. Quick searching, both online and on my shelves, didn't turn up the numbers. That would be good to do. In the meantime, my dusty brain tells me that studies show a high incidence of bugs in loop-related code, which also relates to off-by-one errors. That doesn't mean REP 101 is the answer, just that there is a problem to be solved.

The name

The name itself: For isn't a great name. The only reason to use this is is historical/expectation. Loop is the alternate proposed name, and is better, because it can be used as a verb. Repeat is even better, because it is normally a verb. BUT, #tangent [the most important thing is not whether something will be intuitive to non-programmers (because nothing will), or seem odd at first glance (because it always will to some people). What matters is whether it conveys intent clearly and fits with the overall design of the language for a range of casual to advanced users. Absolute beginners and gurus can register their complaints. "The needs of the many..."]

Note that, when I say "guru", I do not mean eventual matrix support or use in scientific computing. Those are both important and should be considered in Red's design. Parallelization should also be considered. Guru issues would be things like defining the interface based the ability to generate optimized code. But the double-loop/cartesian-iterator approach from Julia, that @geekyi posted, looks very convenient. The concept also applies to series!, and has been seen as n-foreach in the past.

Range!

Re: range!, it's not clear to me that a lexical form is worth the cost. For those who use them heavily in other langs, what are your most common cases? I only ever see examples like 1..5, where the bounds are fixed integer values. Defining ranges is important, and maybe there is a datatype for them, but without a lexical form (unless someone writes a convincing REP for it).

Responses to comments

MaximV: I feel like we can just copy CL's loop and thats it its a looping dialect which is the most powerful out there

REP 101 matches the basics closely, with less subtle behavior based on keywords (e.g. in vs on). Local vars would be done with use outside the loop (though I'm not keen on that name, it may live on from Rebol). The interesting bit is the addition of value accumulation in the dialect, which is noted as what really sets it apart from do/dolist/dotimes in CL. I have old aggregator funcs that match theirs, but if we add aggregates to Red, they need to be usable outside loops as well.

nc-x: Well, i prefer golang. It has a single looping construct which can be used for everything. Instead of having for, foreach, while, etc etc a single for loop for everything.

DideC: Having different words for different syntaxes, make it easier to remember as our brain is more taillored for that.

My view is that this is something like goto vs for/while/loop. Goto is unlimited in scope and flexibility, but how many of us would give up the constraints looping constructs force on us? Another way to look at it is that we can have very general functions which we compose and curry, specializing them for a given purpose or use. Some loops are more specialized than others, and that's a good thing. As Didier says, different words have different meanings. That said, I don't use forall and forskip much, because I have to think harder about them for some reason (and always seem to flip the skip-num and body args with forskip).

PeterWAWood: I feel that the interface for the proposed function has a level of complexity beyond that of the functions supplied with Red. Its interface falls midway between the "core" functions (insert, copy, until, etc.) and the builtin dialects (view, parse). It doesn't feel to be a natural fit. I also feel that as it is seems to be based in a procedural programming paradigm and whilst it may be familiar to many people, it could also serve to delay a deeper understanding of Red for such people.

1. Function level: This is important because I would like to see more functions at this in-between level. This is what Red is all about. Define a language for a specific purpose. Split is an example. I think format will be like this as well. I think help could be dialected. What about test? CLI? FSM? Cron? We can design these with any kind of interface, and I'm not saying everything should be done this way. Like you, I want Red to be a cohesive whole. So I need to step back and think about the "fit" and what the alternatives are. As a side note, while looking for bug research, I found a chapter in a book that said "COBOL is a terrible language, but the alternatives are so much worse."

2. Procedural model delaying understanding: This one I'm not clear on. Loops are distinctly procedural; got that. The options would be recursion (functional), implicit (as in APL and J), or HOF (map, fold, etc.). What part of understanding Red would for delay?

Closing thoughts

It's good if we can cull obsolete elements, and certainly anything that promotes bad practices or leads to bugs. At the same time, how many people will be turned away from Red if it is too elitist? This is a question for Nenad, which I posed to Carl about Rebol many years ago: Who is the target audience? Haskell, Erlang, Scala, Clojure, etc. have a very different target, and approach than BASICs, including Visual Basic or what we might call "Beginner" languages and tools.

Knowing we can't be all things to all people (and I could tangent about language focus a bit too, another time), how do we let people "Do Red wrong" but still encourage them to do better, and provide the tools to lead them there.

Misc

I do have a format design in the works, which may lead to many of the same questions about complexity and dialected funcs.

References

http://www.gigamonkeys.com/book/loop-for-black-belts.html

http://curecode.org/rebol3/ticket.rsp?id=1993