[bitc-dev] White space

[Jonathan S. Shapiro]

On Mon, Aug 9, 2010 at 10:05 PM, wren ng thornton <wren at freegeek.org> wrote:

> With how ubiquitous lists are in functional languages, I'd think that
> (a::b::c::zs) is preferable to (Cons a (Cons b (Cons c zs))). Are you
> suggesting we say (Pair x y) instead of (x,y) ?
>

Dear God no! You should say (cons x y), or perhaps cons(x,y). Pair(x,y) is
something else entirely. :-)

OK, so I'm punchy this morning, but to illustrate the difference in BitC,
our preamble defines List as the expected union having nil and cons as its
cases. Pair, by contrast is:

unboxed struct Pair<'a,'b> {
  fst: 'a;
  snd: 'b;
}

Note the "unboxed" - in CLR we would say this produces a value type.

But I don't think that eschewing symbolic
> function names is really the solution. That way lies LISP.
>

I guess I straddle the fence on this. There is clear benefit to having
syntactic sugar for the really commonly used types. Lists are a good example
for functional programs (though rarely used any place else). But there is a
reason that strong style conventions for identifiers emerge in large-scale
programming environments, and it is surprising how consistent those style
guidelines are in adopting long identifier names in the interest of clarity.

In short: it's not just LISP. I'm not clear whether the coding conventions
are backed by any science, but there is a *perceived* enhancement of clarity
in preferring identifier names.

My personal opinion is that mixfix is unnatural in most cases, and that
where it works it is a consequence of learned behavior. We read infix math
because we have been taught to do so since grade school. We read the >>
streamIO syntax because it fits with so many other directional indicators in
our lives.

So yes, there is a definite place for syntactic sugar, but only up to a
point.


shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100810/b9bb961c/attachment-0001.html