[M3devel] "target specific pragmas"?

Tony Hosking hosking at cs.purdue.edu
Fri Feb 15 17:15:59 CET 2008


The directions of these postings are off-topic for the m3devel  
mailing list.  Let's try to get back to questions of Modula-3  
development.

On Feb 15, 2008, at 10:10 AM, Jay wrote:

> Having written a bit of Python..really just a bit..you are all  
> privy to ALL of the Python I have ever written...I'll bite.
>
> It's fairly obvious once you write a bit of Python what goes on here.
>
> First, we all know that we all strive to indent things "correctly".
> Now, "correctly" can vary somewhat, but the intent is universal.
> Deeper lexical nesting goes with increased indentation.
> You can pick the indent size, spaces vs. tabs, where the braces/ 
> begin/end go, but it's still the same intent.
>
> Now, when paired with begin/end or braces, you end up with a large  
> duplication of information.
> The one the compiler uses only and the ones human use more.
> You get to keep them in sync. Your editor might help a lot.
>
> What Python does is merely throw out half the data, and require  
> some consistency on your part for what in other languages the  
> compiler ignores.
> I don't know the exact rules, but they are probably easy to think of.
> That is, it could easily allow either spaces or tabs.
>
> This approach is not bad. But I have two problems:
> 1) again, my editor
> 2) it's a little wierd and hard to see when you have a whole lot of  
> closes in a row
>
>   if
>      print
>      if
>        print
>        if
>          print
>   nothing here
>
> vs. either C or Modula-3.
> Perhaps a better approach is to require "end" and require  
> consistent indentation.
> Python also can't cope with an empty statement because of this plus  
> its lack of semicolons.
> You have to say "pass". That's a bit of an indictment.
>
> As to tabs, the answer is very easy. Never ever use them.
> Lots of folks use 4 space tabs, lots of folks use 8 space tabs.
> I used to be a 4 space tab guy, but I gave up tabs a few years ago.
> The Cygwin code uses 8 space tabs and is therefore unreadable to me.
> (I could change my editor setting, and since the 4 space tabs are  
> pretty rare now, ok.)
>
> To those who suggested emacs for convenient Modula-3 editing,  
> sorry, it's not likely going to happen.
> I have tried vi and emacs multiple times through the years and I  
> can't use either.
> I use vi just for editing commit comments, which are often pasted  
> in to the console from notepad anyway.
>
> My "problem" is that I make heavy use of the arrows, home, end,  
> page up, page down, control, and shift.
> (control can "accelerate" arrows, shift is used for selecting).
> And some other ingrained keyboard short cuts like control-f, F3, etc.
> I use Visual C++ 5.0 and its support for these keys, plus a little  
> bit of support for indentation, is excellent.
> It could be that the newer versions are better, and I would like  
> find-and-REPLACE in files, and support for unicode files, but these  
> aren't worth it so far. Oh, and the find-in-files, minus a replace  
> option, is excellent, just super duper, I use it constantly.  
> Nothing else compares.
>
> The only people I try to get to change editors is people that use  
> notepad.
>
> On PPC_DARWIN I make do with TextWrangler. It is ok. (From the  
> BBEdit folks).
> On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok.
>
> If anyone out there is struggling with too-basic editors such as  
> TextEdit or whatever it's called these days, I'd recommend trying  
> these. But if you are already using a "programmer's editor", I'll  
> leave you alone. :)
> If anyone knows of something more comparable to Visual C++ 5.0 on  
> other platforms, I'm eager to hear.
> (Maybe under Wine? But that requires x86 I think..)
>
> Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows),  
> but it starts up slowly on Windows, crashes a bit on Windows, and  
> isn't being updated..
>
> (Trying for "gentle advise" not "advocacy" here.)
>
> > > incremental cost of adding any given feature. One of M3's great
>
> I think the problem is more of multiplication than increment.
> How do the features interact with each other?
> Two features interact very very well -- destructors and exceptions.
>   And constructors in that mix.
> Otherwise not certain.
>
>  > C is a bit obsessive about source size,
>
> There used to be an assembler that used tabs and a competitor that  
> used spaces.
> The tab guy advertised his much smaller files. :) And I think  
> therefore faster assembling.
> Well, definitely much faster assembling either way, probably not  
> because of or only because
> of the tabs.
>
> Yes I have that problem with procedures. And modules, and interfaces.
> This is where my editor and braces excel. You need to sprinkle in  
> the matching text.
> You type control-brace on a brace and it shows you the matching one.
> Some editors do this just by moving the cursor across a brace (or  
> paren).
>
>  - Jay
>
>
>
> > Date: Fri, 15 Feb 2008 09:18:19 -0500
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] "target specific pragmas"?
> >
> > 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
>
>
> Shed those extra pounds with MSN and The Biggest Loser! Learn more.




More information about the M3devel mailing list