Unnofficial - because Parallax hasn't chimed in on an plans or intentions for a Spin roadmap into the future
Propeller - well, duh, that's why we're here
Expo - that's so we have at least 3 opportunities to have committee steering meetings
2016 - trust me on this it will be here before much is agreed on in committee
Voting members/ technical committee:
Roy
Phil
Heater
Ersmith
Pedward
Dave Hein
Jazzed
Neutral corners will be assigned, debates will be in 5 minute rounds, you are allowed to "tag out" to someone on your sub-committee.
The 2016 target date is just to have a formal definition of the language, working tools will be released by 2018.
Play nice because in the end this is for the children....or the grandchildren depending on how effective the committee is.
Ok, now we have a committee! Let's git 'er done!!!
Wonderful! Another language designed by committee. :-)
Seriously, if you find that you want to add lots of the features of C and C++ to Spin, maybe you should evaluate whether it would be better to just write a nice Propeller-specific library for C or a class library for C++ to take good advantage of the strengths of the Propeller rather than designing "yet another language". Leave Spin pretty much as-is for beginners.
PropGCC offers a better alternative to SPIN. PropGCC still needs more stuff to be built up around it. But, when that happens, I won't see a reason why to use SPIN anymore.
I've pretty much lost interest in this thread after post #1. I guess Spin needs a Benevolent Dictator for Life (BDFL). Is this a discussion on improvements for Spin, but Spin remains basically the same? Or is it the design of a new language? I personally like Spin and want it kept similar to what it is. C/C++, especially on Prop II, adds all the features one could want. My list of improvements to Spin:
1. Compile time checking--types and any other errors the compiler can find.
2. Support for floats. I write a := b * c and compiler writes a:= F.Fmul(b,c).
3. Support for strings.
4. Speed and size optimizations.
5. Better way to handle libraries.
...But, when that happens, I won't see a reason why to use SPIN anymore.
Same here. But I do think Spin is an excellent introductory language for non-programmers. As was BASIC back in the C64 days.
As such it should be kept as simple an free of "line noise" as possible. It does a very good job of that so far what with doing away with curly braces and other redundant brackets and semi-colons etc.
That may well mean that it is never a good choice for large or complex programs, well so what? If anyone hits the boundaries of Spin then they understand the problems and can move on to C/C++ and be in a position to understand why what they are looking at is a lot more complicated.
But I do think Spin is an excellent introductory language for non-programmers. As was BASIC back in the C64 days.
As such it should be kept as simple an free of "line noise" as possible. It does a very good job of that so far what with doing away with curly braces and other redundant brackets and semi-colons etc.
Well, Spin adds some "line noise" as well in the form of lots of obscure operators. Those could probably be removed if the compiler had a little optimization added.
I think it would be a mistake to pigeon-hole Spin as a beginners-only language. I see it more as a tool for rapid application development for the Prop. As such, it deserves to have some sophisticated enhancements, such as the ? : trinary operator (yay!). I would also encourage the addition of && and || lazy conditionals.
One of the issues I see with adding language features at the compiler level right away is the problem of validation. It's taken all summer to validate the Core Spin compiler, and apparently the process continues. Every time you add a new feature, that feature not only has to be validated, but you have to revalidate Core Spin to make sure something didn't get screwed up in the process. With a preprocessor approach, Core Spin is left sacrosanct as a fall-back position.
I think it would be a mistake to pigeon-hole Spin as a beginners-only language. I see it more as a tool for rapid application development for the Prop. As such, it deserves to have some sophisticated enhancements, such as the ? : trinary operator (yay!). I would also encourage the addition of && and || lazy conditionals.
One of the issues I see with adding language features at the compiler level right away is the problem of validation. It's taken all summer to validate the Core Spin compiler, and apparently the process continues. Every time you add a new feature, that feature not only has to be validated, but you have to revalidate Core Spin to make sure something didn't get screwed up in the process. With a preprocessor approach, Core Spin is left sacrosanct as a fall-back position.
That's a bit different. In your example the preprocessor is external to the language itself. There is no feature inside of Perl that allows you to specify that "mypreprocessor" should be run before passing the code to the Perl interpreter. Or is there? I'm certainly not a Perl expert.
You're right: it's not a perfect analogy. As you know, the shebang operator is a Linux/Unix thing that directs how a text file is to be processed when given as a command. Windows, unfortunately, does not recognize it. So for true OS cross-compatibility, something like PRE becomes necessary for implementation by the compiler. In the case of Spin, there's an additional advantage to PRE, in that each object can have its own PRE section instructing the compiler how to preprocess the file.
This isn't something I just came up with, BTW. I've been lobbying for preprocessor hooks in Spin for years. It would just make it so much easier to experiment with the language.
The hash, shriek, slash, bin, slash, bash thing was, as far as I can tell, a Unix hack to get the system to apply the right interpreter to a script file so that you can use the script file as any other command from the command line. It only worked originally because # was the comment character for the languages and the rest of the line ignored by the interpreters. I think now a days Linux can use other "magic" in files to get then running correctly as well.
I mean really, hiding a file type in a comment, is that a hack or not?
So there is the solution. Just do the same in Spin.
{!/usr/bin/phils_spin_mangler.pl}
CON
bla bla
VAR
bla bla
PUB
bla bal
Just have a master script that runs over all your objects reading the comments and applying the appropriate mangle.
(Of course you'll have to be careful not to write the mangled versions over the originals.)
Then compile as usual.
No, Eric, you have it backwards. Core Spin is, and always will be, the lowest common denominator from which compatibility springs. Obviously, if you try to import Enhanced Spin A statements into an Enhanced Spin B program, you're going to have problems. No one is arguing that. But, since both programs can be reduced by preprocessing to Core Spin, you can cut and paste their products with impunity into a hybrid Core Spin program. But if one object requires an eSpin A compiler and another an eSpin B compiler, you're screwed, since there's no common source expression to which both dialects map. Core Spin, in my proposal, is the lingua franca or Esperanto, if you will, for commonality.
-Phil
I think we're pretty close actually in our conception of things. I agree that Core Spin should be the output of the eSpinA and eSpinB preprocessors -- I'm not proposing that they should (only) produce bytecode. Where we differ is whether eSpinA and eSpinB should be invoked by the outside environment (IDE or Makefile) or the Spin compiler itself. I still think it's better to have the IDE do it; I think it's cleaner, and using the file name extension to identify the preprocessor has some advantages. For one thing, if FullDuplexSerial.spin is an extended Spin file, what should the corresponding "Core Spin" file be called? For another, Spin does not currently have a way to output Spin source, does it?
Either way, you need the preprocessor programs available for your platform.
The one exception would be if eSpin had a scripting language built into it and all the extensions were written in that scripting language. Which is a tempting thought, but again I think that should be experimented with in a separate pass and not as part of the core Spin compiler.
The one exception would be if eSpin had a scripting language built into it and all the extensions were written in that scripting language. Which is a tempting thought, but again I think that should be experimented with in a separate pass and not as part of the core Spin compiler.
You could argue that this would be like Lisp macros. They have the full power of Lisp to generate the macro expansion not just simple argument substitution.
I wrote an extended spin preprocessor a couple of years ago. It included #define, #ifdef, #include pre-processor commands. The #define allowed you to define constants like Spin does in the CON section, but you could also substitute strings and implement macros. It redefined the "=>" operator as ">=", and also redefined some of the other Spin operators.
It also added structures, data types and pointers. It used a well-defined standard set of methods for doing string manipulation and conversion between numbers and strings. It also supported formatted input and output. The preprocessor generated standard Spin code that could then be compiled with the Spin tool or BST.
The one exception would be if eSpin had a scripting language built into it and all the extensions were written in that scripting language.
Perl can do it all, it is available on all platforms, and it's embedable. (I can hear the groans already. ) In any event, embedding an already-available scripting language would be better than inventing a new one, if you go that route.
I wrote an extended spin preprocessor ... Phil, are you interested in trying it out?
Sure! And I like the idea that you did it to try new things with the language. That's the kind of freedom I'm trying to encourage. Rather than relying upon "intelligent design" by a few individuals, easy-to-use preprocessor hooks would create an environment where evolution can take place and the fittest language extensions survive. But empowering the user base in that fashion can be a scary notion for some to swallow.
While that is perl strictly speaking, it doesn't go into the ever cryptic symbols like $_ and other perl oddities. The investment in learning the language probably anchors people to it.
Perl does have some redeeming factors: 1) text parsing power with regex, and 2) hash array features. Of course other languages offer similar features without the weird syntax.
Has anyone considered that Perl has a C like syntax and Spin is more Python like? Spin also uses the curly braces for block comments while Perl uses them to define blocks. It's gonna be like mixing oil and water.
While that is perl strictly speaking, it doesn't go into the ever cryptic symbols like $_ and other perl oddities. The investment in learning the language probably anchors people to it.
I've failed to convince Phil that implicit variables like $_ are evil. Perhaps you'll have better luck.
Do you know what you get when you cross Forth, perl and C? Very, very confused.
On a serious note, I would hope there is a Spin2 running somewhere inside Parallax or Chip's walnut grove. At this point in the game, there should be a tool that can generate byte code and PASM to run on the Prop2 simulator. Hopefully, this tool has addressed some of the long hoped for requests for enhancements. Parallax hasn't really said much about language plans except for backing Roy and his OS Spin compiler and the inclusion of Spin support into SimpleIDE.
I think Spin/PASM are still a viable development toolset for Prop2 and would hope there is a professional package available when the Prop2 is available.
Has anyone considered that Perl has a C like syntax and Spin is more Python like?
Many times. It's all very superficial, appearance only.
Yes, C and Perl share squiggly brackets and such but the languages are totally different. Same for C and Java, same for C and C#, same for C and JavaScript and so on. I have car that is red, some flowers are red, are they similar?
Python and Spin? White space indenting, no semicolons, no redundant brackets around if conditions etc. Fine, but see how different they are under the hood.
That was totally wicked. And brilliant. My hat off to you!
Yes, I dangled the bait and Phil went for it -- much the same way that Browser would follow someone holding a nice piece of shrimp. If I have to learn Perl for Phil to learn C then I'll do it. There is an interesting Perl program included with FSRW that converts the orignal C program to Spin. I've attached it below. By the time I figured out how that works I'll probably have learned enough Perl to do some interesting things.
Comments
Seriously, if you find that you want to add lots of the features of C and C++ to Spin, maybe you should evaluate whether it would be better to just write a nice Propeller-specific library for C or a class library for C++ to take good advantage of the strengths of the Propeller rather than designing "yet another language". Leave Spin pretty much as-is for beginners.
1. Compile time checking--types and any other errors the compiler can find.
2. Support for floats. I write a := b * c and compiler writes a:= F.Fmul(b,c).
3. Support for strings.
4. Speed and size optimizations.
5. Better way to handle libraries.
John Abshier
Same here. But I do think Spin is an excellent introductory language for non-programmers. As was BASIC back in the C64 days.
As such it should be kept as simple an free of "line noise" as possible. It does a very good job of that so far what with doing away with curly braces and other redundant brackets and semi-colons etc.
That may well mean that it is never a good choice for large or complex programs, well so what? If anyone hits the boundaries of Spin then they understand the problems and can move on to C/C++ and be in a position to understand why what they are looking at is a lot more complicated.
One of the issues I see with adding language features at the compiler level right away is the problem of validation. It's taken all summer to validate the Core Spin compiler, and apparently the process continues. Every time you add a new feature, that feature not only has to be validated, but you have to revalidate Core Spin to make sure something didn't get screwed up in the process. With a preprocessor approach, Core Spin is left sacrosanct as a fall-back position.
#! /usr/bin/perl
#! /usr/bin/sh
#! /usr/bin/mypreprocessor | /usr/bin/perl
-Phil
Sneaky:)
You're right: it's not a perfect analogy. As you know, the shebang operator is a Linux/Unix thing that directs how a text file is to be processed when given as a command. Windows, unfortunately, does not recognize it. So for true OS cross-compatibility, something like PRE becomes necessary for implementation by the compiler. In the case of Spin, there's an additional advantage to PRE, in that each object can have its own PRE section instructing the compiler how to preprocess the file.
This isn't something I just came up with, BTW. I've been lobbying for preprocessor hooks in Spin for years. It would just make it so much easier to experiment with the language.
-Phil
I mean really, hiding a file type in a comment, is that a hack or not?
So there is the solution. Just do the same in Spin.
{!/usr/bin/phils_spin_mangler.pl} CON bla bla VAR bla bla PUB bla balJust have a master script that runs over all your objects reading the comments and applying the appropriate mangle.
(Of course you'll have to be careful not to write the mangled versions over the originals.)
Then compile as usual.
I think we're pretty close actually in our conception of things. I agree that Core Spin should be the output of the eSpinA and eSpinB preprocessors -- I'm not proposing that they should (only) produce bytecode. Where we differ is whether eSpinA and eSpinB should be invoked by the outside environment (IDE or Makefile) or the Spin compiler itself. I still think it's better to have the IDE do it; I think it's cleaner, and using the file name extension to identify the preprocessor has some advantages. For one thing, if FullDuplexSerial.spin is an extended Spin file, what should the corresponding "Core Spin" file be called? For another, Spin does not currently have a way to output Spin source, does it?
Either way, you need the preprocessor programs available for your platform.
The one exception would be if eSpin had a scripting language built into it and all the extensions were written in that scripting language. Which is a tempting thought, but again I think that should be experimented with in a separate pass and not as part of the core Spin compiler.
Eric
It also added structures, data types and pointers. It used a well-defined standard set of methods for doing string manipulation and conversion between numbers and strings. It also supported formatted input and output. The preprocessor generated standard Spin code that could then be compiled with the Spin tool or BST.
Phil, are you interested in trying it out?
-Phil
-Phil
-Phil
Now, let's C what I need to do.
-Phil
That was totally wicked. And brilliant. My hat off to you!
While that is perl strictly speaking, it doesn't go into the ever cryptic symbols like $_ and other perl oddities. The investment in learning the language probably anchors people to it.
Perl does have some redeeming factors: 1) text parsing power with regex, and 2) hash array features. Of course other languages offer similar features without the weird syntax.
Here is my favorite Perl reference page: http://www.rexswain.com/perl5.html
I dare not look, my brain might freeze over. Like what happens when I visit the IOCCC pages: http://www.ioccc.org/2011/akari/akari.c
If Phil has his way you will be able to do that in Spin as well:)
I've failed to convince Phil that implicit variables like $_ are evil. Perhaps you'll have better luck.
On a serious note, I would hope there is a Spin2 running somewhere inside Parallax or Chip's walnut grove. At this point in the game, there should be a tool that can generate byte code and PASM to run on the Prop2 simulator. Hopefully, this tool has addressed some of the long hoped for requests for enhancements. Parallax hasn't really said much about language plans except for backing Roy and his OS Spin compiler and the inclusion of Spin support into SimpleIDE.
I think Spin/PASM are still a viable development toolset for Prop2 and would hope there is a professional package available when the Prop2 is available.
Many times. It's all very superficial, appearance only.
Yes, C and Perl share squiggly brackets and such but the languages are totally different. Same for C and Java, same for C and C#, same for C and JavaScript and so on. I have car that is red, some flowers are red, are they similar?
Python and Spin? White space indenting, no semicolons, no redundant brackets around if conditions etc. Fine, but see how different they are under the hood.
I seriously hope not otherwise Roy is wasting his time. As far as I know Roy's open source compiler will evolve to be the Prop II Spin compiler.
Wouldn't you want tools soon though if you're going to be sampling chips in ..... oh, never mind! :frown: