I'm not sure I'm right to ask this but here goes...
Is using indenting an apparently good idea that has some unexpected
downside? I'm trying to think of scenarios where indenting to delimit
blocks might be better done with explicit language tokens. The only
thing I can think of it in a generation of code, using preprocessors,
macros, having to rewrite behind-the-scenes, etc.
For example, I use a system where some code
x := 1
Would be rewritten just prior to execution, invisibly to the
programmer, like this:
function()
{
x := 1
}
This could cause a minor but nagging problem when syntactic errors were
reported:
x =: 1 // illegal!
would obviously be considered by the programmer as having a syntax
error on line 1 whereas when it was rewritten and actually executed it
would be reported on line 3.
This was made worse by some error trapping try/except code we had to
introduce to get around bugs in the underlying framework, something
like:
function()
{
try
{
x =: 1
}
finally
// stuff here
// and the rest
This would be easily cured by inlining everything like this:
function() { try { x =: 1 } finally // and the rest
But you can't do this with block-delimit-by-indent.
I've used M4 to partly automate compiler test suite generation and I
would not wish to deal with an indented syntax in such a case either.
It's just easy to stick { and } around things as necessary.
I understand that BitC is not going to have macros of any sort as part
of the language, so that at least is not an issue, but as you can see
from the above, weird hacks sometimes stick their heads up.
Therefore, can anyone see any situation down the line where indented
code can cause problems?
It should be easy to answer because there is plenty of experience here
with indented languages (I have none though).
Yes, I know, it's a trivial question likely with a trivial answer but I
think it needs asking.
jan
>
>In the 1st case, at the closing curly brace. In the 2nd, at the next Dedent.
>
>
>On Thu, Mar 5, 2009 at 1:25 PM, Jonathan S. Shapiro <[email protected]>wrote:
>
>> Rick:
>>
>> You have the issue backwards. When does the let block END?
>>
>> On Thu, Mar 5, 2009 at 1:03 PM, Rick R <[email protected]> wrote:
>> > I rather like
>> > let { binding and binding and binding in EXPR}
>> >
>> > or let binding
>> > binding
>> > binding
>> > in EXPR
>> >
>> >
>> > This leaves no question in the reader's mind about the scope of the
>> > variables. It is explicit that all variables share the same scope, which
>> is
>> > the intent here, isn't it?
>> >
>> > If you want nested levels of scope, then put another let block in the
>> EXPR.
>> >
>> > This is basically Haskell syntax, perhaps I'm already showing by bias.
>> >
>> >
>> > On Thu, Mar 5, 2009 at 12:36 PM, Jonathan S. Shapiro <[email protected]>
>> > wrote:
>> >>
>> >> Binding forms that introduce inner scopes should be distinct from
>> >> those that merely append definitions to the current scope. I do
>> >> understand that appending actually does introduce a new scope. The
>> >> issue is that in one type of form the scopes end in the same place,
>> >> where in the other they do not.
>> >>
>> >> I'm currently inclined to favor a syntax very similar to OCaml:
>> >>
>> >> let BINDING { and BINDING } in EXPR end
>> >>
>> >> and other forms similarly.
>> >>
>> >>
>> >> Strong objections or alternatives?
>> >> _______________________________________________
>> >> 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
>> >
>> >
>> _______________________________________________
>> 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
>
>--000e0cd32872b7a103046463bee7
>Content-Type: text/html; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>In the 1st case, at the closing curly brace. In the 2nd, at the next Dedent=
>.<br><br><br><div class=3D"gmail_quote">On Thu, Mar 5, 2009 at 1:25 PM, Jon=
>athan S. Shapiro <span dir=3D"ltr"><<a href=3D"mailto:[email protected]";>=
>[email protected]</a>></span> wrote:<br>
><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
>204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Rick:<br>
><br>
>You have the issue backwards. When does the let block END?<br>
><div><div></div><div class=3D"h5"><br>
>On Thu, Mar 5, 2009 at 1:03 PM, Rick R <<a href=3D"mailto:rick.richardso=
>[email protected]">[email protected]</a>> wrote:<br>
>> I rather like<br>
>> =A0 let { binding and binding and binding in =A0EXPR}<br>
>><br>
>> or let binding<br>
>> =A0 =A0 =A0 =A0 binding<br>
>> =A0 =A0 =A0 =A0 binding<br>
>> =A0 =A0 =A0 =A0 in EXPR<br>
>><br>
>><br>
>> This leaves no question in the reader's mind about the scope of th=
>e<br>
>> variables. It is explicit that all variables share the same scope, whi=
>ch is<br>
>> the intent here, isn't it?<br>
>><br>
>> If you want nested levels of scope, then put another let block in the =
>EXPR.<br>
>><br>
>> This is basically Haskell syntax, =A0perhaps I'm already showing b=
>y bias.<br>
>><br>
>><br>
>> On Thu, Mar 5, 2009 at 12:36 PM, Jonathan S. Shapiro <<a href=3D"ma=
>ilto:[email protected]">[email protected]</a>><br>
>> wrote:<br>
>>><br>
>>> Binding forms that introduce inner scopes should be distinct from<=
>br>
>>> those that merely append definitions to the current scope. I do<br=
>>
>>> understand that appending actually does introduce a new scope. The=
><br>
>>> issue is that in one type of form the scopes end in the same place=
>,<br>
>>> where in the other they do not.<br>
>>><br>
>>> I'm currently inclined to favor a syntax very similar to OCaml=
>:<br>
>>><br>
>>> =A0let BINDING { and BINDING } in EXPR end<br>
>>><br>
>>> and other forms similarly.<br>
>>><br>
>>><br>
>>> Strong objections or alternatives?<br>
>>> _______________________________________________<br>
>>> bitc-dev mailing list<br>
>>> <a href=3D"mailto:[email protected]";>[email protected]</a><b=
>r>
>>> <a href=3D"http://www.coyotos.org/mailman/listinfo/bitc-dev"; targe=
>t=3D"_blank">http://www.coyotos.org/mailman/listinfo/bitc-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> We can't solve problems by using the same kind of thinking we used=
> when we<br>
>> created them.<br>
>> =A0 =A0- A. Einstein<br>
>><br>
>> _______________________________________________<br>
>> bitc-dev mailing list<br>
>> <a href=3D"mailto:[email protected]";>[email protected]</a><br>
>> <a href=3D"http://www.coyotos.org/mailman/listinfo/bitc-dev"; target=3D=
>"_blank">http://www.coyotos.org/mailman/listinfo/bitc-dev</a><br>
>><br>
>><br>
>_______________________________________________<br>
>bitc-dev mailing list<br>
><a href=3D"mailto:[email protected]";>[email protected]</a><br>
><a href=3D"http://www.coyotos.org/mailman/listinfo/bitc-dev"; target=3D"_bla=
>nk">http://www.coyotos.org/mailman/listinfo/bitc-dev</a><br>
></div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>We can'=
>t solve problems by using the same kind of thinking we used when we created=
> them. <br> =A0 =A0- A. Einstein<br>
>
>--000e0cd32872b7a103046463bee7--
>
>--===============0962580977==
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>_______________________________________________
>bitc-dev mailing list
>[email protected]
>http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>--===============0962580977==--
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
