[M3devel] "target specific pragmas"?

[Darko]

I'm sticking to my view about lexical arbitrariness, but on that  
basis, I'd really like to see an alternate syntax for M3, one that  
looks almost exactly like C, but roughly keeps the existing statement  
form. I think it would make the language much more palatable to C  
programmers and the like and would remove what is a silly barrier to  
broader adaption. We could call the syntax 'Modula-C'.


On 16/02/2008, at 1:18 AM, hendrik at topoi.pooq.com wrote:

> On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote:
>> I don't really question the usefulness of any given feature, just the
>> incremental cost of adding any given feature. One of M3's great
>> strengths is that it is low on features, but the ones it has are
>> powerful and well chosen.
>>
>> The comparison I meant in the typing discussion was between C and M3,
>> not the length of symbols. C is a bit obsessive about source size,
>> which was meaningful back in the day, but today is totally  
>> irrelevant.
>> Even if you don't use macros on your editor, the amount of time spent
>> staring and your code is much greater than the time you spend typing
>> it. You could argue that BEGIN/END is easier to read than {/}
>
> If I had to argue, I'd argue the reverse.  In fact, if it weren't for
> disputes about the number of spaces that are equivalent to a tab and
> such, I'd argue for using indentation and dispensing with BEGIN/END/ 
> {/}
> altogether.
>
> Somewhere I have a C++ program with all the braces left out.  If you
> manage to supply the right braces and get it compiled, you end up
> with a program that will do the job of supplying the right braces.
> I could post it here if anyone in interested in such a curiosity.
>
> There's one language I've seen that goes in the opposite direction.
> Every END is followed by an arbitrary amount of text from the start of
> the construct it closes and a semicolon.  This a WHILE loop starting
>   WHILE toronto == montreal
> could end with
>   END WHILE toronto ==;
> making visual matchin unambiguous.
>
> I've got friends that complain about haveing to type the name if a
> procerure twice in its declaration -- once at the start and once at  
> the
> end.  They say they keep fprgetting to modify both.  But I welcome  
> this
> as a useful check on long-range bracket matching.  Forcing it for
> short-range marching, though, is clutter.
>
> -- hendrik