Legal Variables in Scripting

[admin]

Looks like I have to enforce some laws on the format of variables in scripting.

I'd like to copy the rules from PHP because they are simple and work well. Here they are:

(1) Variables are represented by a dollar sign followed by the name of the variable.
(2) The variable name is case-sensitive.
(3) A valid variable name starts with a letter or underscore, followed by any number of letters, numbers, or underscores.
(4) A letter is a-z, A-Z (different here from PHP which also allows the ASCII characters from 127 through 255).

Everybody ready to go that way?

[jacky]

Yep, sounds good, and I am. (Well, I might need to adjust a couple of scripts, but that'd be fine/worth it).

[PeterH]

Looks like I have to enforce some laws on the format of variables in scripting.

I'd like to copy the rules from PHP because they are simple and work well. Here they are:

(1) Variables are represented by a dollar sign followed by the name of the variable.
(2) The variable name is case-sensitive.
(3) A valid variable name starts with a letter or underscore, followed by any number of letters, numbers, or underscores.
(4) A letter is a-z, A-Z (different here from PHP which also allows the ASCII characters from 127 through 255).

Everybody ready to go that way?

No problems with (3+4)
(2) do you have a reason for case-sensivity?

But (1)? For the reason to refer everywhere to a variable without respect to form, you must prefix a $ to that form? From my point of view this is a problem of "variables" that are no variables, but kind of text-substitution or so. For me a variable should be "a real thing" having a real name, that should be simple to recognize in coding. Today I can set A to "B" - and it will be very strange...
...if I must prefix $ to the name, and use vars $count and $c - what will happen? And if I change the sequence of the vars - will the result be the same?

So it's correct: a variable should be "one name" - that is 1 word, contain only defined characters like a-z,0-9 and _, maybe case-sensitive, able to destinguish from others (by a separator like blanc, quote, or whatever not in the characterset for names. Then a variable may be named a, and nothing can happen. Your idea of "strings in quotes and variables outside" would have the abilities to lead to that...

Maybe another interpretation of the $; it replaces half of the quotes of a quoted string, you may say "x1=".x1 or x1=$x1-but what, if you have another var named x or $x? No problem for quoted strings and variables as words.

(And sorry: had to use some procedural languages using variablenames prefixed with & - and they were very bad - not only for this...)

[admin]

Looks like I have to enforce some laws on the format of variables in scripting.

I'd like to copy the rules from PHP because they are simple and work well. Here they are:

(1) Variables are represented by a dollar sign followed by the name of the variable.
(2) The variable name is case-sensitive.
(3) A valid variable name starts with a letter or underscore, followed by any number of letters, numbers, or underscores.
(4) A letter is a-z, A-Z (different here from PHP which also allows the ASCII characters from 127 through 255).

Everybody ready to go that way?

No problems with (3+4)
(2) do you have a reason for case-sensivity?

But (1)? For the reason to refer everywhere to a variable without respect to form, you must prefix a $ to that form? From my point of view this is a problem of "variables" that are no variables, but kind of text-substitution or so. For me a variable should be "a real thing" having a real name, that should be simple to recognize in coding. Today I can set A to "B" - and it will be very strange...
...if I must prefix $ to the name, and use vars $count and $c - what will happen? And if I change the sequence of the vars - will the result be the same?

So it's correct: a variable should be "one name" - that is 1 word, contain only defined characters like a-z,0-9 and _, maybe case-sensitive, able to destinguish from others (by a separator like blanc, quote, or whatever not in the characterset for names. Then a variable may be named a, and nothing can happen. Your idea of "strings in quotes and variables outside" would have the abilities to lead to that...

Maybe another interpretation of the $; it replaces half of the quotes of a quoted string, you may say "x1=".x1 or x1=$x1-but what, if you have another var named x or $x? No problem for quoted strings and variables as words.

(And sorry: had to use some procedural languages using variablenames prefixed with & - and they were very bad - not only for this...)

I personally don't care so much about case-sensivity. I would never have 2 variables $a and $A in my code, maybe that's because I come from VB (where this is not possible). I just took this rule from PHP but I would have no problems to change it. But I assume other users would like case-sensivity... ... so I'm open for suggestions...

About $. For once it makes code more readable.
$count and $c: I will check for word boundaries in the next version so $count will never be seen as $c + ount.
If $ is required, then blah$count could/would be parsed/interpolated as blah + $count. If $ is not required and the variable would be named "count" then blahcount could/would not be parsed as blah + count, you would have to do 'blah' . count. So a required identifier makes interpolation easier and more readable. If you don't user interpolation in your scripts (i.e. keep all variables outside of quotes) then there is not much won by an identifer. Again: I'm open for suggestions...

ADD: A required identifier also makes your scripts more robust against future developments. E.g. if you use a variable "date", and in a later stage I add a function "date", it might mean trouble. If all vars begin with $ there will never be any name conflicts (and I don't have to check for reserved words).

[PeterH]

Sorry - wrote most of this reply this morning - but had no time to send. But still think it's worth reading it.

I personally don't care so much about case-sensivity. I would never have 2 variables $a and $A in my code, maybe that's because I come from VB (where this is not possible). I just took this rule from PHP but I would have no problems to change it. But I assume other users would like case-sensivity... ... so I'm open for suggestions...

About $. For once it makes code more readable.
$count and $c: I will check for word boundaries in the next version so $count will never be seen as $c + ount.
If $ is required, then blah$count could/would be parsed/interpolated as blah + $count. If $ is not required and the variable would be named "count" then blahcount could/would not be parsed as blah + count, you would have to do 'blah' . count. So a required identifier makes interpolation easier and more readable. If you don't user interpolation in your scripts (i.e. keep all variables outside of quotes) then there is not much won by an identifer. Again: I'm open for suggestions...

ADD: A required identifier also makes your scripts more robust against future developments. E.g. if you use a variable "date", and in a later stage I add a function "date", it might mean trouble. If all vars begin with $ there will never be any name conflicts (and I don't have to check for reserved words).

Case-sensitivity: you are right, not important. I'd just prefer non-sensivity.

About $ (First I must say, I don't want to offend - just say my understanding, my feeling, whatsoever...)
If $-prefix for varnames make code more readable, this is because structure of the code is bad. I know of some interpretative languages, but for none the problem is "the missing variable-prefix". I still think this prefix is only needed, if the concept of the language requires it - especially if variables are not simply to distinguish from "other" text. If they are distinguished from text, you will see them, even without such a leading $ or & or whatever.
Much of the work for this will be done, when you check for word-boundaries of varnames! (Very good against my $c / $count sample ) Rest seems to be this "variables can be specified inside (some) quotes"!
Your blah$count sample: I'm pleased, too, if this is not a variable. But if I you have to split it (blah.$count or 'blah' . $count), some more of the necessity for the $ is lost, again.
But: my sample was for $blah$count - beeing interpreted 2 times, from right to left! (Don't get me wrong - that's a bad way to construct kind of indexed variables. But if it's the only way? Of course, real indexed variables would be better )

And sorry - must come back to something I said weeks before! All this we talk about "is not XY", but creation of a language just supporting XY. All the time spent for such things, by creating a very simple language to support kind of XY-automation, could be solved by using an external language like ooREXX. Never again thinking about how to define variables, programming that, later on finding some problems, changing it, (and people have to change all their execs,) somewhen noting, that requiring people to change isn't acceptable and keeping bad ideas. (Have I mentioned "indexed" variables?) Then the same for program logic like do/end, if/then/else, select, ... For the concept of defining and calling subroutines and functions. For some string, arithmetic, bool, ... functions. File reading/writing. Debugging. Error handling. Substitution and interpretion...
You can program for a year, and just have a simple subset of what such a system could do. And what you do is not XY -it's just something to support it!
I still think that, on using an external scripting-system with some "handmade" interfaces for XY, you could have an extremly powerful and consistent language, and concentrate yourself on that, what XY is: filemanagment.
And of course: this way would also have some disadvantages. But from my current point of view I think the advantages would be more. Correct my, if I'm wrong...
And now realtime-text...
Found 7.50.0001. Yet this is "not exactly what I would want" - but from my point of view a very very good improvement to your scripting-syntax!

PS One reason for my positive saying is, that variables start to be "real variables" - not this "kind of substitution" they were before. Really good!!

[admin]

Found 7.50.0001. Yet this is "not exactly what I would want" - but from my point of view a very very good improvement to your scripting-syntax!

Thanks!

Using an external language is something that does not appeal to me. Maybe I'm a control freak but I like fix my own bugs.

I could drop the need for $ (even could make that a user-option) without having to change anything. The scripting engine runs perfectly without $ identifiers. Now. But in future, when I might add conditions, functions, loops, it might make parsing a lot easier (for me!) if I can rely on an variable identifier.

[PeterH]

Using an external language is something that does not appeal to me. Maybe I'm a control freak but I like fix my own bugs.

I could drop the need for $ (even could make that a user-option) without having to change anything. The scripting engine runs perfectly without $ identifiers. Now. But in future, when I might add conditions, functions, loops, it might make parsing a lot easier (for me!) if I can rely on an variable identifier.

First to the $ - the main problem isn't the $ itself - even though I don't like it. The problem is the concept of a "language" where you think you need this prefix!
For (a restricted) example: there is no problem to distinguish between <clipboard>, a variable clipboard, and a function clipboard(...), isn't it? Especially, if var-names have to be "complete words", as well as function names.

And then again (I will try to do this for the last time) something to the idea of an "external scripting interpreter". But I still think it's important to talk about that...

On one side I understand, that you want to make "everything" by yourself. As it will have "your own bugs". And I think, as it's interesting and some kind of fun :-)
But you do use Windows, VB, Installer, Packer, VB-Routines, System-Functions, ...
Sometimes I read "the used Windows-API works like this", "it's the shell that..." and such. I think you could make it better - but you don't have the time - and have more things to do. So you do use these not-own "functions"
OK - there is a little difference between these things, and an external interpreter on the user PC, but at least I think there are same analogies...

I'm afraid, when your scripting is ready, you will know quite much about the concepts of scripting you should have started with. One example is the change in use of variable names from beginning to now - and I'm afraid, that such things will often arise... And if you find things that shpuld be changed, you will not frequently be able to tell the people, that syntax has changed and they all have to change their scripts...
As was with the mentioned REXX: that language was designed, maybe 30 years ago, by people having made some other interpretative languages before, and having learned very much from all the problems they had in those systems. (Though these still can be used today - but nobody likes them.) REXX was enhanced all the years to be as reliable as needed for mainframe-automation. And later was ported to PC. (At that time as a comercial product.) And after all, *this* was given to the "REXX Language Association" in the Open Source community, to people still enhancing the functions.
So I think I'm right to expect REXX is very reliable, and a very "complete" and consistent language! And all problems you will have in the next years(!) with defining a language, and programming an interpreter for it, has been done by these people, over years and years!

This is the reason why I would ask you to possibly think one more time about using an "external interpreter" for scripting. I'd expect that you could save *very* much time, and have a much better result! (In sense of concept for the language - not for the programming you have to do.)
But it's no question: it would need "some" work for you to supply an XY-interface to REXX - only then it would make sense.

Maybe there are other people knowing about other "products" usable for this task? For my kind of view it must not be ooREXX - maybe there other products? But I only happen to know of this one.

But, after all: finally it's your choice...

[j_c_hallgren]

Maybe there are other people knowing about other "products" usable for this task? For my kind of view it must not be ooREXX - maybe there other products? But I only happen to know of this one.

Not sure if this would work in this case, but I heard Leo Laporte mention he was looking at http://www.Lua.org/about.html.

[PeterH]

Maybe there are other people knowing about other "products" usable for this task? For my kind of view it must not be ooREXX - maybe there other products? But I only happen to know of this one.

Not sure if this would work in this case, but I heard Leo Laporte mention he was looking at http://www.Lua.org/about.html.

Basically you seem to be right, it also seems to be usable as a script-system to expand other applications.
I had a short look at the documentation - but must say: I didn't understand very much. If someone knows about LUA, some short samples could help, maybe? But my impression is, that LUA is optimized on handling of arrays and such - this isn't what's needed here. And to me it seems as if the syntax is less of "straight forward" compared to REXX - but maybe I see this wrong!

For both I can't say how easy they are to integrate into a VB-System, for both I found notes especially for c/c++, so I only can hope it's possible for VB, too. (This is necessary for the scripts to call XY-commands, used to return values like files / selections / dates / attributes, or to do actions like select / copy / delete.)

[admin]

Using an external language is something that does not appeal to me. Maybe I'm a control freak but I like fix my own bugs.

I could drop the need for $ (even could make that a user-option) without having to change anything. The scripting engine runs perfectly without $ identifiers. Now. But in future, when I might add conditions, functions, loops, it might make parsing a lot easier (for me!) if I can rely on an variable identifier.

First to the $ - the main problem isn't the $ itself - even though I don't like it. The problem is the concept of a "language" where you think you need this prefix!
For (a restricted) example: there is no problem to distinguish between <clipboard>, a variable clipboard, and a function clipboard(...), isn't it? Especially, if var-names have to be "complete words", as well as function names.

No. When interpolated these are ambiguous.

And if you find things that shpuld be changed, you will not frequently be able to tell the people, that syntax has changed and they all have to change their scripts...

If I model scripting after PHP this should not happen very often if at all.

[RalphM]

If I model scripting after PHP this should not happen very often if at all.

That made all the difference for me...

I was just about to suggest you could at least take a copy of a users reference of any scripting language and then stick to those definitions for the future enhancements to scripting.
This approach would still allow you to fix your own bugs, while being consistent with another scripting language.

@PeterH: I used to work with REXX as well, back in my IBM mainframe days, and was quite happy with it.
Later on PC I rather used Perl instead.

[j_c_hallgren]

I used to work with REXX as well, back in my IBM mainframe days, and was quite happy with it.

We may have that in common! I did a bit of REXX on IBM mainframes also!
When I wasn't doing COBOL or a bit of S/370 assembler.

[PeterH]

... there is no problem to distinguish between <clipboard>, a variable clipboard, and a function clipboard(...), isn't it? Especially, if var-names have to be "complete words", as well as function names.

No. When interpolated these are ambiguous.

(Is usage of "interpolated" correct here? I'd use "interpreted" - but can be wrong.) Could it be this wording, but I don't understand what you want to say - or why you think so.
Maybe it's my expextation how the text of the script is analyzed *before* interpretation. And if clipboard(...) is a function, it cannot be a variable. Further if <clipboard> is a system-var, it's substring clipboard also cannot be an internal var...
(Not my idea: this is REXX :-) )

And if you find things that should be changed, you will not frequently be able to tell the people, that syntax has changed and they all have to change their scripts...

If I model scripting after PHP this should not happen very often if at all.

This sounds correct! If you, in future, will lean on the syntax of another interpreter, and do this quite close, a lot of the problems I mentioned can be avoided! (I didn't have the impression till now, for example for the history of "variable names".) But if you do, this can help a lot!
I'm not familiar with PHP at all - so I don't know how "good" it is. (Though I have some restrictions.) But the advantage will be, that there will be several people beeing familiar with PHP - more as with REXX :-)
(And, of course, anyone will prefer, at least a bit, a syntax he is used to know and to work with...)

Good to hear from some mainframers having used REXX. I needed it for "some" system automation in NetView...

[admin]

... there is no problem to distinguish between <clipboard>, a variable clipboard, and a function clipboard(...), isn't it? Especially, if var-names have to be "complete words", as well as function names.

No. When interpolated these are ambiguous.

(Is usage of "interpolated" correct here? I'd use "interpreted" - but can be wrong.) Could it be this wording, but I don't understand what you want to say - or why you think so.
Maybe it's my expextation how the text of the script is analyzed *before* interpretation. And if clipboard(...) is a function, it cannot be a variable. Further if <clipboard> is a system-var, it's substring clipboard also cannot be an internal var...
(Not my idea: this is REXX :-) )

I would not recommend it but currently this works:

Code: Select all

::set $getInfo, "file"; msg "This is ". $getInfo(file);

$getInfo(file) is an unquoted string where $getInfo is interpolated. Without the $ it would be ambiguous with a function getInfo().

[PeterH]

I would not recommend it but currently this works:

Code: Select all

::set $getInfo, "file"; msg "This is ". $getInfo(file);

$getInfo(file) is an unquoted string where $getInfo is interpolated. Without the $ it would be ambiguous with a function getInfo().

Sorry: I don't understand this code at all. Maybe there's an error in it?
($getInfo is setted to "file"??)

What I wanted to say: a name followed by "(" is (from my point of view, or from REXX...?) a function, not a variable. So if you recognize a name as a function name, you should not interpret it as variable name.
With this, your 2nd statement would expand to call the function $getInfo with parm file - where file is an (undefined?) variable?

Just another question: does RPG require the set-command to set a variable? So there's no construct:
$a = $b;

Or is it just not been defined by you?