More DOT NOTATION SYNTAX features for spin? ( Type Ahead)
DavidM
Posts: 630
HI,
If anyone is familiar with the REALBASIC IDE, it has a "TYPE AHEAD" Feature activated by pressing the TAB Key after a FULLSTOP is typed in after any variable or method name.
With this in mind It would be cool if lets say I type in
Then I press TAB, I would get a popup list of ALL the options that can be typed in after the dot, Including METHODS, VARIABLES and CONSTANTS
eg.
and while I am at it, you could then ACCESS DEEPER into other objects ( properties) that are nested in those objects
Then would could SET or GET Variables easily without having to switch to the object and scrolling a round or trying to remember them, also only QUALIFIED items would apear, for example PRI methods and local variables would not list.
To reference the variable by LOCATION ( ADDRESS) we could use.
which would appear in the TYPE AHEAD Feature.
we could also use this for LOCAL methods and variable by using
And last but not least this could be used as a way of ACCESSING Global Variables of parent objects?
---
I think this could be an OPTION setting in the SPIN Preferences and would also be a great TEACHING aid. as the TYPE AHEAD feature can show you what is accessible.
What do you think?
Dave M
Post Edited (DavidM) : 7/26/2010 5:56:47 AM GMT
If anyone is familiar with the REALBASIC IDE, it has a "TYPE AHEAD" Feature activated by pressing the TAB Key after a FULLSTOP is typed in after any variable or method name.
With this in mind It would be cool if lets say I type in
Object.
Then I press TAB, I would get a popup list of ALL the options that can be typed in after the dot, Including METHODS, VARIABLES and CONSTANTS
eg.
Object.Method ( for a method ) or Object.Variable ( for a variable in that object )
and while I am at it, you could then ACCESS DEEPER into other objects ( properties) that are nested in those objects
MyMethod.Object.Method or Method.Object.Variable etc
Then would could SET or GET Variables easily without having to switch to the object and scrolling a round or trying to remember them, also only QUALIFIED items would apear, for example PRI methods and local variables would not list.
To reference the variable by LOCATION ( ADDRESS) we could use.
MyVariablePointer := Object.Variable.Pointer
which would appear in the TYPE AHEAD Feature.
we could also use this for LOCAL methods and variable by using
Me.Method eg.
And last but not least this could be used as a way of ACCESSING Global Variables of parent objects?
---
I think this could be an OPTION setting in the SPIN Preferences and would also be a great TEACHING aid. as the TYPE AHEAD feature can show you what is accessible.
What do you think?
Dave M
Post Edited (DavidM) : 7/26/2010 5:56:47 AM GMT
Comments
Seriously, I think parallax has created a good tool without major bugs. But as it works so well the pressure to add features is very low. And each enhancement of course costs money. Are you willing to pay for it? Parallax rather spends it's manpower in developing new things that generate income. And that's pretty feasible to keep the company alive.
If you want new features the best way to go is: do it yourself - either using Eclipse or one of the third party SPIN compilers as a basis.
One thing is that the PROP 2 would probably have some extra features requiring support of a revised SPIN IDE APPLICATION, so it wouldn't be a bad Idea to include these features during that development.
Also, why can't the IDE be continually improved?
I know nothing about creating IDE's so ( although I do a lot of development in realbasic, I believe that application could be used, as Realbasic was written with Realbasic) an advantage of this would be you could create PC, MAC & Linux version at the same time.
And yes I would be willing to PAY FOR IT , so long as a MAC version was available. If they wrote the SPIN IDE in realbasic then they could have easily supported multiple platforms.
Another way to look at it, if Parallax released these features tomorrow would you use it? Would it make programming easier for you?
besides I am only asking people opinions of the idea, whether PARALLAX does it, or not is up to them.
regards
Dave M
There are hundreds, maybe thousands of programming languages and their compilers/interpreters available for free. Complete with source code. That are cross platform, Windows, Linux, Mac, and more.
Anyone with the skills to create a nice compiler is more likely to use one of those. Case in point, BradC has made the great cross platform BST Spin/PASM compiler and IDE in Pascal.
Now the question might be should someone like BradC start extending the Spin language that his creation can handle? Or should he keep it as compatible with the Prop Tool as possible?·Do we want to split the world of Spin software into that which can be only compiled on say BST with Spin extensions and the rest that is Prop Tool compatible? Does someone like BradC have the motivation to create an incompatible language?
BradC has already added some fairly minor features to his PASM assembler that were suggested by users. I think he spent a good while pondering each one of those features as to whether it was a good idea or not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yeah, it's actually a good idea. Once a programmer gets used to using it, it can speed up productivity quite a bit.
I believe that the current Parallax IDEs are created with Delphi, which is basically Object Pascal. As such, it's not likely that it would be ported to RealBasic. Whether autocompletion is ever added or not probably depends on customer demand.
FWIW, I personally think they should freeze their current IDEs and using something like Eclipse or Netbeans, create a single, modular, cross-platform IDE that would be used for at least the BS1/2 & Propeller. The SX is EOLed, so it is what it is. Making the IDE plug-in capable would open it up to others to add whatever features that they want.
Ok, AUTOCOMPLETE is what its called , It is a great feature, but a KEY benefit would be if we could ACCESS VARIABLES as I have mentioned, I don't believe the ROM INTERPRETER would need to change, its all done in the IDE/Compiler. ( I could be wrong )
Your last suggestion of an open source multi-platform IDE sounds brilliant!
Dave M
Is it really useful when programming tiny applications for the Prop in Spin? I can see it helps a lot when you are using the huge libraries with millions of classes as methods like you find in the Java world or using the Qt graphics libs. Then auto completion can save you having to consult the manuals quite so often.
I'm a bit loath to saddle newcomers to programming or casual programmers with Eclipse though. It's huge and complicated. I've just be through getting Eclipse up to work for Android development. It's for sure not the click and go convenience of the Prop Tool or BST.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/26/2010 11:21:35 AM GMT
I think that has already happened. A clever chap called 'heater' came up with a zicog program last year and in order to get it to work on many platforms, it needed lots of #include statements. Only BST supports these.
Actually, listing off the top of my head all the Propeller programs I run - Kyedos, Zicog, Nascom, Colour Genie, TRS80, qZ80 ; only one of those will compile on the PropTool (KyeDos). All the rest will only run on BST.
So for me the world of Spin has been split long ago. Which of course does mean that Brad or anyone else could be free to add as many features as they like. Comments from Brad?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Currently ( with spin) if you want to access a variable in an object you have to have a method in that object to SEND IT BACK , and you will need that for each different variable, with dot notation you don't need any extra code!
I still think the biggest benefit would be accessing methods, variables or constants from ANY OBJECT specifically parent objects.
to me its a small addition to the IDE but MANY BENEFITS!
Dave M
Ah yeah. The original idea with ZiCog, and this may still be true, is that there were #ifdefs to select different code for different hardware Platforms. If one really wanted to compile the thing with the Prop Tool it would be an easy matter to go through the code and delete all the parts that don't fit your platform. They are all clearly marked with #ifdef after all.
Looking at Catalina I think I spotted that RossH has a lot of #ifdefs in some modules, but he supplies a tool to pre-process those away so they can be compiled with the Prop Tool. A logical automation of the idea.
If one were to put more complex features into BST or other Spin, say bit fields or floating point, it would start to become too complicated a job to hack the modules back into something that the PropTool can handle.
That's my excuse anyway [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes it probably is a space saver. And it's probably easy to add to the Spin language. Very enticing.
And it is inherently a really bad idea. Why?
Spin module A wants to read Spin module B's data directly.
We can't do that now so we introduce a new syntax and can write x:=b.y and such like.
But often Spin module B is running something as a different task in a different COG.
So soon people will be making randomly failing programs that may be very hard to debug because variables are being up dated and read in some out of order fashion by the two tasks.
Lets say I write
x := b.x
y := b.y
and these x's and y's should be maintained together, perhaps they are position coordinates. Clearly without locks around the accesses things are going to start to go wrong. The newbie programmer will do this, find the thing fails and give up in frustration perhaps not realizing the problem.
As it is now you need access functions to get/put data from other objects. Which at least forces you to think about what might happen and save you from disaster. And if you have to put locks or other thread safe guards around your accesses then you may as well do it via an access function in the object you want to use, as we do now and where they belong, rather than in the caller, where they don't belong.
If you still feel the need for a.x notation it's time to move to C++ were you then have the luxury of allowing access or not (public vs private members) or using access functions or direct access.
A harmless looking and simple language feature like this can lead to a world of pain, especially for newcomers, which Spin tries it's best to avoid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For us power users (or platforms other than windoze) bst is the way to go. I use both bst and PropTool. If the program is simple I prefer to keep it so that PropTool can compile it even though bst gives me better control, such as giving warnings for jmp xxx where # is missing/forgotten. A listing can be good too at times.
There are some features that would be nice to have in bst such as macros, include and perhaps inline pasm or LMM. However, I am not advocating recking the spin commands/syntax with all sorts of extensions. I am pleased Brad is cautious to add extensions without a lot of input to the viability of them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
b_ptr := b.get_data_ptr
x := LONG[noparse][[/noparse]ptr + 0]
y := LONG[noparse][[/noparse]ptr + 1]
This of course is a maintenance nightmare as any change in the data structure causes the need to update two objects source code in stead of one.
However it is useful for passing "mailboxes" around that enable cog to cog communication.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am not understanding your examples , I cannot see how this is a bad idea? Are you talking about semaphores ?
sorry , but can you explain a different way?
thanks
Dave M
I've got all sorts of things I'd like to add to BST. eg the little arrow thingies that indicate indents are very nice in the proptool and sometimes I copy and paste code from BST to proptool just to get my head around the structure.
I like writing code in .net. Years and years of work have gone into the .net IDE environment. It is now quite hard to write code ine the 'wrong' way. Syntax errors are flagged with wavy lines under then as you write them, so there is no need to compile to find a lot of errors. Indents are automatic and update whenever a line is changed. Dot.notation syntax and .autocomplete with dropdown menus makes selecting things easier. Define MyVariable at the beginning of a subroutine and then write myvariable in smalls, and it autochanges to MyVariable. Nested(brackets(likethis)) will flag if brackets don't match. If you try to call a subroutine and misspell the name, it tells you as soon as you leave that line.
In an ideal world, all these things would be in an IDE. But I suspect they are a lot of work to add.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
All these features exist because programming is a (expletive), anything that makes typing it ( or organising it) is very welcome, if these features exist in other tools, then theres no reason why we can't WISH for them for the PROPELLER!
Remember that we don't even have a built in debugger?
Dave M
Suppose we have a Spin module "gps.spin" handling a GPS device.
The data coming out of that module is longitude, latitude, altitude, velocity, and direction.
This data gets updated every minute or possibly at random times whenever the unit gets a good fix.
Now our main object tries to read this data with the new dot notation. So we write soomething like:
[noparse][[/noparse]/code]
longitude := gps.longitude
latitude := gps.latitude
altitude := gps.latitude
speed = gps.speed
direction := gps.direction
[noparse][[/noparse]/code]
Perhaps we test this code and it works fine. Then we build a huge application around it. And then one day we realize that every now and then our quadcopter, robot or whenever it is spins out of control and crashes. We test the code again and again but its just fine. Just that every now and then things go wrong and the thing crashes and burns. We get frustrated and give up.
What could be going wrong?
Well if the gps object happens to update all that position information at a time when our main object half way through reading it, all of a sudden we have a totally wrong position and heading information in the main object. Lat and long might be old data, speed and direction may be new data. Boom we crash.
This situation has to be guarded against with locks or some other technique to make it "thread safe". If there is only one reader and one writer of the info then it can be done without locks, a simple flag (semaphore) will do. If there are many readers perhaps locks are required. Even with many readers it is possible to do without locks.
Anyway, using locks or other technique it will probably make sense to wrap the whole data access thing in a function. And it would be better for that function to be in the gps object. That saves having to rewrite it in every new main object you create that uses gps.
So, my conclusion is that the simple, harmless looking a.b notation is actually not much use and can be dangerous in unexpected and hard to fathom ways.
This partly why the idea of "data hiding" has been around for such a long time and is implemented in Spin with objects that have no "dot" notation for member data.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jees, every time I express my view that delimiting blocks with white space is a really bad idea there is a heated defence of it. You have just nicely summed up my whole problem with it. If your code had braces or other visible block delimiters it would be a lot less easy to get into a muddle no matter what editor you use. The fact that the Prop Tool has that indent/block highlighting feature just shows how serious a problem it is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
don't get me going. No don't. Oh darn - here it comes....
/* begin rant */
My dislike of Spin started when I started editing the VT100 code. This has huge chunks of nested 'if' code, and the tricky bit is that much of this code spans more than one page on the screen. Sometimes, when changing this I might accidentally add just one space. And the syntax of an 'if' definition would change two pages down! It wasn't even visible. It is only possible to spot this in the Proptool if you keep a very close watch on those arrows.
Some people say Spin is like C. Or like Basic. Or like Pascal. No, to me, the closest language to Spin is this joke language whitespace en.wikipedia.org/wiki/Whitespace_%28programming_language%29
That is just my crazy opinion. Please ignore me if you disagree...
Spin assumes that the IDE has those arrows (editing Spin is much harder in BST). Editing spin is all but impossible if you copy and paste it into a text editor and use a 'non terminal' font like Arial or Times Roman. It has to have a font like Terminal or Courier so the columns line up. Not every text editor defaults to Courier. And if I am writing an IDE (I've written several), the first thing you add to a Form is a RichTextBox. Arrow thingies in a RichTextBox, anyone?
/* end rant (sort of) */
But let's look at this in a positive way. How do you turn a negative into a positive? Well, consider the problem of an IDE that autoindents a program where the programmer has put one space then two spaces then one space. The autorouter can guess they mean two spaces. Or maybe guess they mean one space. It isn't easy though. And it may well change the syntax. What if they wrote it in a text editor and there are Tabs and Spaces interspersed. Is a Tab worth 5 spaces? Or 9?
I think an autocompleting IDE with auto syntax checking, auto .notation and all the other helpful features might actually struggle to work with Spin. There are too many ambiguities. Ambiguities might be good for a poet, but not so good for a programmer.
Deep down, I'm a Basic programmer. But the more I think about this, the more I am drawn to the incredible simplicity of the C { and }
With just these two characters you can define all indents automatically. If there is a { then indent by two spaces. Or a Tab. Or 5 spaces. It doesn't really matter, because a } goes out by the same amount. Any badly indented program can be reconstructed if you have { and }. Heck, you can even put the whole thing on one line and it can be automatically rebuilt to a proper indented structure.
Would it cause rioting in the streets to suggest adding { and } to spin? Are the crowds going to be coming for me with pitchforks and blazing torches? Yikes, I'm off to hide. Hmm, this sign says "Nursing Home for Old-School Programmers". They will never find me here...
@DavidM All these features exist because programming is a (expletive), anything that makes typing it ( or organising it) is very welcome, if these features exist in other tools, then theres no reason why we can't WISH for them for the PROPELLER!"
Yes, yes and yes. I delight in writing code in an IDE that happily writes half my code for me, without me even having to think about it. Thankyou for starting this very interesting discussion.
Thinking about this more, .notation should be fairly straightforward. Take any existing object. List all the calls (search for PUB and PRI) Put them in a ComboBox. If you type the name of that object, up comes the Combobox. It need only be one level deep. Then the next automatic listing is the variables passed to or from that subroutine. So for the programmer, with a few keypresses you can see all the subroutines in an object, find the right one with a few characters, and then with a few more characters ensure you pass and return the right number of variables. It would make things a lot easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 7/26/2010 2:14:30 PM GMT
The other side of that argument, of course, is that way it works now allows the object's programmer can determine which values to reveal, possibly preventing the uninitiated from "breaking" an object by incorrectly manipulating one of its variables.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Just the other day a colleague of mine who is quite a wiz with Python and likes it very much was cursing at some editor he had opened his code in that messed up the white space indenting.
I say it's not the editors fault.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yoda
I would think that if enough people cared, it would be utterly trivial to add END statements to the BST version of Spin and a word that would disable indentation awareness. I would think it would be equally trivial to provide an 'export to proptool' function that would go through commenting such END statements and forcing the proper indentation.
For that matter while Spin bytecode is a poor fit to C, it is a pretty good fit to BASIC and it should be fairly simple to write a compiler that would compile a more BASIC-like language, supporting GOTO and with a more flexible memory model than Spin's objects allow. It is absolutely horribly difficult to reclaim PASM image memory in Spin; this could easily be improved.
I would probably be doing something like that myself but I've realized that no matter what I will need more than 32K for user interface intricacies and other relatively slow code, so I'm working on a way to run byte code directly out of EEPROM -- which requires a different interpreter that has the EEPROM driver embedded, so it doesn't have to be Spin compatible.
Thanks for that better explanation,
I understand now what your were getting at, BUT I don't think that AutoCompleted, or DOT.NOTATION has anything to do with the problems you are suggesting they could create,
Would I have a function in the CHILD OBJECT to gather a bunch of variables that need to be calculated at the same instance, yes I would, thats because those variables you mentioned are related to each other in a time critical manner, the programmer would know this. ( or should know this) nothing to do with the language
regarding, locks, in most case where you think you may need semaphore, you can usually code up some other way. We have LOCK in spin now, I have never needed them. but its nice to know that it there.
Also, remember that PRI & PUB access would be regarded in dot.notation.
Regards
Dave M
Hi JonnyMac,
Yes you have a point about SETTING a variable in a CHILD OBJECT, That could be messy, But the advantage is LESS CODE ( memory required) , reading a variable with DOT.NOTATION is pretty much a non issue, if you do need to WRITE to a variable, then more than likely you would set up those variables in the CHILD OBJECT specifically to be only written by one EXTERNAL PARENT METHOD.
thanks
Dave M
"Dot" notation is a language feature and it worries me.
Yes perhaps you would have a function to collected related time critical data, but my worry is that new comers to programming might not think to do so and find themselves in a mess as I described above. Yes "the programmer should know this" but my point is that beginners don't. So as a language for beginners Spin should try to keep them safe by not having direct access to data via ".".
Introducing the idea of PRI and PUB applying to data to provide data hiding (which we already have) having implemented "dot" notation is another unnecessary language feature. Now needing to be thrown in to fix the problem with "dot" notation. That's the difficulty with language design, one little feature causes the need for another little feature and so on until you end up with C++ or ADA. Again I say Spin as a beginners language should not go down that road.
Re: locks, same here. I have yet to find myself in a situation where locks are required when programming the Prop. Cyclic buffers don't need them if there is only one reader and one writer.
Command/response mailboxes don't them for one master one slave use and the semaphore can be hidden in the command field.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
ViewPort's code editor supports basically all the functionality found in Visual Studio- including:
1 outlining (being able to selectively collapse sections of code)
2 all sorts of editing/navigation/bookmarks
3 macros
4 regular expression search/replace
and finally- "IntelliPrompt" which is a superset of the "autocompletion" discussed on this thread:
*Code snippet
*Member lists
*Complete word functionality.
*Parameter info tips
*Quick info tips that show detailed information about what is under the mouse.
*Smart tags that show when the mouse hovers over their indicator, and display a popup when clicked.
Items 1..4 are already included in ViewPort for both spin and c files. I'm working on Intellipromt....
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer