A common subset of Spin, Spin2, etc. should be defined that includes basic things like CON, VAR, OBJ, and much of PRI and PUB syntax. Spin, Spin2, and any other spin variant (such as the x86 Spin people like Heater IIRC and myself have considered) should all comply with this basic subset. Stuff like register bit ranges (e.g. outa[21..13]) and I/O should be extensions to this basic subset, as well as features relying on the P-code nature of the PNUT interpreter (for function pointers and coroutines and stack trickery and such). That way, simpler pure Spin objects that don't directly do any I/O, such string manipulation objects and serial protocol objects that just talk to FDS but don't actually do the I/O themselves, will be compatible between different versions of Spin.
This sounds good. One would expect the PASM part of Spin to be different between P1 and P2 but the high-level language syntax should be the same or at least backward compatible.
I realize that the underlying issue here is going to be a much bigger conversation, but let's get back to the original request.
Chip,
Will you please update pnut.exe for P2 to use ".spin2" or similar filename extension (and update your sample files to match). If you also want to add a pragma, that's fine too. Just as long as there's something that can be reliably used to distinguish P2 files from P1 files.
I like the idea of using an intrinsic function, such as Phil's ifelse() function, to implement the ternary expression. It's sort of a special case of the instrinsic lookup function. cspin implements the C expression "a = b > 1 ? c : d;" as "a := lookupz(-((b > 1) == 0) : c, d)". A special lookupl() or ifelse() function could be used instead. Maybe it could just be a variation on the lookup and loopupz function, where it uses a base of -1, instead of 1 or 0.
The ternary expression using the ? operator is pretty common across many languages. Using some oddball thing would be non-standard and more confusing.
Confusing to whom, though? Novice programmers who've never seen the ternary operator? And experienced programmers should have no trouble adjusting to a new syntax.
In any event, I do not want to see the "?" go away as Spin's random operator. A question mark is a total natural for expressing randomness. And it's too far embedded in Spin's culture to be discarded.
Phil, complete non-coders using Arduino have the ? ternary operator.
Using the newb arguement is lame here. Newbs will read the docs or get help from others. Once they have the info it's all good.
You beloved Perl has it, and it even allows it to be used on the L-value side of all things. I'm surprised you aren't championing it on that case alone... :P
You're right about Perl's use of ... ? ... : ... And I'm totally comfortable using it there. Cripes! I LOVE that construct and use it all the time. But I'm not a slave to convention. Let's face it: Perl and C are both difficult languages to learn. Anything that gets a newb accelerating up the entrance ramp to any language is a plus. And if a different, friendlier syntax is what it takes, I'm totally for it!
I realize that the underlying issue here is going to be a much bigger conversation, but let's get back to the original request.
Chip,
Will you please update pnut.exe for P2 to use ".spin2" or similar filename extension (and update your sample files to match). If you also want to add a pragma, that's fine too. Just as long as there's something that can be reliably used to distinguish P2 files from P1 files.
The ternary operator is great in Spin, because it gets around all the indention and lines needed to do normal if-then-else constructs. And because it can be used in assignments, it makes for more efficient code.
The way fastspin does it is certainly easy to read. And even though if and else are overloaded, their context as part of an expression is well-established before they're encountered, so it should be easy to parse.
BTW, Roy, is there a formal grammar for Spin?
-Phil
You can already do things like a := b+++c. It looks ambiguous, but (according to BST at least) it is, in fact, valid, and it compiles to a := b++ + c. I don't see why a := b ? ? c : d should be illegal. Just pick one of the two possible interpretations as the correct one - I'd say that it should compile to a := b ? (?c) : d, because that's probably more useful.
On the other hand, the parser system I invented for my compile-time-extensible Spin compiler that I never finished would probably give an ambiguous operator error if it came across this, while it would compile the +++ thing just fine (since the lexer, and not the parser, would deal with it).
The ternary operator is great in Spin, because it gets around all the indention and lines needed to do normal if-then-else constructs.
Yes, that's a nice operator, the ternary op.
I've also wished to be able to have a statement immediately following an if-statement on the same line, and also missed being able to put multiple statements on the same line separated by semicolons. For example:
if timeExpired ringBell
if a < b x := 3; y := 6; z := 8
setTemp; turnOnHeater; turnOnStirrer
I realize some will protest due to readability concerns, but I feel having related code on one line can be more readable (and enjoyable to write) and easier to view (it saves a lot of vertical space). Whether to use such features or not partly depends on how the code would be commented, I realize. Anyway, in the case of being able to use the semicolon between statements, one wouldn't have to take advantage of it if one didn't want to; it'd be up to the coder (though one might have to read code from others using that style). I assume that the semicolon would parse well for the compiler. I'd probably make a final semicolon optional, if feasible. In the case of an if-statement with one or more statements afterwards on the same line, I'm not sure if it'd be good to still allow indented statements on succeeding lines or not, but I guess so. Anyway, I'm just dreaming.
I and most coders I have worked with are the exact opposite of you on this one. Compacting code like that makes it harder to read, harder to maintain, and more prone to inducing bugs when modified.
Also, the whole optionally use a semicolon or not thing is just right out! It complicates an already complex parsing mechanism for no real benefit. Just NO! Like seriously, I will not write/port that parsing code. Either you bring in the whole scoping mechanism with curly braces and require the semicolon on every statement and remove the scope by indenting mechanism, or you don't do any of that and stick with the indenting mechanism for scoping.
Readability is arguably more important than writeability when it comes to code: For any piece of code, you write it only once, but there's no limit to how many times it can be read - including by yourself. So, to conclude that line of reasoning, it is more important that the code is enjoyable to read than that it is enjoyable to write..
(And it is many times more complicated to debug software than to write it, so it follows that if you write as complex code as you can mentally handle you will not have the mental capacity to debug it later, when it doesn't work. So keep it as easy to understand as possible.)
I'm not sure I contribute anything by this, but I enjoy code...
Readability is arguably more important than writeability when it comes to code: For any piece of code, you write it only once, but there's no limit to how many times it can be read - including by yourself. So, to conclude that line of reasoning, it is more important that the code is enjoyable to read than that it is enjoyable to write..
(And it is many times more complicated to debug software than to write it, so it follows that if you write as complex code as you can mentally handle you will not have the mental capacity to debug it later, when it doesn't work. So keep it as easy to understand as possible.)
I'm not sure I contribute anything by this, but I enjoy code...
Compacting code like that makes it harder to read, harder to maintain, and more prone to inducing bugs when modified.
"Compacting" the code is as good a word for it as any, I guess. Anyway, thanks, guys, for the thought-provoking comments. I figured prior to posting where most of you would stand, but I tossed the idea out there anyway (before ducking and running for cover). Guess I'll have to wait for a possible port of JavaScript to the P2 from Heater to get my semicolon fix. Okay, carry on; I'm still happy about the ternary operator.
Ternary is fine with me too. It's readable and compact at the same time. The concern is when it's made more complex than a simple a := b? c:d
ersmith's variant is also quite good.
I don't see why a := b ? ? c : d should be illegal. Just pick one of the two possible interpretations as the correct one - I'd say that it should compile to a := b ? (?c) : d, because that's probably more useful.
Hmm. Good point!
Now I wonder (and I'm not going out to my shop at this late hour to try it), does a := b?? compile? IOW, does the expression's L-value get preserved so that ? can be applied again?
I don't see why a := b ? ? c : d should be illegal. Just pick one of the two possible interpretations as the correct one - I'd say that it should compile to a := b ? (?c) : d, because that's probably more useful.
Hmm. Good point!
Now I wonder (and I'm not going out to my shop at this late hour to try it), does a := b?? compile? IOW, does the expression's L-value get preserved so that ? can be applied again?
-Phil
According to BST, a := b?? does not compile (even with a space), but a := ?b? does (but it compiles to the same bytecode as a := b?, so I think this is a bug).
For P2, I prefer to use PropTool for editing as it highlights in colors. I just then save the file (important not to forget this) and then reload the file with pnut (also important not to forget this) and compile and download for testing.
With ".spin2" files, PropTool of course no longer colors the screen when editing.
I am not so sure if .spin2 files are such a good idea, at least for while we test the P2 FPGA ???
For P2, I prefer to use PropTool for editing as it highlights in colors. I just then save the file (important not to forget this) and then reload the file with pnut (also important not to forget this) and compile and download for testing.
With ".spin2" files, PropTool of course no longer colors the screen when editing.
I am not so sure if .spin2 files are such a good idea, at least for while we test the P2 FPGA ???
I'll try to get the VSCode extension updated this evening, so you will be able to use that. Then you will have syntax highlighting for the full P2 instruction set.
I'll try to get the VSCode extension updated this evening, so you will be able to use that. Then you will have syntax highlighting for the full P2 instruction set.
*sigh* ran out of time this evening. competing in an out of town regatta tomorrow. I'll try again tomorrow evening...
For P2, I prefer to use PropTool for editing as it highlights in colors. I just then save the file (important not to forget this) and then reload the file with pnut (also important not to forget this) and compile and download for testing.
With ".spin2" files, PropTool of course no longer colors the screen when editing.
I am not so sure if .spin2 files are such a good idea, at least for while we test the P2 FPGA ???
I'll try to get the VSCode extension updated this evening, so you will be able to use that. Then you will have syntax highlighting for the full P2 instruction set.
That would be so nice. Just let us know when its done.
BTW IIRC Sapieha did a highlighter for Notepad++ and P1.
I have this one I made for Notepad++ with .spin and .spin2 file extensions. The "{{ }}" comment braces don't work quite right, but most everything else does.
Change the extension from .txt to .xml before importing.
Edit: It targets P2, so there could be some P1 keywords missing.
Ok. I had a few hours while on the road this morning to extract the syntax portion of the extension that I'm working on. To install in VSCode, unzip the attachment into your %userprofile%/.vscode/extensions folder.
Comments
Chip,
Will you please update pnut.exe for P2 to use ".spin2" or similar filename extension (and update your sample files to match). If you also want to add a pragma, that's fine too. Just as long as there's something that can be reliably used to distinguish P2 files from P1 files.
The alternate way (Verilog style) is harder to read, which is partly why I don't like C.
In any event, I do not want to see the "?" go away as Spin's random operator. A question mark is a total natural for expressing randomness. And it's too far embedded in Spin's culture to be discarded.
-Phil
To whom? I like RND and feel totally natural typing it
Using the newb arguement is lame here. Newbs will read the docs or get help from others. Once they have the info it's all good.
You beloved Perl has it, and it even allows it to be used on the L-value side of all things. I'm surprised you aren't championing it on that case alone... :P
You're right about Perl's use of ... ? ... : ... And I'm totally comfortable using it there. Cripes! I LOVE that construct and use it all the time. But I'm not a slave to convention. Let's face it: Perl and C are both difficult languages to learn. Anything that gets a newb accelerating up the entrance ramp to any language is a plus. And if a different, friendlier syntax is what it takes, I'm totally for it!
Don't forget that "?" is both a prefix and a postfix operator in Spin. How's your comfort level now?
-Phil
I'll do it.
You can already do things like a := b+++c. It looks ambiguous, but (according to BST at least) it is, in fact, valid, and it compiles to a := b++ + c. I don't see why a := b ? ? c : d should be illegal. Just pick one of the two possible interpretations as the correct one - I'd say that it should compile to a := b ? (?c) : d, because that's probably more useful.
On the other hand, the parser system I invented for my compile-time-extensible Spin compiler that I never finished would probably give an ambiguous operator error if it came across this, while it would compile the +++ thing just fine (since the lexer, and not the parser, would deal with it).
I've also wished to be able to have a statement immediately following an if-statement on the same line, and also missed being able to put multiple statements on the same line separated by semicolons. For example:
if timeExpired ringBell
if a < b x := 3; y := 6; z := 8
setTemp; turnOnHeater; turnOnStirrer
I realize some will protest due to readability concerns, but I feel having related code on one line can be more readable (and enjoyable to write) and easier to view (it saves a lot of vertical space). Whether to use such features or not partly depends on how the code would be commented, I realize. Anyway, in the case of being able to use the semicolon between statements, one wouldn't have to take advantage of it if one didn't want to; it'd be up to the coder (though one might have to read code from others using that style). I assume that the semicolon would parse well for the compiler. I'd probably make a final semicolon optional, if feasible. In the case of an if-statement with one or more statements afterwards on the same line, I'm not sure if it'd be good to still allow indented statements on succeeding lines or not, but I guess so. Anyway, I'm just dreaming.
Ugh deluxe edition!
I and most coders I have worked with are the exact opposite of you on this one. Compacting code like that makes it harder to read, harder to maintain, and more prone to inducing bugs when modified.
Also, the whole optionally use a semicolon or not thing is just right out! It complicates an already complex parsing mechanism for no real benefit. Just NO! Like seriously, I will not write/port that parsing code. Either you bring in the whole scoping mechanism with curly braces and require the semicolon on every statement and remove the scope by indenting mechanism, or you don't do any of that and stick with the indenting mechanism for scoping.
(And it is many times more complicated to debug software than to write it, so it follows that if you write as complex code as you can mentally handle you will not have the mental capacity to debug it later, when it doesn't work. So keep it as easy to understand as possible.)
I'm not sure I contribute anything by this, but I enjoy code...
+1
"Compacting" the code is as good a word for it as any, I guess. Anyway, thanks, guys, for the thought-provoking comments. I figured prior to posting where most of you would stand, but I tossed the idea out there anyway (before ducking and running for cover). Guess I'll have to wait for a possible port of JavaScript to the P2 from Heater to get my semicolon fix. Okay, carry on; I'm still happy about the ternary operator.
ersmith's variant is also quite good.
Now I wonder (and I'm not going out to my shop at this late hour to try it), does a := b?? compile? IOW, does the expression's L-value get preserved so that ? can be applied again?
-Phil
According to BST, a := b?? does not compile (even with a space), but a := ?b? does (but it compiles to the same bytecode as a := b?, so I think this is a bug).
For P2, I prefer to use PropTool for editing as it highlights in colors. I just then save the file (important not to forget this) and then reload the file with pnut (also important not to forget this) and compile and download for testing.
With ".spin2" files, PropTool of course no longer colors the screen when editing.
I am not so sure if .spin2 files are such a good idea, at least for while we test the P2 FPGA ???
I'll try to get the VSCode extension updated this evening, so you will be able to use that. Then you will have syntax highlighting for the full P2 instruction set.
*sigh* ran out of time this evening. competing in an out of town regatta tomorrow. I'll try again tomorrow evening...
BTW IIRC Sapieha did a highlighter for Notepad++ and P1.
Change the extension from .txt to .xml before importing.
Edit: It targets P2, so there could be some P1 keywords missing.