Isn't that more or less the same as "0 !< x !> 10" ? Or what if you did "0 <# x #> 10"? Oh, isn't that already what we have?
Dave, did you try running that before you posted? I did:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
sio : "Parallax Serial Terminal"
PUB start | i
sio.start(9600)
repeat i from -5 to 15
sio.dec(0 <# i #> 10)
sio.char(13)
I stand corrected. That does work. I know because I tried it:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
sio : "Parallax Serial Terminal"
PUB start | i
sio.start(9600)
repeat i from -5 to 15
sio.dec(0 #> i <# 10)
sio.char(13)
Chip,
I think for in Spin, just go with the operators as you discussed. I think it's fine. We can make whatever named functions we want out of them. I think it's actually best to have them be operators, so the names remain available for functions.
The thing that needs fixing is the PASM instructions. MIN and MAX are just wrong for those.
The usual min/max functions are reversed if you want to limit in a range.
They are okay to find the min or max, but not if you want to clip to min, max.
It's the opposite meaning, that's why you never find one set of operators, or function names for both cases.
...offends people because of their past experience, always seeing...
You are so right.
We all come at these things from different backgrounds and experiences. Even if they are not related to programming languages. What is blindingly obvious to one is cryptic gibberish to another.
At the end of the day pretty much anyway to express anything works and is not logically any better or worse than any other. Provided you are not looking at it with preconceived ideas.
That's why language wars are so much fun! White space delimiting vs braces, semicolons or not, this operator symbol or that. It's interesting to see where people come from in that respect. (I'm mean really "REM" for comments, what century is this? )
This is unique though. A language war over a language that does not exist yet.
It is said that "A camel is a horse designed by a committee." We trust you to come up with something that is not committee soup! Even if it does not please all committee members.
(Hmm...I think that's a bit hard on Camels, considering the very different environment they have evolved to live in).
That's why language wars are so much fun! White space delimiting vs braces, semicolons or not, this operator symbol or that. It's interesting to see where people come from in that respect. (I'm mean really "REM" for comments, what century is this?
It's for sure the previous century since I am 45 .... and it stared from the ages of commodore 64 when I was 12 .... but beside being used in most if not in all the BASICs (including the modern ones) it is also used in batch scripts on windows platforms, also today.
And this is the reason that when I see REM the first thing I think of is comment. If it's not then I need to google for it. But even today if you google for rem statement or rem command or rem instruction the first thing that comes out is comment.
Sadly I'm too old to be of the C64 generation. My first experience of programming was BASIC in 1973 or so, on a mainframe far away over a 300 baud serial connection.
So, yeah, I know were REM comes from. Deep in the foggy past of computing history.
As for REM in Windows BAT files. I have not done any of that since 1998. We have had Linux since then!
Having said that, I'm not so sure I like "REM" being repurposed for "remainder". "REM" is just ugly whatever it's supposed to mean.
Dave, did you try running that before you posted? I did:
sio.dec(0 <# i #> 10)
And I get all 10s in the output.
All of this confusion nicely illustrates exactly the problem with glyphs...
The code by Jason posted back in page 8, was this
What confusion? Read from left to right - Elev equals 1000 less than or equal to Elev, Elev less than or equal to 2000. The hardest part of that is memorizing the meaning of a few (what 6? 8? 10?) symbols. The only thing I can come up with that might be clearer would be Elev := 1000 #v Elev ^# 2000 or Elev := 999 v Elev v 2001, and they are only marginally better.
Honestly, I don't know why we even bother with the "or equal" part. Greater than 999 and less than 2001 works just as well. Can anyone come up with a case where the "or equal" part is essential?
The hardest part of that is memorizing the meaning of a few (what 6? 8? 10?) symbols.
Yep, that is 6? 8? 10? too many symbols to have to remember.
Especially for those that use a dozen other languages that have their own cryptic symbols. Which can be very similar but have totally different meaning.
How about we forget the ASCII restrictions? Spin supports Unicode to some extent. We could enter the modern era by adopting some of the millions of Unicode symbols. We could write, for example:
x := 10 💩 x 😉 20
It's just some symbols to remember, right?
Twitter people could then be able to write software!
Way back, when I was first confronted with SPIN, it took an hour to understand a couple of the demo programs.
Then, came one with an involved expression. Graphics_demo.spin has a couple used to generate color data, as an example.
It took another hour to look them up, write what the expression did, plug raw values in to confirm.
There were several more hours to come. But, it was possible to write programs fairly quickly at that point.
Over the years, those expressions triggered many, how do color and tiles work questions. At one point, I wrote some code without them, creating methods for those tasks.
Fewer questions have come since. When I post from desktop, It's in my signature.
In PASM, similar things happened. The simple path got people on board more quickly, but also did limit what can happen.
On P1 SPIN, those expressions are fast. And, one can pack a whole little program into them too. Very obtuse, but tight, fast, memory lean. On P1, this really matters!
P2 SPIN will be faster as byte code, and faster still compiled.
I'll bet the same dynamics come up though.
P2 will bring more of everything, but the scope of tasks will increase too. Bigger buffers, faster signals, etc...
At one point baggers crammed a level of WOLF3D into a P1, SPIN plus PASM. I remember having to pull out my reference card to parse that program.
Nice that he was able to write that program. This is why we need to remember why some things in SPIN are the way they are. Chip tends to optimize toward this kind of thing being possible.
Whatever we do with SPIN 2, I feel strongly about it performing like P1 SPIN does.
Making compact, fast, powerful expressions is a part of that. When those get written, it's very likely most everyone will need to review before understanding that code.
OK fine.
Designing that away runs the cost and risk of also designing the performance, size and ease away too.
Doing that is a mistake.
On this byte code version of SPIN, doing things in some less than orthodox way, will make great sense in the context of the hardware, assembly language. Taken as a whole, it will make great sense. This should be primary.
I see it much like I do the interrupt events. It's there, and when needed, welcome. Those will very significantly improve on the scope of possible tasks P2 can do well.
A fast, compact, flexible, raw SPIN 2 will do the same.
This is part of the sauce that people value. And when they experience it, they tend to be productive and have fun.
Not all people, and it's fine. Absolutely nothing prevents others from bringing their vision to the table too.
But, we have a lot of P1 users, who will expect these dynamics to be here on P2, enhanced, but not designed away.
So function names? How about for math? Get rid of those nasty symbols and use add, subt, mult, div, exp, and so on?
Well....no.
I like to think that anybody who ever made it to high school was taught some basic arithmetic. As such "+", "-", "×", "÷" and others have been ingrained in our culture for some thousand years or whatever. Even if you know nothing of programming they should be immediately recognizable.
That is why languages like FORTRAN and BASIC etc were invented in the first place. To get away from the cryptic mnemonics of assembler that programmers used and provide a language that normal people could understand.
Sadly the guys that specified ASCII saw fit to ignore "×", "÷" so we don't have it in the character set or on our keyboards. But "*" and "/" are close enough as to be obvious.
Then there is the other big mistake that many languages make. Using "=" as an assignment. Which is not what it means in mathematics.
Then we get into all the other weird, cryptic, operators that programming languages have introduced over time.
Mind you, it seems high school kids today don't get taught how to do arithmetic or read and write much. That is why we need things like Blockly.
Those ASCII designers decided to use "." for the decimal point. Which meant it could no longer be used as a multiply operator as anyone who has done high school maths might expect. So we are stuck with "*".
I doubt that the ASCII designers were the cause of * and /. (Extended ASCII actually includes × and ÷.) No, we have Herman Hollerith to "blame." His code was adopted by IBM for their punch cards, then along came Fortran, which used * and /. The rest is history.
But IBM did not sit on a small character set for long, for then came APL. It had a huge set of cryptic operators (which operated right-to-left). An APL program looked almost runic. Keith's keyboard above shows some of the symbols used by APL. Here's a sample APL program:
Kinda makes interpreting Spin code seem like reading an English primer by comparison, doesn't it?
My mom had to take a programming class as part of her MBA program, and got stuck learning APL. As far as I know she never used it after passing that class.
I like to think that anybody who ever made it to high school was taught some basic arithmetic. As such "+", "-", "×", "÷" and others have been ingrained in our culture for some thousand years or whatever. Even if you know nothing of programming they should be immediately recognizable.
That "ingraining" had a starting point, so is it not reasonable to expect that someone who wants to program computers would have to learn to use the symbols and functions needed.
Comments
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ sio : "Parallax Serial Terminal" PUB start | i sio.start(9600) repeat i from -5 to 15 sio.dec(0 <# i #> 10) sio.char(13)And I get all 10s in the output.
-Phil
-Phil
-Phil
-Phil
eg #MOD, #LIMS or #CLAMP (limits signed), etc.
These could be alternatives (substitute whatever word is decided)
All of this confusion nicely illustrates exactly the problem with glyphs...
The code by Jason posted back in page 8, was this
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ sio : "Parallax Serial Terminal" PUB start | i sio.start(9600) repeat i from -5 to 15 sio.dec(0 #> i <# 10) sio.char(13)Did you?
-Phil
I think for in Spin, just go with the operators as you discussed. I think it's fine. We can make whatever named functions we want out of them. I think it's actually best to have them be operators, so the names remain available for functions.
The thing that needs fixing is the PASM instructions. MIN and MAX are just wrong for those.
I think that's done - Chip did post this earlier
.. not sure if this still applies, looks fine to me ?
REM can be an alias for ' or // for end of line comments, nothing else.
We all come at these things from different backgrounds and experiences. Even if they are not related to programming languages. What is blindingly obvious to one is cryptic gibberish to another.
At the end of the day pretty much anyway to express anything works and is not logically any better or worse than any other. Provided you are not looking at it with preconceived ideas.
That's why language wars are so much fun! White space delimiting vs braces, semicolons or not, this operator symbol or that. It's interesting to see where people come from in that respect. (I'm mean really "REM" for comments, what century is this?
This is unique though. A language war over a language that does not exist yet.
It is said that "A camel is a horse designed by a committee." We trust you to come up with something that is not committee soup! Even if it does not please all committee members.
(Hmm...I think that's a bit hard on Camels, considering the very different environment they have evolved to live in).
And this is the reason that when I see REM the first thing I think of is comment. If it's not then I need to google for it. But even today if you google for rem statement or rem command or rem instruction the first thing that comes out is comment.
So, yeah, I know were REM comes from. Deep in the foggy past of computing history.
As for REM in Windows BAT files. I have not done any of that since 1998. We have had Linux since then!
Having said that, I'm not so sure I like "REM" being repurposed for "remainder". "REM" is just ugly whatever it's supposed to mean.
But, that's just me.
I like // for line comments and /* */ for block comments.
What confusion? Read from left to right - Elev equals 1000 less than or equal to Elev, Elev less than or equal to 2000. The hardest part of that is memorizing the meaning of a few (what 6? 8? 10?) symbols. The only thing I can come up with that might be clearer would be Elev := 1000 #v Elev ^# 2000 or Elev := 999 v Elev v 2001, and they are only marginally better.
Honestly, I don't know why we even bother with the "or equal" part. Greater than 999 and less than 2001 works just as well. Can anyone come up with a case where the "or equal" part is essential?
Especially for those that use a dozen other languages that have their own cryptic symbols. Which can be very similar but have totally different meaning.
How about we forget the ASCII restrictions? Spin supports Unicode to some extent. We could enter the modern era by adopting some of the millions of Unicode symbols. We could write, for example:
x := 10 💩 x 😉 20
It's just some symbols to remember, right?
Twitter people could then be able to write software!
(Err, no, I'm not serious).
Way back, when I was first confronted with SPIN, it took an hour to understand a couple of the demo programs.
Then, came one with an involved expression. Graphics_demo.spin has a couple used to generate color data, as an example.
It took another hour to look them up, write what the expression did, plug raw values in to confirm.
There were several more hours to come. But, it was possible to write programs fairly quickly at that point.
Over the years, those expressions triggered many, how do color and tiles work questions. At one point, I wrote some code without them, creating methods for those tasks.
Fewer questions have come since. When I post from desktop, It's in my signature.
In PASM, similar things happened. The simple path got people on board more quickly, but also did limit what can happen.
On P1 SPIN, those expressions are fast. And, one can pack a whole little program into them too. Very obtuse, but tight, fast, memory lean. On P1, this really matters!
P2 SPIN will be faster as byte code, and faster still compiled.
I'll bet the same dynamics come up though.
P2 will bring more of everything, but the scope of tasks will increase too. Bigger buffers, faster signals, etc...
At one point baggers crammed a level of WOLF3D into a P1, SPIN plus PASM. I remember having to pull out my reference card to parse that program.
Nice that he was able to write that program. This is why we need to remember why some things in SPIN are the way they are. Chip tends to optimize toward this kind of thing being possible.
Whatever we do with SPIN 2, I feel strongly about it performing like P1 SPIN does.
Making compact, fast, powerful expressions is a part of that. When those get written, it's very likely most everyone will need to review before understanding that code.
OK fine.
Designing that away runs the cost and risk of also designing the performance, size and ease away too.
Doing that is a mistake.
On this byte code version of SPIN, doing things in some less than orthodox way, will make great sense in the context of the hardware, assembly language. Taken as a whole, it will make great sense. This should be primary.
I see it much like I do the interrupt events. It's there, and when needed, welcome. Those will very significantly improve on the scope of possible tasks P2 can do well.
A fast, compact, flexible, raw SPIN 2 will do the same.
This is part of the sauce that people value. And when they experience it, they tend to be productive and have fun.
Not all people, and it's fine. Absolutely nothing prevents others from bringing their vision to the table too.
But, we have a lot of P1 users, who will expect these dynamics to be here on P2, enhanced, but not designed away.
I like to think that anybody who ever made it to high school was taught some basic arithmetic. As such "+", "-", "×", "÷" and others have been ingrained in our culture for some thousand years or whatever. Even if you know nothing of programming they should be immediately recognizable.
That is why languages like FORTRAN and BASIC etc were invented in the first place. To get away from the cryptic mnemonics of assembler that programmers used and provide a language that normal people could understand.
Sadly the guys that specified ASCII saw fit to ignore "×", "÷" so we don't have it in the character set or on our keyboards. But "*" and "/" are close enough as to be obvious.
Then there is the other big mistake that many languages make. Using "=" as an assignment. Which is not what it means in mathematics.
Then we get into all the other weird, cryptic, operators that programming languages have introduced over time.
Mind you, it seems high school kids today don't get taught how to do arithmetic or read and write much. That is why we need things like Blockly.
Those ASCII designers decided to use "." for the decimal point. Which meant it could no longer be used as a multiply operator as anyone who has done high school maths might expect. So we are stuck with "*".
We carry a lot of historical baggage here.
No, what is that?
Kind of reminds me of a Commodore Pet keyboard.
No that I remember that very well now.
Edit: Perhaps this "·".
But IBM did not sit on a small character set for long, for then came APL. It had a huge set of cryptic operators (which operated right-to-left). An APL program looked almost runic. Keith's keyboard above shows some of the symbols used by APL. Here's a sample APL program:
Kinda makes interpreting Spin code seem like reading an English primer by comparison, doesn't it?
-Phil
Ah, APL. Let's not go there.
Yes.
Or at least I used to think so before I saw some of the suggestions cropping up here.
Let's see what we end up with.
That was more of a tongue in cheek than a serious suggestion.
That "ingraining" had a starting point, so is it not reasonable to expect that someone who wants to program computers would have to learn to use the symbols and functions needed.