[M3devel] "target specific pragmas"?

[hendrik at topoi.pooq.com]

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