SPIN syntax, request
ServoM
Posts: 10
Hello all:
This is a request directed at Parallax.
While I find this system, and the SPIN language quite flexible, and vastly more powerful and easier to use than any other microcontroller I have had experience with, the thing I have had the most trouble with, consistently, is the spacing sensitive nature of SPIN.
It is very easy to render a working application broken by means of one deleted or added space. So easy as to be a very serious matter for developers.
Moreover, the printing facility does not seem to be able to print the logic ladder that is shown in the editor, which makes reviewing the printed code essentially useless.
I realize that the spacing sensitive nature of the syntax was done for good reasons, but, can the editor be adjusted so that the logic ladder is optionally (or always) printed when printing the source texts?
Alternatively, if this facility is already in there, and I have missed it, will someone kindly help this one-eyed programmer find it?
Thanks,
Mike
This is a request directed at Parallax.
While I find this system, and the SPIN language quite flexible, and vastly more powerful and easier to use than any other microcontroller I have had experience with, the thing I have had the most trouble with, consistently, is the spacing sensitive nature of SPIN.
It is very easy to render a working application broken by means of one deleted or added space. So easy as to be a very serious matter for developers.
Moreover, the printing facility does not seem to be able to print the logic ladder that is shown in the editor, which makes reviewing the printed code essentially useless.
I realize that the spacing sensitive nature of the syntax was done for good reasons, but, can the editor be adjusted so that the logic ladder is optionally (or always) printed when printing the source texts?
Alternatively, if this facility is already in there, and I have missed it, will someone kindly help this one-eyed programmer find it?
Thanks,
Mike
Comments
You can adjust the tabsize if you increase it or if you use more than two spaces it is easier to see.
Another idea is to make screenshots simply be pressing Alt-Print and paste to an office-document.
If you set the fontsise pretty small you can print a lot of lines on one sheet of paper.
If you take care of another programming-rule: "every method does just ONE (senseful) thing". This will keep the methods short so that it is easy to see what an indented block is doing.
For instance IMHO professional programmers code in a way that they always know what's inside and outside a block.
If you really want to have a loop with multiple indentions hundreds of lines long. Stay in the editor put the cursor into the columm you want to check and move the cursor up and down without changing the columm
then you can see what is inside a block or whats outside.
best regards
Stefan
There are pretty big applications written in Python - and the developers do not have that problem. Why Spin would be different?
Good language design keeps that sort of problem at bay by making it a non-issue. I would imagine that the syntax-directed scanner/parser for the editor must have been a bear to write, so as to ensure consistent presentation. As it is, I find I catch it out pretty often.
While it may appear that I am banging on SPIN a bit, I do want to acknowledge its expressive power and otherwise relative ease of use. Some things are easy to fix; others, not so much, as they are sacrifices to specific constraints.
-M
Not wanting to start a languages war, and being unfamiliar with Python: if Python features a similar syntax, and the assertion is being made that successful, large applications somehow legitimizes this languages' 'feature' of indentation-sensitivity, then I am sorely missing the logic of that statement. Juggling chainsaws is at best messy and at worst, dangerous.
Languages should promote, wherever possible, clean, clear, concise code that compiles/interprets without ambiguity. SPIN does are relatively decent job of that, indentation excepted.
My first reaction to Spin's indentation-sensitive syntax was the same as yours: ugh! But I've since come to like it very much, and I think you will, too. Languages like Spin that are stripped of syntactic gingerbread (i.e. "{" and "}") are lean and clean. But the best part is that more lines of code fit on a screen at one time, making reading and editing much easier. I've not found brace-free indents to be any harder to read than the brace-encumbered indents of, say, Perl. It's just as hard in the latter to tell where the beginning and ending of a block are in a long listing. Also, for editing Spin, be sure to take advantage of the block indent and unindent feature. It does make life easier (although it does have one maddening quirk WHICH HAS YET TO BE FIXED, PARALLAX).
-Phil
Most people who stick with Spin for a while get used to the indentation requirement. Most Spin programs are small, so it is usually not a problem distinguishing the block boundaries. If your code contains lots of imbedded blocks, I would suggest adding comments that delineate the beginning and end of major blocks. This is common practice in other languages -- even languages that use block markers instead of indentation.
Dave
if( PreConditionsInvalid ) return
...is not valid in Spin; you need to make it two lines, taking up more space. I'm used to the indenting in Spin now, and I know it's not going to change, but I've always disliked whitespace sensitive languages. That said, for the OP - you do get used to it pretty quickly. One thing to watch for : the logic ladder hides comment markers if they happen to be in the same column as the indent marks, making it tricky to see if you've commented out a block of code.
'Good point about the one-liners. I hadn't taken that into consideration.
-Phil
The block boundaries are obvious in the C version.
Dave
' Wait from 5 to 15 seconds for input. Print a random fact from ' the vocab table if no input received. PUB WaitForInput | waittime, starttime, ptr1, ptr2, ptr1a, ptr2a, index, count waittime :=((rand // 10) + 5) * clkfreq starttime := GetTicks c.printf0(string("> ")) repeat while (not kbhit) ' Scan all the entries in the vocab table if (GetTicks - starttime > waittime) count := 0 ptr1 := @vocab ptr1a := ptr2a := 0 repeat while (ptr1 < @vocab + size) if ((byte[ptr1][0] & TYPE_MASK) == TYPE_RELATED) ptr1 += 7 elseif ((byte[ptr1][0] & TYPE_MASK) == TYPE_EQUATE) ptr1 += 5 elseif (byte[ptr1][0] & DELETE_MASK) ptr1 += strsize(ptr1) + 3 else ptr2 := ptr1 repeat while (ptr2 := GetNextItem(ptr2)) if (byte[ptr2][0] == TYPE_RELATED) count++ if ((rand // count) == 0) ptr1a := ptr1 ptr2a := ptr2 ptr1 += strsize(ptr1) + 3 ' Print the entry that was randomly selected if (ptr1a and ptr2a) if (byte[ptr2a][0] == TYPE_RELATED) c.putchar(8) c.putchar(8) PrintStatement(ptr1a + 1, ptr2a) c.printf0(string("> ")) waittime :=((rand // 10) + 5) * clkfreq starttime := GetTicks// Wait from 5 to 15 seconds for input. Print a random fact from // the vocab table if no input received. void WaitForInput(void) { int waittime = ((rand() % 10) + 5) * TICKS_PER_SECOND; int starttime = GetTicks(); char *ptr1; char *ptr2; char *ptr1a; char *ptr2a; int index, count; printf("> "); while (!kbhit()) { // Scan all the entries in the vocab table if (GetTicks() - starttime > waittime) { count = 0; ptr1 = vocab; ptr1a = ptr2a = 0; while (ptr1 < vocab+size) { if ((ptr1[0] & TYPE_MASK) == TYPE_RELATED) ptr1 += 7; else if ((ptr1[0] & TYPE_MASK) == TYPE_EQUATE) ptr1 += 5; else if (ptr1[0] & DELETE_MASK) ptr1 += strlen(ptr1) + 3; else { ptr2 = ptr1; while (ptr2 = GetNextItem(ptr2)) { if (ptr2[0] == TYPE_RELATED) { count++; if ((rand() % count) == 0) { ptr1a = ptr1; ptr2a = ptr2; } } } ptr1 += strlen(ptr1) + 3; } } // Print the entry that was randomly selected if (ptr1a && ptr2a) { if (ptr2a[0] == TYPE_RELATED) { putchar(8); putchar(8); PrintStatement(ptr1a+1, ptr2a); printf("> "); } } waittime = ((rand() % 10) + 5) * TICKS_PER_SECOND; starttime = GetTicks(); } } }-Phil
Might be a option to copy paste into such a editor, and print from there.
It's been my experience so far that I would be opening and closing a lot of blocks with the delimiter character, vs just lining code up. For me, I make few "forward create" errors with the indenting, and more with the delimiters. When making changes, the indents can be a source of trouble, and so can the delimiters.
Mostly a net gain with the white space for me.
Overall, my favorite thing about SPIN is that it's lean. At first it wasn't, but once I started using more of the operators, I found the overall amount of typing less.
Sometimes I miss the multi line option. Not often. Sometimes I find that a multi-line can be done with the operators and such too. The more I use those, the more I find I can express some conditional math, or just math in general on one line.
Then there is the problem of BST and Homespun - you need these two editors for "ifdef" conditional compilation statements and these editors don't have the logic ladder/arrows.
For me, the solution came when I started writing big programs that needed external memory. This forced a move to C, and now I'm happily coding in Catalina C doing all the things that Spin can do.
I think others have found a similar solution by moving to PropBasic/Forth etc.
I don't know if the authors of BST and Homespun would be able to look at adding the logic ladder arrows?
-Phil
Another idea is a preparser to allow braces to be used and removed to output the corrected spin syntax. Of course this could be done with another editor and use propellant for the compiler. But I prefer bst or homespun because of the ifdef requirements. I also think macros would be a great addition. Homespun now also has includes.
There's still nothing like a sound LL(1) grammar and a clean recursive descent parser to make me feel warm and fuzzy. Clean, compact, pretty much foolproof in many ways. But, we have what we have, and I am not a SPIN detractor, really. I just think it needs a bit of help with regard to the editor: I can deal with the spacing sensitive nature of SPIN, but it WOULD be nice to be able to print the source text in a way that preserves the ladder diagrams. The suggestion to do a screen shot and print that doesn't work for me, because the Propeller Tool's display can be caught out too many times with those ladder diagrams.
That's the main request: the ability to be able to print the sources with the ladders intact.
-M
In the late 90's I had to print about 9 yards of Intel assembler which I found impossible to follow on screen. Problem was line printer paper was obsolete by then and I ended up sticking sheets of laser printer output together so that I could draw lines all over it that indicated the control flow.
In the this modern world functions and methods tend to be kept short so you can see the whole thing on screen.
I once had a professor who advocated printing out source code weekly and sitting down and reading it. The idea was you'd discover bugs and design mistakes that you never would within a code editor. I never really tried it though, seemed like a real waste of paper.
As far as the space-sensitive nature of SPIN code, my job has evolved me into someone who programs in python 90% of the time. At first I hated using indentation to establish code blocks, but now it seems natural and familiar. I can look at Python code and see block boundaries as easily as I can with C code. The old C curly braces seem unnecessary and distracting to me. Python code looks much like properly-indented C code without the curly braces. In fact, I think Python has helped me to improve the indentation of my C. Most people I've met who are new to Python hate it, just like I did at first. It's just something that takes some getting used to.
Now, whoever setup the <=, >=, =>, and =< operators in SPIN... that's some syntax I could do without.
Have typed in a thing or to as well.
What's really fun is going back through the pile, finding things, and realizing where you've gone since.
I also print out writings of various kinds. It is disturbing to think that the words, once rendered, won't just be there. Maybe that's just me.