Phil explained the whole matter once. He said that Prop1 (and Spin1, I assume) is like a cat sitting tightly in a shoe box. It takes up all the space and there's no dimension which can be increased to allow for more in the box.
I did say that, didn't I? And I still think it's pretty much true. But I'm sure it pertained just to the hardware. Any computer language can be expanded ad infinitum to encompass whatever syntax and semantics deemed appropriate for maximum expressivity. Of course, one can get carried away ...
Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
Eric's fastspin covers this case and exists already.
While it covers the case, it is NOT the same as it compiles to PASM. Thus, anything that is RAM critical, or even with some RAM free, may not work due to larger code size.
I am talking about a Spin1 interpreter running on P2. I stopped working on it a couple of months age when I thought there was no need. I am now convinced otherwise, so I'll finish it when I get time, which is currently short atm.
I believe all 3 can and will co-exist (fastspin, spin1 on P2, spin2) for P2. Each will have their audience.
I think it's a good idea to have a Spin1 interpreter for the P2. This will allow P1 Spin programs to run on the P2 with little or no changes to the Spin source code. The programs would have to run in the lower 64K of RAM, but the upper RAM could be used for display memory and user data. Now that Chip has posted his Spin2 interpreter it should be fairly easy to modify it to run Spin1 bytecodes.
No need to use Chip's Spin2. I have already done most of the bytecode spin1 interpreter in P2ASM and it uses skip and will use skip/skipf/execf once its fully debugged. Fortunately I already had my Spin Fast Interpreter using a vector table for all bytecodes which meant that using execf is a breeze.
Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
Eric's fastspin covers this case and exists already.
While it covers the case, it is NOT the same as it compiles to PASM. Thus, anything that is RAM critical, or even with some RAM free, may not work due to larger code size.
The case we're talking about though is moving legacy P1 code to P2. The P1 bytecode fits in 32K of RAM, so even when compiled to PASM it will still fit in a P2.
I think it's a good idea to have a Spin1 interpreter for the P2. This will allow P1 Spin programs to run on the P2 with little or no changes to the Spin source code. The programs would have to run in the lower 64K of RAM, but the upper RAM could be used for display memory and user data. Now that Chip has posted his Spin2 interpreter it should be fairly easy to modify it to run Spin1 bytecodes.
P1 programs can already run on P2 with little to no changes to the Spin source code. fastspin compiles Spin1 (well, Spin1.5, it's extended Spin1) and works fine on P2. It has no 64K restriction, it can use the whole of P2 memory. The P2 memory is much larger than P1, so P1 programs easily fit within it even when compiled.
Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
Eric's fastspin covers this case and exists already.
While it covers the case, it is NOT the same as it compiles to PASM. Thus, anything that is RAM critical, or even with some RAM free, may not work due to larger code size.
I am talking about a Spin1 interpreter running on P2. I stopped working on it a couple of months age when I thought there was no need. I am now convinced otherwise, so I'll finish it when I get time, which is currently short atm.
I believe all 3 can and will co-exist (fastspin, spin1 on P2, spin2) for P2. Each will have their audience.
Of course it is not the same but then neither is your P1 interpreter for P2. It will have very different timing. Also, any P1 program will fit on P2 even if it is compiled to native code since the P2 has far more memory. I suppose there could be a value in being able to run unmodified P1 programs on P2 but I doubt that will be needed very often.
I also don't like the idea of Spin2 being a different language than Spin1. I can see extensions to support P2-specific features but why change the language in arbitrary ways? I also don't see why a Spin2 couldn't generate code for a new P1 interpreter. I understand that it probably won't be able to target the existing P1 interpreter though.
Yes, I have tried fastspin, and also its predecessor spin2cpp. In fact, I believe that fastspin will be one of the main development tools for the P2 as time goes on. I also see some value in the Spin interpreter approach, but there is not as great a need for interpreters on the P2 as there was on the P1. However, I would not want to discourage either Chip or Cluso from pursuing the interpreter approach.
Personally, I don't understand why Spin2 has become so much different than Spin1. This will complicate porting Spin1 programs to Spin2. One of the advantages of Spin1 is that it is a simple language that can be mastered in a very short period of time. This makes it a good language for novices to learn. Spin2 is diverging a bit from this, but hopefully it is still something a novice can understand.
I don't think I'll use Spin as much on the P2 as I did on the P1. I prefer writing in C, which is a standard language, and can be ported to other processors. I understand that fastspin allows integrating Spin and C programs, which makes it a very powerful development tool.
I am not planning on making Spin2 compatible with Spin1. I've tried to make Spin2 ideal for what it is. It would be better to make a Spin2 interpreter for Spin1, I think.
Excellent. I think this is the best path
It is important to make a clear and decisive split between the two (SPIN1/2 and Prop1/2).
This is basic marketing.
Users, old and new, need to have a reason to "upgrade" and to see the benefits of the Spin2/Prop2 combination.
I also, don't think that a Spin2 backport to Prop1 is a good idea either.
Once Spin2 users start using the new capabilities of the Prop2, NONE OF THAT CODE will be backward compatible!!
THE 2 VERSIONS CAN NOT BE COMPATIBLE!!!!
It will only serve to fracture your user base!!!
I think it's a good idea to have a Spin1 interpreter for the P2. This will allow P1 Spin programs to run on the P2 with little or no changes to the Spin source code.
I strongly disagree with this idea. All it promotes is the Prop1 competing with the Prop2.
It becomes a distraction for new users and degrades the Prop2 to just being another Prop1.
Users that end up using SPIN1 on Prop2 would never end up using the full capabilities of the Prop2.
Even worse, "SPIN1 for Prop2" would end up having extensions to add certain Prop2 capabilities which would break compatibility back to the original SPIN1 on Prop1.
There is no good to come of it!
J,
I doubt many here will agree on any of those points. Users will use the new Spin2 when starting fresh on the Prop2. Also these community built tools aren't part of Chip's work. Most users won't ever know of their existence.
PINW(pin,val)
PINL(pin)
PINH(pin)
PINNOT(pin)
PINRND(pin)
PINZ(pin)
x := PIN(pin)
This is fine.
but PINZ( ) could stand to be PINF( ) so as not to have an oddball.
The "~"/"~~" clear/set operators are gone, as well as the ">=" gotcha's.
"~~" is now used before a method pointer to mean 'execute method':
~~MethodPtr(params)
I agree that PINF is better than PINZ.
Those PINW/PINL/PINH/PINNOT/PINRND/PINF methods are all reflective of underlying PASM instructions, one-to-one. They don't jump out as much as "PIN[5] := 1" would in source code, but they also don't lead to any potential misunderstandings or inefficiencies.
It doesn't matter if people agree.
Fractured is fractured. Incompatible is incompatible.
I'm surprised you don't think people will find these tools.
Parallax's market is primarily education. There are a very small number of educators that drive the inclusion of these products in schools and courses. If even one of those educators finds an alternate tool, it will affect thousands or tens of thousands of students and educators.
They use the internet too you know!
..and I'm sure they read the forum as well.
I work in education. Teachers are regularly overworked and if they can find a shortcut (or what appears to be one) they will take it because they don't have the time to do it right. I see bad decisions being made regularly because of this.
Fractured and incompatible products WILL lead to user confusion and lost opportunities for Parallax.
I am not planning on making Spin2 compatible with Spin1. I've tried to make Spin2 ideal for what it is. It would be better to make a Spin2 interpreter for Spin1, I think.
Excellent. I think this is the best path
It is important to make a clear and decisive split between the two (SPIN1/2 and Prop1/2).
This is basic marketing.
Users, old and new, need to have a reason to "upgrade" and to see the benefits of the Spin2/Prop2 combination.
I strongly disagree. Neither the Prop1 nor Prop2 are especially popular microprocessors, and Spin is at best a niche language. Making Spin2 mostly incompatible with Spin1 means that users will have more work to port their Prop1 code to Prop2. So why upgrade in that case?
That's not to say there shouldn't be any changes -- there are a few Spin1 features (like waitvid) that won't work on P2, and lots of new P2 features (like smartpins) that won't work on Prop1. But a great deal of code that doesn't depend on those features should be usable on both processors. Utility libraries for string and date processing, for example -- things that don't touch hardware -- *should* be portable without change from the P1 OBEX to P2. Forcing users to port that kind of code just drives them away from the platform. If you have to re-write your objects anyway, why not re-write them in C++ and let them work on Arduino and other processors?
J,
I doubt many here will agree on any of those points. Users will use the new Spin2 when starting fresh on the Prop2. Also these community built tools aren't part of Chip's work. Most users won't ever know of their existence.
I think what's going to happen is that things like Eric Smith's compiler are going to be picked up by mainstream users after they get their feet wet. At some point, they are going to be looking for faster execution.
Some people are going to start out using other tools because of language familiarity.
The "~"/"~~" clear/set operators are gone, as well as the ">=" gotcha's.
"~~" is now used before a method pointer to mean 'execute method':
~~MethodPtr(params)
Could you reconsider this, please? It's hard not to argue against the ">=" change, that was something that tripped up a lot of people, so I'll be happy to support that. But completely changing the meaning of "~~" seems like a dangerous (and needless) change that will just make porting between Spins that much harder. Couldn't we find a new operator to mean "execute method"? "~*" for example. or "~@"?
Yes, Spin is obscure. I don't personally care much about the compatibility issues. I just want what works best in a system. I guess I look at programming like cooking, or something, where there's not much reuse going on, but new efforts are always required.
Yes, Spin is obscure. I don't personally care much about the compatibility issues. I just want what works best in a system. I guess I look at programming like cooking, or something, where there's not much reuse going on, but new efforts are always required.
You may not personally care, but your users may. I understand that you want to break new ground and fix old problems, and that's fair. But could we avoid needless incompatibilities? It seems like there'd be no harm in using some other operator for "execute method". I'm not even suggesting that your compiler support "~~". It just seems like it would make porting code over from Spin1 much easier if "~~" gave an error rather than doing something completely different.
Or, if you want to completely break compatibility with Spin1, why call the language Spin2? Why not come up with a new name to avoid confusion?
Yes, Spin is obscure. I don't personally care much about the compatibility issues. I just want what works best in a system. I guess I look at programming like cooking, or something, where there's not much reuse going on, but new efforts are always required.
You may not personally care, but your users may. I understand that you want to break new ground and fix old problems, and that's fair. But could we avoid needless incompatibilities? It seems like there'd be no harm in using some other operator for "execute method". I'm not even suggesting that your compiler support "~~". It just seems like it would make porting code over from Spin1 much easier if "~~" gave an error rather than doing something completely different.
Or, if you want to completely break compatibility with Spin1, why call the language Spin2? Why not come up with a new name to avoid confusion?
How about this: I find another set of characters for '~~', so as not to create a naming conflict, but I don't support the old '~' and '~~', since we have something better now: var\newvalue ?
I was anticipating using '~' as a line-end character which continues compiling the same statement in the next line, without resetting the parser.
J,
I doubt many here will agree on any of those points. Users will use the new Spin2 when starting fresh on the Prop2. Also these community built tools aren't part of Chip's work. Most users won't ever know of their existence.
I think what's going to happen is that things like Eric Smith's compiler are going to be picked up by mainstream users after they get their feet wet. At some point, they are going to be looking for faster execution.
Some people are going to start out using other tools because of language familiarity.
How great @ersmith Eric Smith's compiler will be
there will be no way to convince my managers to use them for
professional development if they are not officially supported
by the manufacturer (Parallax) or a major player (Keil, ...)
So I think Parallax needs an OFFICIAL C-Development Environment.
For my private projects I will use TaqOS / Tachyon anyhow ;-)
MJB,
You'll be waiting a long time me thinks. Parallax has enough on it's plate already. Parallax is not Microchip. There is no particular reason for Parallax to "officially" back any commercial C at all. Blocky uses C but I can't see that use of C as commercially supportable by itself.
There has been Catalina for the Prop1. I have no doubt Catalina for the Prop2 will be far more effective. If there is future demand then there will be others too.
How about this: I find another set of characters for '~~', so as not to create a naming conflict, but I don't support the old '~' and '~~', since we have something better now: var\newvalue ?
Yes, ersmith's main point I think was that a move of a glyph is best avoided. ie It should either work as expected, or generate an error.
A text search in the manuals should then find the offending command.
How great @ersmith Eric Smith's compiler will be
there will be no way to convince my managers to use them for
professional development if they are not officially supported
by the manufacturer (Parallax) or a major player (Keil, ...)
So I think Parallax needs an OFFICIAL C-Development Environment.
Reasonable point. What exactly does "officially supported by the manufacturer (Parallax) " mean ? Can you ask your managers ?
Would a web page on parallax.com, linking to a github compiler, represent enough 'official support' ?
eg Altera does that does that for many FPGA development systems.
It doesn't matter if people agree.
Fractured is fractured. Incompatible is incompatible.
I'm surprised you don't think people will find these tools.
Parallax's market is primarily education. There are a very small number of educators that drive the inclusion of these products in schools and courses. If even one of those educators finds an alternate tool, it will affect thousands or tens of thousands of students and educators.
They use the internet too you know!
..and I'm sure they read the forum as well.
I work in education. Teachers are regularly overworked and if they can find a shortcut (or what appears to be one) they will take it because they don't have the time to do it right. I see bad decisions being made regularly because of this.
Fractured and incompatible products WILL lead to user confusion and lost opportunities for Parallax.
Yes and no. P2 silicon is not the same as P1, so it is already incompatible from P1. That's fundamentally present.
That said, I could see the appeal for teachers, being able to run the same/single source on either P1 or P2 targets, but that would need conditional compile and possible include-file support.
I think the original, first Spin1 does not have conditional compile & include-file support, but it is probably not hard to add that ? (I think Spin2 does have this ?)
I am not sure if var\newValue can replace ~ and ~~. The later ones where able to pre or post affect the variable and var\newValue will always return the old var in a expression and then set it to newValue.
As for changing := and = I am against it. Any BASIC could use = to set a value and = to compare two values in a if statement. C# and JavaScript use = for setting and == to compare, JavaScript even uses === for true compare, what a nightmare.
I really think the two Spin Languages should not differ too much to make code reusable. Keep := please.
FastSpin does support conditional compiling, so if careful one can write objects able to run on P1 and P2, but if one has to replace all := with = and all = with == things get complicated. Try that with replace.
Sure Spin2 will differ from Spin1, but it should not be completely different If avoidable.
Yes, Spin is obscure. I don't personally care much about the compatibility issues. I just want what works best in a system. I guess I look at programming like cooking, or something, where there's not much reuse going on, but new efforts are always required.
This is now outright funny, 'not much reuse' from somebody working on a 20 year old source in assembler.
There is a lot of code in the OBEX and it would be sad if one can not even port it over without rewriting every assignment and comparison. Most code I used from the OBEX has Spin around a assembler COG. Yes one needs to rewrite that assembler part.
But - for example - someone here ported the spin version of FSRW to the P2 thanks @ersmith possible with the current Spin 1.5 of fastspin.
As a COBOL programmer I like the Idea of continue in the next line to avoid long lines and horizontal scrolling, what I am missing in Spin is the opposite of it, multiple statements in one line for things like a:=1, b:=2, c:=3 in one line.
This may also work with multiple assignments aka (a,b,c):=(1,2,3)
I also like FastSpin's multiple return values, way better then parameters defined as OUT. For me way more readable when input parameters are on top and return values on the bottom. Makes just more sense to me.
Another thing I really like is how FastSpin can cast a parameter as String, this avoids all the STRING("Hello") but maybe a @"Hello" could do that also.
Anyways since the interpreter is not in ROM we will end up with multiple versions of Spin since it will evolve and get changed and has to be included into every program. That is another problem. Object XXX needs Spin2.003 while Object YYY needs Spin2.005.
Yes, Spin is obscure. I don't personally care much about the compatibility issues. I just want what works best in a system. I guess I look at programming like cooking, or something, where there's not much reuse going on, but new efforts are always required.
You may not personally care, but your users may. I understand that you want to break new ground and fix old problems, and that's fair. But could we avoid needless incompatibilities? It seems like there'd be no harm in using some other operator for "execute method". I'm not even suggesting that your compiler support "~~". It just seems like it would make porting code over from Spin1 much easier if "~~" gave an error rather than doing something completely different.
Or, if you want to completely break compatibility with Spin1, why call the language Spin2? Why not come up with a new name to avoid confusion?
How about this: I find another set of characters for '~~', so as not to create a naming conflict, but I don't support the old '~' and '~~', since we have something better now: var\newvalue ?
I was anticipating using '~' as a line-end character which continues compiling the same statement in the next line, without resetting the parser.
Can you make the post-assignment operator `\=` instead of just `\`? Having the equal sign makes it more apparent that it's an assignment.
Yes, Spin is obscure. I don't personally care much about the compatibility issues. I just want what works best in a system. I guess I look at programming like cooking, or something, where there's not much reuse going on, but new efforts are always required.
This is now outright funny, 'not much reuse' from somebody working on a 20 year old source in assembler.
...
Yeah, I don't really have reason to say that. It's actually 28 years old, from the BASIC Stamp effort.
I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way. Keeping Spin the exact same would be limiting, I feel. We'd have to introduce new features as careful and maybe awkward additions, rather than cleaner tear-down-and-rebuilds. We've already gotten rid of a lot of the stranger glyphs in exchange for meaningful keywords. Really, there's not even much to the language. I just want it to be optimal for what it is.
My heart is beaming with pride. Seriously everyone, I am in hiatus, it's forced, and I'm not happy about it. I am reading regularly with great interest. Carry on. I'll be back soon.
[I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?
[I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?
It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.
Comments
-Phil
No need to use Chip's Spin2. I have already done most of the bytecode spin1 interpreter in P2ASM and it uses skip and will use skip/skipf/execf once its fully debugged. Fortunately I already had my Spin Fast Interpreter using a vector table for all bytecodes which meant that using execf is a breeze.
P1 programs can already run on P2 with little to no changes to the Spin source code. fastspin compiles Spin1 (well, Spin1.5, it's extended Spin1) and works fine on P2. It has no 64K restriction, it can use the whole of P2 memory. The P2 memory is much larger than P1, so P1 programs easily fit within it even when compiled.
Have you guys actually tried fastspin?
I also don't like the idea of Spin2 being a different language than Spin1. I can see extensions to support P2-specific features but why change the language in arbitrary ways? I also don't see why a Spin2 couldn't generate code for a new P1 interpreter. I understand that it probably won't be able to target the existing P1 interpreter though.
Personally, I don't understand why Spin2 has become so much different than Spin1. This will complicate porting Spin1 programs to Spin2. One of the advantages of Spin1 is that it is a simple language that can be mastered in a very short period of time. This makes it a good language for novices to learn. Spin2 is diverging a bit from this, but hopefully it is still something a novice can understand.
I don't think I'll use Spin as much on the P2 as I did on the P1. I prefer writing in C, which is a standard language, and can be ported to other processors. I understand that fastspin allows integrating Spin and C programs, which makes it a very powerful development tool.
It is important to make a clear and decisive split between the two (SPIN1/2 and Prop1/2).
This is basic marketing.
Users, old and new, need to have a reason to "upgrade" and to see the benefits of the Spin2/Prop2 combination.
I also, don't think that a Spin2 backport to Prop1 is a good idea either.
Once Spin2 users start using the new capabilities of the Prop2, NONE OF THAT CODE will be backward compatible!!
THE 2 VERSIONS CAN NOT BE COMPATIBLE!!!!
It will only serve to fracture your user base!!!
Don't do it !!!
I strongly disagree with this idea. All it promotes is the Prop1 competing with the Prop2.
It becomes a distraction for new users and degrades the Prop2 to just being another Prop1.
Users that end up using SPIN1 on Prop2 would never end up using the full capabilities of the Prop2.
Even worse, "SPIN1 for Prop2" would end up having extensions to add certain Prop2 capabilities which would break compatibility back to the original SPIN1 on Prop1.
There is no good to come of it!
J
This is fine.
but PINZ( ) could stand to be PINF( ) so as not to have an oddball.
I doubt many here will agree on any of those points. Users will use the new Spin2 when starting fresh on the Prop2. Also these community built tools aren't part of Chip's work. Most users won't ever know of their existence.
The "~"/"~~" clear/set operators are gone, as well as the ">=" gotcha's.
"~~" is now used before a method pointer to mean 'execute method':
~~MethodPtr(params)
I agree that PINF is better than PINZ.
Those PINW/PINL/PINH/PINNOT/PINRND/PINF methods are all reflective of underlying PASM instructions, one-to-one. They don't jump out as much as "PIN[5] := 1" would in source code, but they also don't lead to any potential misunderstandings or inefficiencies.
Fractured is fractured. Incompatible is incompatible.
I'm surprised you don't think people will find these tools.
Parallax's market is primarily education. There are a very small number of educators that drive the inclusion of these products in schools and courses. If even one of those educators finds an alternate tool, it will affect thousands or tens of thousands of students and educators.
They use the internet too you know!
..and I'm sure they read the forum as well.
I work in education. Teachers are regularly overworked and if they can find a shortcut (or what appears to be one) they will take it because they don't have the time to do it right. I see bad decisions being made regularly because of this.
Fractured and incompatible products WILL lead to user confusion and lost opportunities for Parallax.
j
I strongly disagree. Neither the Prop1 nor Prop2 are especially popular microprocessors, and Spin is at best a niche language. Making Spin2 mostly incompatible with Spin1 means that users will have more work to port their Prop1 code to Prop2. So why upgrade in that case?
That's not to say there shouldn't be any changes -- there are a few Spin1 features (like waitvid) that won't work on P2, and lots of new P2 features (like smartpins) that won't work on Prop1. But a great deal of code that doesn't depend on those features should be usable on both processors. Utility libraries for string and date processing, for example -- things that don't touch hardware -- *should* be portable without change from the P1 OBEX to P2. Forcing users to port that kind of code just drives them away from the platform. If you have to re-write your objects anyway, why not re-write them in C++ and let them work on Arduino and other processors?
I think what's going to happen is that things like Eric Smith's compiler are going to be picked up by mainstream users after they get their feet wet. At some point, they are going to be looking for faster execution.
Some people are going to start out using other tools because of language familiarity.
Could you reconsider this, please? It's hard not to argue against the ">=" change, that was something that tripped up a lot of people, so I'll be happy to support that. But completely changing the meaning of "~~" seems like a dangerous (and needless) change that will just make porting between Spins that much harder. Couldn't we find a new operator to mean "execute method"? "~*" for example. or "~@"?
You may not personally care, but your users may. I understand that you want to break new ground and fix old problems, and that's fair. But could we avoid needless incompatibilities? It seems like there'd be no harm in using some other operator for "execute method". I'm not even suggesting that your compiler support "~~". It just seems like it would make porting code over from Spin1 much easier if "~~" gave an error rather than doing something completely different.
Or, if you want to completely break compatibility with Spin1, why call the language Spin2? Why not come up with a new name to avoid confusion?
Students that end up here will become future enthusiasts themselves. For them, having extra tools is an adventure.
How about this: I find another set of characters for '~~', so as not to create a naming conflict, but I don't support the old '~' and '~~', since we have something better now: var\newvalue ?
I was anticipating using '~' as a line-end character which continues compiling the same statement in the next line, without resetting the parser.
How great @ersmith Eric Smith's compiler will be
there will be no way to convince my managers to use them for
professional development if they are not officially supported
by the manufacturer (Parallax) or a major player (Keil, ...)
So I think Parallax needs an OFFICIAL C-Development Environment.
For my private projects I will use TaqOS / Tachyon anyhow ;-)
You'll be waiting a long time me thinks. Parallax has enough on it's plate already. Parallax is not Microchip. There is no particular reason for Parallax to "officially" back any commercial C at all. Blocky uses C but I can't see that use of C as commercially supportable by itself.
There has been Catalina for the Prop1. I have no doubt Catalina for the Prop2 will be far more effective. If there is future demand then there will be others too.
A text search in the manuals should then find the offending command.
Were that is needed in other languages, I've see underscore '_' used as a line continuation - that seems a natural symbol ?
Would a web page on parallax.com, linking to a github compiler, represent enough 'official support' ?
eg Altera does that does that for many FPGA development systems.
That said, I could see the appeal for teachers, being able to run the same/single source on either P1 or P2 targets, but that would need conditional compile and possible include-file support.
I think the original, first Spin1 does not have conditional compile & include-file support, but it is probably not hard to add that ? (I think Spin2 does have this ?)
As for changing := and = I am against it. Any BASIC could use = to set a value and = to compare two values in a if statement. C# and JavaScript use = for setting and == to compare, JavaScript even uses === for true compare, what a nightmare.
I really think the two Spin Languages should not differ too much to make code reusable. Keep := please.
FastSpin does support conditional compiling, so if careful one can write objects able to run on P1 and P2, but if one has to replace all := with = and all = with == things get complicated. Try that with replace.
Sure Spin2 will differ from Spin1, but it should not be completely different If avoidable.
This is now outright funny, 'not much reuse' from somebody working on a 20 year old source in assembler.
There is a lot of code in the OBEX and it would be sad if one can not even port it over without rewriting every assignment and comparison. Most code I used from the OBEX has Spin around a assembler COG. Yes one needs to rewrite that assembler part.
But - for example - someone here ported the spin version of FSRW to the P2 thanks @ersmith possible with the current Spin 1.5 of fastspin.
As a COBOL programmer I like the Idea of continue in the next line to avoid long lines and horizontal scrolling, what I am missing in Spin is the opposite of it, multiple statements in one line for things like a:=1, b:=2, c:=3 in one line.
This may also work with multiple assignments aka (a,b,c):=(1,2,3)
I also like FastSpin's multiple return values, way better then parameters defined as OUT. For me way more readable when input parameters are on top and return values on the bottom. Makes just more sense to me.
Another thing I really like is how FastSpin can cast a parameter as String, this avoids all the STRING("Hello") but maybe a @"Hello" could do that also.
Anyways since the interpreter is not in ROM we will end up with multiple versions of Spin since it will evolve and get changed and has to be included into every program. That is another problem. Object XXX needs Spin2.003 while Object YYY needs Spin2.005.
Somebody has to write @potatohead sized posts...
Mike
Can you make the post-assignment operator `\=` instead of just `\`? Having the equal sign makes it more apparent that it's an assignment.
Yeah, I don't really have reason to say that. It's actually 28 years old, from the BASIC Stamp effort.
I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way. Keeping Spin the exact same would be limiting, I feel. We'd have to introduce new features as careful and maybe awkward additions, rather than cleaner tear-down-and-rebuilds. We've already gotten rid of a lot of the stranger glyphs in exchange for meaningful keywords. Really, there's not even much to the language. I just want it to be optimal for what it is.
-Phil
It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.