[M3devel] "target specific pragmas"?

[Jay]

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!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080215/0b3d1849/attachment-0002.html>