Well it wouldn't really be part of the compiler itself, but the wrapper around the compiler. I kind of call the whole thing the compiler, but anyway...
The downside to having it be your way is then you have to do the <objname>.<func> thing.
My current idea is essentially just an object that the compiler tries to find pubs in when it has a undefined symbol. It's kind of like the "using" thing in C++ or C#
Roy
I think the problem with that approach is in the phrase "an object that the compiler tries to find pubs in". Using that scheme you only have a single object which isn't very extensible. It seems like it would be better to have a number of "system" objects that the user could make use of. Having more than one also solves some namespace issues. If you have only one and you have lots of "built in" functions you'll end up having to prefix function names with a pseudo object name. Something like "timerSet" rather than having a "Timer" object with a "set" method. Those compound names sort of break the object-oriented paradigm that Spin is based on.
The downside to having it be your way is then you have to do the <objname>.<func> thing.
Like I said, a name space issue.
Don't worry about that. The Arduino users, many of them beginners and non-programmers have been handling things like "serial.tx(something)" for a long time. After all they are using C++ even if they don't know it. Rumour has it they get on quite happily.
This is not meant to be a big thing. It's just snippets to make things simpler, and to include some things into Spin that would be in there is we had more cog memory for a bigger bytecode interpreter. It's also an avenue to get some of the Spin2 features working on Prop 1.
So it's not really outside of the language like I said it could be. Going back on what I said before. It's just something me and Jeff have talked about, and we both like the idea, we just need to work out details.
Serial (like FullDuplexSerial) would still be an object like now. Don't turn it into some big ugly thing...
I'm starting to lean toward the C guys here. Implicit method calls to virtual objects may be overkill, despite what the ed. guys want. This is a perfect case where specifying a preprocessor might be a better idea. Also, if you want to eliminate the <object>.<method> syntax, there are acceptable ways to do that without invoking the using keyword, although I wouldn't be opposed to that. It can be done in the OBJ section:
OBJ
sio : "IO::Parallax Serial Terminal" char [b]as[/b] tx, str, dec
The method list after the object specifies which methods are imported implicitly. For example, every time the tx method is nakedly invoked, sio.char gets called. The other methods don't require "as" aliases, since they're pretty standard. The obvious advantage of this is that disparate objects with different method names but having similar functions can be swapped out without editing every call in the program.
I wonder if one of the reasons we're running into difficulty here is that it isn't clear who is the target audience for Spin. It has been said that Parallax failed to attract much of the "professional" market because they didn't support C/C++ on the Propeller from the start. Since we now have several C solutions to address this "professional" market, I don't think that is the target for Spin. Next, it is my understanding that Parallax has been losing traction in the educational market because that market also demands C/C++ although with a simpler development environment like the Arduino tool. This is being addressed by SimpleIDE. I guess that leaves the hobbyist market? Is that the primary target for Spin? If so, what are the needs of that market? Are these customers mostly beginning programmers who may have a hard time understanding the concept of "objects"? If so then the idea of a virtual object with methods that can be called without the <obj>.<method> syntax may indeed be best. On the other hand, if we can assume that the audience for Spin is a bit more sophisticated then maybe Solutions such as what Phil suggested with his "sio" example would be best. It provides an extensible solution facility that isn't limited to a handful of functions that Parallax might think are useful right now. So I guess my real question is, what is the target audience for Spin and what is their level of programming sophistication?
I think Spin will always be a programming language for the novice programmer. With that in mind it should contain more features to help the novice programmer. Some of the biggest pitfalls that novices fall into are incorrect use of pointers. The compiler could be improved without changing the language to check the use of string pointers. Standard Spin functions such as string, strsize and strcomp are well defined, and the compiler could check how these are used. There are also defacto standard objects, such as FullDuplexSerial that could be checked as well.
Another problem that novices encounter is the use of floating point in Spin. The Spin compiler knows which constants are floating point and it can check the use of the standard floating pointer methods to ensure that they are consistent.
There are other common programming errors that could be checked by the compiler, such as using uninitialized stack variables and the used of the ">=" and "<=" operators, which should almost never be used in normal practice.
Beyond that, the language could be extended to allow for the use of optional type qualifiers. This would allow for even more error checking capability.
I do think Chip's language Spin is brillant because it is so easy to use with minimal setup. Very nice for novice programmer's and us old programmer's that like to type as little as possible.
I do think Chip's language Spin is brillant because it is so easy to use with minimal setup. Very nice for novice programmer's and us old programmer's that like to type as little as possible.
Yes, there are many things that are nice about Spin. I wasn't trying to imply it didn't have value. I was just trying to understand its target audience so any changes we propose for it don't interfere with its current strengths for that audience. We could "improve" Spin from the point of view of more experienced programmers only to make it harder to use for its real audience. That's what I'd like to avoid.
I think you are correct in trying to identify the target audience as I think it is the same as Chip wrote Spin for. I have been programming the Prop since it came out but I still consider myself a novice programmer. I am only a hobbiest who will not be buying a boat load of Propeller's but I hope Spin survives! Also knowing C and it's use through out industry the Propeller has to have it to compete. Thanks to all of the experts out there making both languages available for the Propeller2.
Things that are elegant and powerful tend to do so by maintaining simplicity. I don't concur with adding the kitchen sink of advanced programming features - we have GCC for that.
There seems to be concurrence from this thread and the open prop2 thread about the following regarding SPIN:
#1 Strings need to be improved (by far the most common)
Other secondary items commonly mentioned include:
#2 Floating point support (mostly because adding as external object makes for ugly syntax to use the object)
#3 Built in timing functions (very good to help beginners - great idea)
#4 Built in common functions found in PBASIC (PULSEOUT, etc)
Basically, the design of SPIN is elegant because it is a fairly sparse language that builds up with objects (although it is not OOP). Since there is a bit more memory to play with, improvements should focus on making it easier to use - especially for beginners. I mean, the way SPIN uses strings, or how you have to play with the counter using large numbers for timing are two things, alone, that are like to scare away and intimidate people who won't be intimidated by Processing on the Arduino, for example.
I see mild improvements to SPIN as a way to lower that barrier to entry for propeller and broaden the user base. Parallax won't be around if it is a public service for a small # of people - they are a business that needs to make $ to have stability then as a benefit - support the user community which it does so very well.
I think Spin will always be a programming language for the novice programmer.
What rubbish! I think both of those statements betray the arrogant self-importance of the C programming community. It's existed as a subtle undertone of discussion ever since the subject of C for the Propeller came up, and now it's out in the open. Although Spin is certainly novice-friendly, it is and will continue to be, a favored language for rapid application development on the Propeller by professional and novice alike. To suggest that it be confined to the toybox of beginners is totally presumptuous.
Agree with you Phil. SPIN is very powerful and isn't just for novices. (I've been trying to make the point that a few tweaks will allow it to serve novices better than it does now, however).
There is sort of an arrogance regarding more established languages, isn't there?
I experienced the same thing programming in ActionScript 2/3 with the flash IDE - got some powerful things done with a decent object oriented language, that some people want to pshaw.
What rubbish! I think both of those statements betray the arrogant self-importance of the C programming community. It's existed as a subtle undertone of discussion ever since the subject of C for the Propeller came up, and now it's out in the open. Although Spin is certainly novice-friendly, it is and will continue to be, a favored language for rapid application development on the Propeller by professional and novice alike. To suggest that it be confined to the toybox of beginners is totally presumptuous.
-Phil
Notice that I didn't say that Spin wouldn't be used by the professional market, only that that market seems mostly to demand C/C++. What I was trying to get at is that we could add lots of stuff to Spin to make it better address this professional market and that would be great as long as it doesn't make it more difficult for its intended market which I suspect is novice programmers.
There is sort of an arrogance regarding more established languages, isn't there?
I wouldn't call it arrogance. I'd call it facing reality. You can invent a new language that is better than every other language ever invented but that doesn't mean it will be used. People will tend to use whatever they're familiar with that can do the job and like it or not that is C/C++ for most microcontroller applications. C/C++ isn't the best language in the world. I don't think even its advocates would suggest that. But it is adequate for the job and there are lots of people who have experience with it. There are a few people who will take the time to learn a new language if it offers them something that other languages don't but I think they're in the minority.
In any case, I think it would be a lot of fun to enhance Spin to be even more powerful than it is now but I don't think those improvements will make it all that much more likely that it will be accepted by the masses.
What rubbish! I think both of those statements betray the arrogant self-importance of the C programming community.
I don't see it like that.
What I see is a lot of requests to add this or that feature to the Spin language: A preprocessor, pointers to objects, stronger type checking, string handling, structures, pointer types, etc etc etc.
Well, my conclusion is that if you add all that to Spin you are basically recreating C, perhaps with a bit of C++ thrown in given that Spin has objects.
As such I have to say why bother? We have C that has done all of that for the past 40 years. It's investing a lot of time and effort into a language that nobody outside the Propeller user community is ever going to use. It's a dead end.
On the other hand I think Spin is brilliant as a really simple, easy to understand language to start off those new to programming or those who would like to get something done occasionally without dedicating hundreds of hours to understanding a lot of archane details. No header files, no macros, no #ifdefs, no braces or semicolons to worry about. And here is a biggie, no Make files to build a program from multiple sources, just use OBJ and let the compiler figure out what to do. Type code, hit the button, it runs.
My proposal is to get Spin working on the Prop II with as few changes as possible to the language itself.
What rubbish! I think both of those statements betray the arrogant self-importance of the C programming community. It's existed as a subtle undertone of discussion ever since the subject of C for the Propeller came up, and now it's out in the open. Although Spin is certainly novice-friendly, it is and will continue to be, a favored language for rapid application development on the Propeller by professional and novice alike. To suggest that it be confined to the toybox of beginners is totally presumptuous.
-Phil
I don't think that Spin supports the professional. It doesn't have:
1. File organization ability (library, etc.)
2. Configurable compilation with conditional configuration (#ifdefs along with Make/Ant type setup).
3. A unit test system (such as CppUnit)
4. Professional documentation on the nuts and bolts of Spin (i.e., how and what is compiled)
5. A highly efficient optimized compiler
6. A static analyzer (list)
There are several more (coding standard, standardized documentation, compiler optimizations, compiler cross platform, a better library, etc.) that are being developed.
I don't disagree with you as such but do notice some confusion in you list of missing features.
Ever since they invented the IDE there has been confusion about what is the language, what is in the IDE and what may or not be in the standard libraries. I suggest the "language" is that definition of syntax and semantics of the text you actually end up compiling. Everything else is peripheral, not to say that it is not important.
So stepping through your list:
1. File organization ability (library, etc.)
Yes C, for example comes with a standard library of file handling stuff. That is not the language as such but some standardised suport that comes with it. I can understand that Spin is not supplied with such a standard library as who would have expected a small MCU to require such a thing?
2. Configurable compilation with conditional configuration (#ifdefs along with Make/Ant type setup).
The #ifdef and other preprocessing things we might consider as part of the language but the build system, Make/Ant whatever, is surely not. On the other hand Spin with it's lack of header files and OBJ sections basically does not need a Make utility.
3. A unit test system (such as CppUnit)
Again, this is not part of the language as such.
4. Professional documentation on the nuts and bolts of Spin (i.e., how and what is compiled)
Ditto. The big thing here is that there is no formal definition of the Spin syntax or it's semantics.
5. A highly efficient optimized compiler
Again not part of the language definition, but an implementation thing that would be nice to have.
6. A static analyzer (list)
Also not part of the language.
Historically many languages have not had the things you mention. Currently many of them still don't.
I hereby withdraw my comment about "professional" users vs. "educational" users vs. "hobbyist" users. I only mentioned it to try to focus the discussion not to bring up a flame war about whether Spin is the best possible language for all purposes. I think it has value but I think it's important to keep in mind its intended purpose to avoid cluttering it with features that would make it less useful to that purpose. In fact, it was a roundabout way of saying that maybe Roy and Jeff are right that adding a few simple functions is better than building a new more general framework.
The problem I have with a "new more general framework" solution (like Phil's "as" thing) is that it makes it easy for people to make their code harder for others to use. For example, say that in your code you made it so that tx mapped to the char PUB inside of Parallax Serial Terminal. Sounds great, but if I want to use your code, I now have to do the same mapping. However, if I have already mapped tx to something else in my program, then I have to go do search and replace stuff to fix things up before I use it. I prefer the object approach without aliasing in this case.
The intent of what Jeff and I talked about was more along the lines of adding "standard" stuff to Spin that would be well defined and work for everyone. These would work as if they were build in keywords to the language. The only issue remaining for me on this is the potential name collision with variables and functions in pre-existing code. The discussion of how we might implement that is what I think led us down the more general solutions path...
I'm already opening a whole big can of worms in Spin with the preprocessor.
The intent of what Jeff and I talked about was more along the lines of adding "standard" stuff to Spin that would be well defined and work for everyone. These would work as if they were build in keywords to the language.
If that will make Spin easier to use then go for it! You certainly know Spin programmers better than I do. I can't even remember what all of the operators do without looking them up each time! :-)
... Also, if you want to eliminate the <object>.<method> syntax, there are acceptable ways to do that without invoking the using keyword, although I wouldn't be opposed to that. It can be done in the OBJ section:
Why don't you just write a Propeller Perl interpreter?
What rubbish! I think both of those statements betray the arrogant self-importance of the C programming community. It's existed as a subtle undertone of discussion ever since the subject of C for the Propeller came up, and now it's out in the open. Although Spin is certainly novice-friendly, it is and will continue to be, a favored language for rapid application development on the Propeller by professional and novice alike. To suggest that it be confined to the toybox of beginners is totally presumptuous.
My comments had nothing to do with C, except that C is one of the languages that has excellent support for error checking, and uses a standard set of library functions. If Spin had those features it would make it much more useful.
For example, say that in your code you made it so that tx mapped to the char PUB inside of Parallax Serial Terminal. Sounds great, but if I want to use your code, I now have to do the same mapping. However, if I have already mapped tx to something else in my program, then I have to go do search and replace stuff to fix things up before I use it. I prefer the object approach without aliasing in this case.
I'm not sure I understand the problem there. First of all, the as mapping makes it easy to switch, say, from FullDuplexSerial to PST and back -- or between any two objects that have similar functions with different names. Secondly, what's wrong with global search-and-replace? It's drop-dead simple to change symbol names that way. I do it all the time.
I believe there's way more upside than downside to such a feature. Besides, don't forget: the less there is to type, the better. Programmers are lazy, and laziness is a virtue that deserves encouragement.
Frankly, I'm a little disturbed by the C cabal's apparent desire to keep Spin dumbed down. Guys, Spin isn't a threat to C and never will be. Those who program in C will probably continue to do so, regardless of the power of Spin. But those who don't do C deserve to have the best tools available. Spin tops the list, IMO, and deserves to grow. Anyway, unless you're a Spin programmer or Spin wannabe, I'm not sure that your trying to influence the direction of Spin is in the best interests of the Propeller community.
Frankly, I'm a little disturbed by the C cabal's apparent desire to keep Spin dumbed down. Guys, Spin isn't a threat to C and never will be.
I don't think anyone ever implied it was. One thing you might want to consider though is this. Parallax probably has a limited amount of money to spend on software development. What would be the best way to spend that money to help insure that the Propeller 2 sells as well as possible? Would it be to make a new and improved Spin? It might be I guess. I'm not in the Parallax marketing department and I don't know their strategy for selling P2. However, they should probably make sure that they invest the most effort and resources in what will best help sell their products whatever that may be.
Of course, maybe you're not talking about me when you say "the C cabal". After all, I'm really a Lisp booster! :-)
What? There is no conspiricy here, why would there be?. What have C users or tool developers got to gain by it.
"desire to keep Spin dumbed down" is one way to see it. Another way is "desire to not see Spin aquire a lot of warts and band aids that move it away from that beautifuly simple language that a casual programmer can do something with after five minutes of study".
The Propeller2 has to have C/C++ to compete. I just wish that the wonderful language of Spin that the Propeller1 was introduced with will not be pushed to the side because of the need to make "money" for the Propeller2. I have spent alot of time learning Spin over the last few years and personally like it better than C.
... Frankly, I'm a little disturbed by the C cabal's apparent desire to keep Spin dumbed down. Guys, Spin isn't a threat to C and never will be. Those who program in C will probably continue to do so, regardless of the power of Spin. But those who don't do C deserve to have the best tools available. Spin tops the list, IMO, and deserves to grow. Anyway, unless you're a Spin programmer or Spin wannabe, I'm not sure that your trying to influence the direction of Spin is in the best interests of the Propeller community.
-Phil
I don't understand "your problem" at all. Spin, is Spin and will always be spin. Chip will ensure that. It's his language.
Comments
I maintain that building such specific things like serial or SPI or whatever "default objects" into the language itself is all messed up.
I think the problem with that approach is in the phrase "an object that the compiler tries to find pubs in". Using that scheme you only have a single object which isn't very extensible. It seems like it would be better to have a number of "system" objects that the user could make use of. Having more than one also solves some namespace issues. If you have only one and you have lots of "built in" functions you'll end up having to prefix function names with a pseudo object name. Something like "timerSet" rather than having a "Timer" object with a "set" method. Those compound names sort of break the object-oriented paradigm that Spin is based on.
Like I said, a name space issue.
Don't worry about that. The Arduino users, many of them beginners and non-programmers have been handling things like "serial.tx(something)" for a long time. After all they are using C++ even if they don't know it. Rumour has it they get on quite happily.
So it's not really outside of the language like I said it could be. Going back on what I said before. It's just something me and Jeff have talked about, and we both like the idea, we just need to work out details.
Serial (like FullDuplexSerial) would still be an object like now. Don't turn it into some big ugly thing...
Roy
I'm starting to lean toward the C guys here. Implicit method calls to virtual objects may be overkill, despite what the ed. guys want. This is a perfect case where specifying a preprocessor might be a better idea. Also, if you want to eliminate the <object>.<method> syntax, there are acceptable ways to do that without invoking the using keyword, although I wouldn't be opposed to that. It can be done in the OBJ section:
The method list after the object specifies which methods are imported implicitly. For example, every time the tx method is nakedly invoked, sio.char gets called. The other methods don't require "as" aliases, since they're pretty standard. The obvious advantage of this is that disparate objects with different method names but having similar functions can be swapped out without editing every call in the program.
-Phil
Another problem that novices encounter is the use of floating point in Spin. The Spin compiler knows which constants are floating point and it can check the use of the standard floating pointer methods to ensure that they are consistent.
There are other common programming errors that could be checked by the compiler, such as using uninitialized stack variables and the used of the ">=" and "<=" operators, which should almost never be used in normal practice.
Beyond that, the language could be extended to allow for the use of optional type qualifiers. This would allow for even more error checking capability.
There seems to be concurrence from this thread and the open prop2 thread about the following regarding SPIN:
#1 Strings need to be improved (by far the most common)
Other secondary items commonly mentioned include:
#2 Floating point support (mostly because adding as external object makes for ugly syntax to use the object)
#3 Built in timing functions (very good to help beginners - great idea)
#4 Built in common functions found in PBASIC (PULSEOUT, etc)
Basically, the design of SPIN is elegant because it is a fairly sparse language that builds up with objects (although it is not OOP). Since there is a bit more memory to play with, improvements should focus on making it easier to use - especially for beginners. I mean, the way SPIN uses strings, or how you have to play with the counter using large numbers for timing are two things, alone, that are like to scare away and intimidate people who won't be intimidated by Processing on the Arduino, for example.
I see mild improvements to SPIN as a way to lower that barrier to entry for propeller and broaden the user base. Parallax won't be around if it is a public service for a small # of people - they are a business that needs to make $ to have stability then as a benefit - support the user community which it does so very well.
-Phil
There is sort of an arrogance regarding more established languages, isn't there?
I experienced the same thing programming in ActionScript 2/3 with the flash IDE - got some powerful things done with a decent object oriented language, that some people want to pshaw.
In any case, I think it would be a lot of fun to enhance Spin to be even more powerful than it is now but I don't think those improvements will make it all that much more likely that it will be accepted by the masses.
I don't see it like that.
What I see is a lot of requests to add this or that feature to the Spin language: A preprocessor, pointers to objects, stronger type checking, string handling, structures, pointer types, etc etc etc.
Well, my conclusion is that if you add all that to Spin you are basically recreating C, perhaps with a bit of C++ thrown in given that Spin has objects.
As such I have to say why bother? We have C that has done all of that for the past 40 years. It's investing a lot of time and effort into a language that nobody outside the Propeller user community is ever going to use. It's a dead end.
On the other hand I think Spin is brilliant as a really simple, easy to understand language to start off those new to programming or those who would like to get something done occasionally without dedicating hundreds of hours to understanding a lot of archane details. No header files, no macros, no #ifdefs, no braces or semicolons to worry about. And here is a biggie, no Make files to build a program from multiple sources, just use OBJ and let the compiler figure out what to do. Type code, hit the button, it runs.
My proposal is to get Spin working on the Prop II with as few changes as possible to the language itself.
I don't think that Spin supports the professional. It doesn't have:
1. File organization ability (library, etc.)
2. Configurable compilation with conditional configuration (#ifdefs along with Make/Ant type setup).
3. A unit test system (such as CppUnit)
4. Professional documentation on the nuts and bolts of Spin (i.e., how and what is compiled)
5. A highly efficient optimized compiler
6. A static analyzer (list)
There are several more (coding standard, standardized documentation, compiler optimizations, compiler cross platform, a better library, etc.) that are being developed.
I don't disagree with you as such but do notice some confusion in you list of missing features.
Ever since they invented the IDE there has been confusion about what is the language, what is in the IDE and what may or not be in the standard libraries. I suggest the "language" is that definition of syntax and semantics of the text you actually end up compiling. Everything else is peripheral, not to say that it is not important.
So stepping through your list:
1. File organization ability (library, etc.)
Yes C, for example comes with a standard library of file handling stuff. That is not the language as such but some standardised suport that comes with it. I can understand that Spin is not supplied with such a standard library as who would have expected a small MCU to require such a thing?
2. Configurable compilation with conditional configuration (#ifdefs along with Make/Ant type setup).
The #ifdef and other preprocessing things we might consider as part of the language but the build system, Make/Ant whatever, is surely not. On the other hand Spin with it's lack of header files and OBJ sections basically does not need a Make utility.
3. A unit test system (such as CppUnit)
Again, this is not part of the language as such.
4. Professional documentation on the nuts and bolts of Spin (i.e., how and what is compiled)
Ditto. The big thing here is that there is no formal definition of the Spin syntax or it's semantics.
5. A highly efficient optimized compiler
Again not part of the language definition, but an implementation thing that would be nice to have.
6. A static analyzer (list)
Also not part of the language.
Historically many languages have not had the things you mention. Currently many of them still don't.
The intent of what Jeff and I talked about was more along the lines of adding "standard" stuff to Spin that would be well defined and work for everyone. These would work as if they were build in keywords to the language. The only issue remaining for me on this is the potential name collision with variables and functions in pre-existing code. The discussion of how we might implement that is what I think led us down the more general solutions path...
I'm already opening a whole big can of worms in Spin with the preprocessor.
Why don't you just write a Propeller Perl interpreter?
I believe there's way more upside than downside to such a feature. Besides, don't forget: the less there is to type, the better. Programmers are lazy, and laziness is a virtue that deserves encouragement.
Frankly, I'm a little disturbed by the C cabal's apparent desire to keep Spin dumbed down. Guys, Spin isn't a threat to C and never will be. Those who program in C will probably continue to do so, regardless of the power of Spin. But those who don't do C deserve to have the best tools available. Spin tops the list, IMO, and deserves to grow. Anyway, unless you're a Spin programmer or Spin wannabe, I'm not sure that your trying to influence the direction of Spin is in the best interests of the Propeller community.
-Phil
Of course, maybe you're not talking about me when you say "the C cabal". After all, I'm really a Lisp booster! :-)
What? There is no conspiricy here, why would there be?. What have C users or tool developers got to gain by it.
"desire to keep Spin dumbed down" is one way to see it. Another way is "desire to not see Spin aquire a lot of warts and band aids that move it away from that beautifuly simple language that a casual programmer can do something with after five minutes of study".
That would be GREAT!!! :cool:
For those that can't tell I'm joking. While I love perl I can't imagine it working well with the limited hardware of the propeller.