XYplorer Beta Club

Posted: **10 Feb 2008 15:18**

Why did I choose "::" as script marker (beginning) and command separator (between commands)? Obviously because I needed a short sequence that was very unlikely to be found anywhere near.

It does the job. But I do not really like it.

It makes the scripts look klingonian in a way.

Why not simply take "; " (semi-colon+blank) instead (as separator, not as marker)!? Okay, it sure is more likely to be found than "::" but up to now it never happened to me. And the scripts would look much more natural to everybody who ever saw a bit of C, Perl, JavaScript, Java, PHP and so on and on.

Compare Now and Then:

Code: Select all

Caption : label
  ::set $path, <curpath>
  ::goto Desktop|
  ::sortby m, d
  ::selpos 1
  // foc list
  ::#1016
  // copy
  ::#201
  ::goto $path

"Caption" label;
  set $path, <curpath>;
  goto Desktop|;
  sortby m, d;
  selpos 1;
  // foc list
  #1016;
  // copy
  #201;
  goto $path

Or compare these:
Now: ::step::filter *.png;*.pdf::goto Desktop::focus list::selpos a::backupto Desktop\<dyyyymmdd>::filter

Then: step; filter *.png;*.pdf; goto Desktop; focus list; selpos a; backupto Desktop\<dyyyymmdd>; filter

BTW: The script marker at the beginning is anyway needed only in non-script contexts, i.e. where locations are expected.

Posted: **10 Feb 2008 15:34**

admin wrote:Or compare these:
Now: ::step::filter *.png;*.pdf::goto Desktop::focus list::selpos a::backupto Desktop\<dyyyymmdd>::filter

Then: step; filter *.png;*.pdf; goto Desktop; focus list; selpos a; backupto Desktop\<dyyyymmdd>; filter

The only potential problem I see is the continued use of ";" as parameter delimeter also, as bolded above...if we're changing to convert to a Perl style, then a comma and/or space would be more appropriate here...otherwise I have no issues with this...and it does seem more readable!

Posted: **10 Feb 2008 15:40**

j_c_hallgren wrote:
admin wrote:Or compare these:
Now: ::step::filter *.png;*.pdf::goto Desktop::focus list::selpos a::backupto Desktop\<dyyyymmdd>::filter

Then: step; filter *.png;*.pdf; goto Desktop; focus list; selpos a; backupto Desktop\<dyyyymmdd>; filter
The only potential problem I see is the continued use of ";" as parameter delimeter also, as bolded above...if we're changing to convert to a Perl style, then a comma and/or space would be more appropriate here...otherwise I have no issues with this...and it does seem more readable!

Just like with the argument separator (comma+space) the new command separator would be "; " (; + space!). Then "filter *.png;*.pdf" is no problem. Only filter *.png; *.pdf (added a space!) would be...

Posted: **10 Feb 2008 16:00**

Well, I still think that if we convert to "; " as cmd delimiter that the parameter delimiter should be another character totally...just to avoid any possible confusion...even IF the ";" is what is used when the cmd would be typed in normally, then it would have to be modified to be used in a script...I don't recall that ";' can be used in Perl (not an expert at all) other than as a command terminator.

Posted: **10 Feb 2008 16:17**

j_c_hallgren wrote:Well, I still think that if we convert to "; " as cmd delimiter that the parameter delimiter should be another character totally...just to avoid any possible confusion...even IF the ";" is what is used when the cmd would be typed in normally, then it would have to be modified to be used in a script...I don't recall that ";' can be used in Perl (not an expert at all) other than as a command terminator.

; is the de facto standard for concatenating filters in Windows. Hell knows why.

Posted: **10 Feb 2008 16:19**

I like it the way it is at the moment. True, you can use syntax like in other languages, but you allready have reinvented the wheel, so why don't use it continously.

I also think :: is a good solution because its depents on characters that would never be in a filename (like all these chars: \ / : * ? " < > |). A ; can also be part of a filename (and I use it sometimes as replacement of a :).

When you plan to convert the syntax anyway then should it come close to common known syntax and that ";" and "; " have a totaly different meaning it everything else then that (and also a littlebit confusing because one space can change the meaning of the whole script).

Here are also some ideas for the syntax (either new or old):

usage of quotes " for example to be able to use somthing like this: ::msg "::msg"
usage of brackets ( and ) which will include all parameters of a command. e.g.: ::filter(*.png;*.jpg) that would it also make it possible to use the same seperaters for commands and parameters without that nasty required space
with combination of both of the above you can also kick out the ::sep-command because you can do somthing like this: ::input($txt,"input something here, or abort","This title can have , :: and any other character except the quote, but maybe we can escape it so we can do something like \"this\"")::msg($txt)
ignoring of spaces, so that "foo,bar" and "foo, bar" and "foo , bar" and "foo ,bar" works as the same. Where foo and bar can also be a quoted text

I don't know how you implemented the script parsing, when you simply split the strings on the seperators then it would be a littlebit more work to implement that stuff, but when you only step from one character to the next then it would be pretty easy (I think), because when you found a " you only have to read everything as argument untill reaching the next " not prefixed by a \ ...

Posted: **10 Feb 2008 16:29**

admin wrote:Okay, it sure is more likely to be found than "::" but up to now it never happened to me.

Yeah, and not that it happened to me either, but the difference is that it is very unlikely that :: would be used. "; " could be used, though, and then there wouldn't be any way to use it, not even by quoting a string or anything...
I'm not sure I mind, I'm just saying.

Plus, let's not forget that this : "Project Foo; Folder 2" is a perfectly correct folder name !! How would that work ?

admin wrote:And the scripts would look much more natural to everybody who ever saw a bit of C, Perl, JavaScript, Java, PHP and so on and on.

There only one big difference : here you're trying to cheat as pass your command separator or prefix, as the end-of-line/command or suffix that it is elsewhere.

For instance, in your little example anyone familiar with Perl, C, PHP, etc might, I guess, be look at it and go : hey, there's a problem here : you forgot a ";" at the end of your last line !!
Only, because it's not really such a delimiter, it's adding one that would create the error.

So what I'm saying is that I kinda like the :: and it works good as a prefix for the commands. Sure it doesn't look like other languages, but in the mean time it is not, it's the XY Scripting.
And (for now?) there's no functions with parameters, no conditions or loops, which by the way might also be a special case in that matter, if you're planning on going there......

Posted: **10 Feb 2008 16:43**

The error when adding to the last line will be easy to fix. I'll even fix it when keeping "::", because ::goto c:\:::::: ... should not raise an error.

jacky wrote:"Project Foo; Folder 2" is a perfectly correct folder name !! How would that work ?

Yes, here we would need another separator changer... but really, people who use ";" in the file and folder names will have problems all day long anyway. They are used to it.

Posted: **10 Feb 2008 18:15**

admin wrote:It does the job. But I do not really like it. It makes the scripts look klingonian in a way.

Klingonian? No...just XYish! We're different from the rest of the world here and we shouldn't give in to having to follow what is typical of other things, right?

So I'm thinking now that leaving it as is would also likely prevent other potential issues with parsing in the future.

Posted: **10 Feb 2008 18:33**

j_c_hallgren wrote:
admin wrote:It does the job. But I do not really like it. It makes the scripts look klingonian in a way.
Klingonian? No...just XYish! We're different from the rest of the world here and we shouldn't give in to having to follow what is typical of other things, right?
So I'm thinking now that leaving it as is would also likely prevent other potential issues with parsing in the future.

I don't know.

The only issue is "Project Foo; Folder 2" and that is a principal one that concerns any separator. If I now want to copy the current separator to clipboard I cannot do it because "copytext ::" does not work.

Now here is one possible solution: I could add a local script variable similar to <br>, namely <cs> (command separator), so "copytext <cs>" would copy "::" (or whatever the command separator is). Disadvantage: you cannot use <cs> unresolved.

The other solution would be to change the separator on the fly. Here's a possible syntax (might look strange at first, but I thought long about it and it's not that bad):

All the following scripts would be identical:

goto Desktop; selpos a
/# /goto Desktop# selpos a
/***/goto Desktop***selpos a
/::/goto Desktop::selpos a
/; /goto Desktop; selpos a

BTW, concerning the final ";":
goto Desktop; selpos a
goto Desktop; selpos a;
Also in CSS it is optional.

Posted: **10 Feb 2008 18:41**

why don't simply quote the text?
Someone read my posting above, please write your comments on my suggestions.

Posted: **10 Feb 2008 18:50**

fishgod wrote:why don't simply quote the text?
Someone read my posting above, please write your comments on my suggestions.

Whoops, I had overlooked your post. Thanks for reminding me! I come back later...

Posted: **10 Feb 2008 19:00**

admin wrote:All the following scripts would be identical:

goto Desktop; selpos a
/# /goto Desktop# selpos a
/***/goto Desktop***selpos a
/::/goto Desktop::selpos a
/; /goto Desktop; selpos a

BTW, concerning the final ";":
goto Desktop; selpos a
goto Desktop; selpos a;
Also in CSS it is optional.

I actually like your idea to make scripts more readable, I don't like the "::"s very much. And concerning the delimiter problems, why don't you just introduce a way to escape any special char within scripts in case they should be treated as non special (i.e. \; or /;).

@jc: To reinvent the wheel only makes sense, if the old one was lacking features you need and therefore you gain sth by reinventing it.

So my vote goes to use similar syntax as other languages, where possible. Maybe Don needs to decide which one it should be, 'cos it might save him the most time by not having to face syntax problems all the time, that have already been thought about by other developers and solved in some way.

Just my 2cts.

Posted: **10 Feb 2008 19:08**

fishgod wrote:I like it the way it is at the moment. True, you can use syntax like in other languages, but you allready have reinvented the wheel, so why don't use it continously.

Well, there are a number of reasons. Expected syntax is ony one of them. Another one is: internally I do it anyway as if it would by C-style. There is no "::"-command prefix in my code (functionally), but a "::"-command separator, which is closer to a suffix, resp. line-end, to me.

Let me pick out one point for now:

fishgod wrote: usage of brackets ( and ) which will include all parameters of a command. e.g.: ::filter(*.png;*.jpg) that would it also make it possible to use the same seperaters for commands and parameters without that nasty required space

"same separators"??? I do not see that.

I see the following advantages of brackets:
- It would allow for spaces in the commands, e.g. "copytext append (text)"
- It is easier to read.
- It is done like this in most languages.

Posted: **10 Feb 2008 19:18**

admin wrote:Let me pick out one point for now:
fishgod wrote: usage of brackets ( and ) which will include all parameters of a command. e.g.: ::filter(*.png;*.jpg) that would it also make it possible to use the same seperaters for commands and parameters without that nasty required space
"same separators"??? I do not see that.

for examle using a ; as command-seperator and as parameter-seperator would make it possible to use a syntax like this:

Code: Select all

filter(bla;bla;bla);filter(bla;bla)

XYplorer Beta Club

::

::

Re: ::

Re: ::

Re: ::

Re: ::

Re: ::

Re: ::

Re: ::