I guess as long as there is an explicit start with an explicit ending to
both the let block and the let body, I don't care what they are. I would
also like to reject the ability to create a let block within a let block.
BAD:
> let x = 42
> let y = foo;
> in ....
I don't think one should go around creating new scope inside the let block,
if they want to create an inner scope, they can do it in the expression
body. It should be perfectly simple to declare multiple let values in the
same scope: those two ideas would look like
GOOD:
> let
> x = 42;
> bar = 53; < -- hope hope :)
> in
> let y = 99;
> in
> bar (x * y) (x * bar) ;
> end
> end
speaking of which, will inline function definition be allowed?
> define foo x
> let
> bar n = (sqrt (sqrt n))
> in
> bar x
> end
> end
or maybe even a point-free approach:
> let
> bar n = (sqrt . sqrt)
> in ...
It's easier for machines to parse and it's easier for humans to parse.
Given my current repertoire of languages. I'd prefer an option of either
indenting or curly braces to indicate the let body.
I guess that this will be determined by what the convention will serve BitC
as a general body delimiter. The fact that, universally, bodies in ruby are
always defined by either do-end or {-}
is nice.
of course if indentation becomes an option then simply
replace do with chr(32)chr(32)chr(32)chr(32)
and end with chr(8)chr(8)chr(8)chr(8)
(if only it were that easy :))
On Thu, Mar 5, 2009 at 3:20 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Thu, Mar 5, 2009 at 2:12 PM, Rick R <[email protected]> wrote:
> > Sorry I was confused about the issue above. I was reading {} in the block
> > sense, not the EBNF sense.
> >
> >
> > let { BINDING DELIMITER } *
> > in
> > EXPR
> >
> >
> > where DELIMITER is ; or "\n"
> > effectively, "in" would signify the end of the let block. and the
> variables
> > defined in the let block would be scoped only to the let block and EXPR
>
> Once again, this isn't the problem. The "in" signals the end of the
> binding patterns, not the let block. The question at hand is: what
> signals the end of the let *body*?
>
> I'm re-learning lessons in the challenges of writing clear email about
> this sort of thing. ;-)
>
> > and EXPR has something to signify the beginning and end of its scope.
> > In code it would look like (modifying Zorg's example)
> >
> > let light_pos = [|-20.0; 20.0; 10.0; 1.0|];
> > angle = 42.0;
> > light_diffuse = [|1.0; 1.0; 0.9; 1.0|];
> > light_specular = [|1.0; 1.0; 0.9; 1.0|];
> > light_ambient = [|0.15; 0.15; 0.15; 1.0|];
> > light_normal = (normalize light_pos) * angle
> > in
> > {
> > glLightfv gl_light0 gl_position light_pos;
> > glLightfv gl_light0 gl_diffuse light_diffuse;
> > glLightfv gl_light0 gl_specular light_specular;
> > glLightfv gl_light0 gl_ambient light_ambient;
> > }
>
> Okay. I agree that this works syntactically. I note that if the "{" is
> mandatory then the "in" is syntactically redundant.
>
> Just so I am clear, are you specifically advocating curly braces, or
> would you find in/end acceptable as an alternative?
>
>
> shap
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
--
We can't solve problems by using the same kind of thinking we used when we
created them.
- A. Einstein
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
