I had a thought, too

When talking about updates, here is something I would use:

proc myProc(argumentList, ...)
'All the variables created in this procedure are LOCAL
'as the main difference between a proc (= procedure abbrev. like func) and a sub or function

'and this proc can go both ways, serving like sub with no value returned, well functions can do that already.

'or a sub serving function-like with
myProc = "" 'if myProc is being used as a sub and no errors found with argument list.
myProc = ME + " error: File not found." 'ah ME, another thought... useful in tracking down errors


Since going both ways might be difficult for parsing, I would probably use this more for functions than subs. You can always use a sub as function to return an error message if it somehow fails to perform as expected. So I would expect to use a proc like a function in a program using the proc eg

procReturned = procName(parameters...)

This would move SmallBASIC more towards modern uses of procedures that do keep everything local without sacrificing compatibility of older SmallBASIC code using regular sub and function.

But of course, start this and someone will be demanding ways to Share variables with procedures other than through parameters list.

But I have been thinking, who needs more than one parameter when you can map all values onto a single variable, specially when not byref.
Ha! so a procedure could always have one and only one argument... crazy? OK, too far... Have I been influenced by fig? ;-))

Mainly, proc would be a place where what is made up in a procedure stays in the procedure. :)

If memory serves me correctly, BBC Basic, used Procedures (proc()) way back in the mid to late 80's. Very cool even that long ago. Still a very cool idea. Oh dear... I know... How 'old' is this guy? I need more coffee...


the way python shares variables is that you use the global keyword inside the function definition:

def funky(p): global x ; print x

#outside the function:
x = 7

funky("") # prints 7 because x is global

That sounds good to me, global keyword inside a procedure, and would distinguish a procedure even more from a sub or function.

But I have no idea what kind of effort these ideas would take to implement.

nor do i. but so far, i think chris is up to it (deliberate understatement.)

i dont ask that sbasic be turned into some kind of python-lite. i think it is close enough to that already, and i mean it in a good way. i mean it in a *really* good way. but there is just enough overlap between python and sb that as new features are added, looking at how python does it is worthwhile-- for those times when at least it doesnt stink in python. because believe me, there *are* some things that stink in python. and for a basic dialect, some of those python things stink more. (case sensitivity and string manipulation are two examples, though one is fixable in python 2.)