[bitc-dev] Surface Syntax (again)

Jonathan S. Shapiro shap at eros-os.com
Thu Feb 26 16:47:16 EST 2009


On Thu, Feb 26, 2009 at 1:43 PM, Pal-Kristian Engstad
<pal_engstad at naughtydog.com> wrote:
> The C-for loop is one construct that I think BitC could do without. I've
> encountered and fixed numerous bugs throughout my career stemming from
> things like:
>
>    for (int i = 0; i < n; j++)
>       do_something(i);
>
> Do you spot the error? How quickly do you spot it?

Yes, and instantaneously. Result of years of practice, and does not
invalidate your point in the slightest.

> The Pascal/Fortran/OCaml approach is to make sure you reference the loop
> variable only once (except in the loop body), and this means less errors
> of the above sort:
>
>    for i = 0 to n - 1 do ...
>    done

Yes. Actually, I was saying to Swaroop just the other day that we
wanted a range iteration construct. The problem with the specific
syntax you give is that it does not generalize very well. I personally
prefer something like:

   for i in 0:n-1 do .. done

which is how Python handles this. The reason I prefer this is that the
notion of range is easily generalized to the notion of set. The
problem with this approach is that it does not handle irregular loops
well (e.g. all *even* slots in a vector), and it has a hard time
dealing with co-induction.

> As an example, if the language had the concept of "generators" (a-la
> Python's yield), then something like this is quite readable:
>
>    {0 .. n-1} |> iter (fun i -> printf "%d\n" i)  // Generate integers
> from 0 to n - 1, and iterate the print function for each element.
>    {1 .. n} |> fold (fun acc i -> acc * i) 1      // Generate integers
> from 1 to n, accumulating the product (i.e. 1*2*...*n).

In many respects I like this approach, and I want to think about this.
My main concern with it is efficient compilation for simple
iterations. I can readily see that the "extra" procedure can generally
be optimized out, but doing so requires a non-trivial amount of
optimizer infrastructure. One attribute that we tried (and failed) to
preserve in BitC was directness of translation/compilation.

> Another interesting idea is to make a distinction between "let rec"
> constructs (that may not be tail-recursive) and loops. For instance, by
> inventing "let loop <label>(<loop-variables>) = ... in":

We already have a separate syntactic construct for loops. The main
reason it exists is the difficulty of inner procedure elimination that
I discuss above.

I am not clear from your description what the distinction between
letrec and let loop is, however. If "let loop" is used, does this mean
that it is *required* for all invocations to be in tail position?
Pardon my ignorance here!

> "Emacs would be a far better OS if it was shipped with
>  a halfway-decent text editor." -- Slashdot, Dec 13. 2005.

Amen.


More information about the bitc-dev mailing list