Can you declare the data type of a parameter of a spin method?

joeysr20det

Can you declare the data type of a parameter of a spin method? Where something like...

PUB myMethod(variable)


could say that variable is a float...


PUB myMethod(float(variable))



I'm not sure if you can do this with parameters. I need to be able to pass a float as a parameter to a method.

Thanks in advance.

Phil Pilgrim (PhiPi)

No, Spin parameters are typeless. A float, BTW, is just a long, so you don't have to do anything special when passing one. You just have to make sure that the method receiving it is expecting a floating-point number.

-Phil

Heater.

No.

You are just going to have to pass that float the same way as a long.

The programmer has to keep track of the data types in his program manually.

Martin_H

Be aware that when you pass a float you can't use integer operations without converting first. It's easy to make that mistake too and you won't notice at compile time. Instead you'll have to test the bugs out of your code. Oh, if only there was a programming language for the Propeller that let you specify the data type, then warned you at compile time when you accidentally mixed data types until you invoked the conversion function. Think of the time we would save.

Duane Degn

Martin_H wrote: »

Be aware that when you pass a float you can't use integer operations without converting first. It's easy to make that mistake too and you won't notice at compile time. Instead you'll have to test the bugs out of your code. Oh, if only there was a programming language for the Propeller that let you specify the data type, then warned you at compile time when you accidentally mixed data types until you invoked the conversion function. Think of the time we would save.

But then you'd loose any time you gained by having to type a zillion brackets.

There hasn't been a full fledge Spin vs C war yet has there? I keep waiting for it.

Martin_H

Duane Degn wrote: »

But then you'd loose any time you gained by having to type a zillion brackets.

Too funny.

Duane Degn wrote: »

There hasn't been a full fledge Spin vs C war yet has there? I keep waiting for it.

I won't start one because the conflict might cause bad feelings on one side or the other. The Official JavaScript Religious War thread was far enough removed from the core identity of this community that there was no danger of ill will. Plus I was sure that both Heater and I would see it as all in good fun.

However, I would start one if there were rules to make it funny. For example, suppose Team C must argue in favor of Spin, while Team Spin must argue in favor of C. Any time real aggression breaks out you get red carded, put in the "Forth Penalty Box", and now have to argue in favor of Forth. If the Forthers get nasty they get put into the "C Penalty Box", where they have to do their next project in C. That should keep everything mellow and possibly humorous.

The ultimate purpose is that there are things to like in all of these languages, and at the end of the day they all get the job done. What's funny is for a type safety zealot my last two projects have been in Forth, so I'm a huge hypocrite.

Dave Hein

I can understand the freedom of not requiring types in Spin, but it might be a nice language/compiler enhancement to allow for types to be specified as an option. This way the Spin compiler could tell you when you're trying to pass an integer to a method that requires a float. One of the most common coding mistakes in Spin is passing an integer value when the method requires a string pointer. Using types allow the compiler to warn the programmer when this happens.

Another possibility would be to use implicit typing based on the first character of the variable name like Fortran does for integer variables starting with the letters I though N. A naming convention like I_VarA for integers, F_VarB for floats and S_VarC for strings might be a workable solution.

Phil Pilgrim (PhiPi)

Spin, with all its freedom and typelessness seems appropriate for the scale of projects that get done on the Propeller, but I would not want to use it for programming a PC. For that, I prefer a language like Perl, where the type information gets carried along with the value. and any necessary memory allocations, garbage collection, and conversions (or error trapping) are done automatically at runtime. For my tastes, if a language is too rigid, productivity suffers. I would rather just sit down and write code wihtout being bothered by things like header files and malloc. But that's more a matter of personal taste than anything else.

-Phil

Dave Hein

The Spin language does require including a header file -- it's just embedded in the Spin objects that are referenced in the OBJ section. When the Spin tool compiles a Spin object it must parse the referenced object to extract it's constants and method definitions. That's the mechanism for including external object constants, such as clib#SEEK_SET, and it's also how the compiler can check that a method call contains the same number of parameters as the method definition in the external object.

The addition of type checking would just require checking the parameter types in the method call with the parameter types defined in the external object, or even within the same object. Make it optional and it has zero impact on programmers that don't want to use type checking. However, I think the use of type checking would be a great benefit to newbies.

Maybe someone can make a clone of OpenSpin that includes type checking plus some of the other features that people have been proposing. We can try out the clone, and some features may catch on and get incorporated into the official version of OpenSpin.

jazzed

Martin_H wrote: »

However, I would start one if there were rules to make it funny. For example, suppose Team C must argue in favor of Spin, while Team Spin must argue in favor of C. Any time real aggression breaks out you get red carded, put in the "Forth Penalty Box", and now have to argue in favor of Forth. If the Forthers get nasty they get put into the "C Penalty Box", where they have to do their next project in C. That should keep everything mellow and possibly humorous.

LOL!

Novel idea. Maybe it should be a forum rule.

Fortunately there are only a few valuable aspects to other languages [:-1], and people can select from a language standard cliche list when called to the box.

Phil Pilgrim (PhiPi)

Dave Hein wrote:

The Spin language does require including a header file ...

True, but it does not require creating one, since the headers, as you state, are implicit in the objects themselves.

-Phil

jazzed

Phil Pilgrim (PhiPi) wrote: »

Ture, but it does not require creating one, since thd headers, as you state, are implicit in the objects themselves.

-Phil

You can omit headers in C if you don't care for what they contain or reference. Really a bad idea though because it helps catch errors in programs.

Phil Pilgrim (PhiPi)

The other thing I like about Spin vs. C is the lack of need for prototypes. That extra pass makes all the difference!

-Phil

jazzed

Following Martin's rule of language warring:

A plus of Spin is that it allows using byte,word,long etc... for casting data to a given element type.

Heater.

Spin vs C war ?

Nah, not from me.

I have always been a "C/C++ on the Prop" evangelist and I'm fairly sure Spin is totally pointless anywhere else but on the Prop.

BUT the Propeller, Spin and PASM were designed together as an integrated whole. It's that "synergy" thing. The resulting system is small, elegant, powerful and very easy to use.

More concretely I mean:

1) Spin and it's byte codes enable a lot of functionality to be squeezed into the small memory space of the Prop which is hard to do otherwise.

2) When you need speed PASM comes to hand very easily, being integrated into Spin. The Prop instruction set and PASM in Spin makes for one of the simplest assembly language programming systems ever. Almost as easy to use as an HLL.

3) Spin is very easy for beginners to get started with or for the more experienced to knock up a quick project. This is all to do with it's simple syntax, lack types, no header files, the object system and so on.

Spin does not hold a candle to pretty much all other general purpose high level languages from ALGOL and FORTRAN to Java and JavaScript. I can't see anyone ever wanting to implement Spin for platforms other than the Propeller. What would be the point when there are so many better alternatives?

The Propeller/Spin/PASM combination though is a wonderful thing.

I'm with Martin, language wars should be pursued with good humour for a bit of fun. Some would say language wars are pointless bickering and endless regurgitation of old arguments. On the other hand a good language good war debate can be informative and educational for those that don't know much about one or other of the languages involved.

Of course one can get a bit heated when your opponent is to stupid to realize why your preferred language is obviously far superior to theirs

Heater.

I'm kind of against introducing a rigorous type system into Spin. This kind of thing might be nice for large projects but given the expected scale of Prop programs just adds complication to the language and makes it harder for beginners to get into.

I'm dead against having prefixes on variable names specify their type FORTRAN style. e.g. I_myInteger. With that simple change you make nice clean looking Spin code into an ugly mess of underscores and camel case. yuk.

potatohead

I completely agree. My favorite aspects of SPIN are the lean syntax. Yes, you can do really ugly things, but you can do really great things too. I'll take that anytime. Besides, one can spend time testing or one can spend time avoiding a lot of the tests, and then we call the remainder "debugging"