[bitc-dev] Syntax Poll: Scoping Syntax

Rick R rick.richardson at gmail.com
Thu Mar 5 15:49:58 EST 2009


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 <shap at eros-os.com>wrote:

> On Thu, Mar 5, 2009 at 2:12 PM, Rick R <rick.richardson at gmail.com> 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
> bitc-dev at coyotos.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20090305/8de06619/attachment.html 


More information about the bitc-dev mailing list