On 09 Aug 2005 08:47:10 +0200, Rafal Bisingier wrote:
>
> On Mon, Aug 08, 2005 at 10:59:16AM +0000, Mikhael Goikhman wrote:
> > On 08 Aug 2005 11:27:16 +0200, Rafal Bisingier wrote:
> > >
> > > This patch ads new test-condition to the Test function named Compare.
> > > With it one can do simple comparisions of numbers or strigs without
> > > using PipeRead and shell subprocesses.
> >
> > I don't really like this verbose syntax:
> >
> > Test (Compare "string 1" strcmp "string 2") DoSomething
> >
> > The following syntax is better:
> >
> > Compare ("string 1" eq "string 2") DoSomething
>
> Well, this syntax is strightly derived from existing syntax and this is
> the only reason of it's form.
Sure. My point is we may go with a better/simplier syntax instead.
> > Perl's operators (eq, ne, lt, gt, le, ge and cmp) are string
> > equivalents of numerical operators (==, !=, <, >, >=, <=, <>).
> > Not sure there is a need for 2 sets of operators rather than
> > just string operations, but ok.
>
> I need it only for integer comparision, so didn't take much care about
> string operations. I've added strcmp only for completness and because it
> was easy to do ;-)
> I personaly don't like perl's string operators (eq, ne, etc.)
Is it because of "perl" or because of "eq", "ne" names? These names are
also tcl's expr operators, and you may find them in the test(1) man page.
> and I don't see any reason to have le, lt, ge and gt operators other
> than completness.
These may be useful for those who use test(1) and sort(1).
But again, I don't see a good reason to have different operators for
"12" == "12" and "string" == "string", unless you also add mathematical
operators. Numbers are normal strings in most of the scripting languages.
> I think much more useful would be case insensitive comparision
I agree, but I don't think C functions (C does not have string operators)
are a good model for a new scripting language. And, well, lowercased
(or any other) comparisions are already available in FVWM (try it):
Eval cmd("GotoDesk 2") if "something" eq lc("SomeThing")
After:
AddToFunc Eval I SendToModule FvwmPerl eval $*
Module FvwmPerl
> > Having separate command for this is not really a problem, just like we
> > have separate command for TestRc. And if already do this, then
> > simply:
> >
> > If ("string 1" eq "string 2") DoSomething
>
> When I made this patch I wanted it to make as little changes to fvwm
> source as possible and make the patch as simple as I only can in the
> hope that this can help in merging it into fvwm...
>
> > But then we had another similar "If" patch by Scott, IIRC.
>
> Yes, there is a patch from Scott adding a complete if-elseif-else-endif
> syntax, but it's far more bigger, much more complicated and adds
> completely new syntax. From the other side Scott's patch is more
> functional and probably simpler to use in complicated configuration.
>
> I don't care which patch can be included into fvwm now (it could be even
> both of them)
I think the ideas in these two patches are ok. There is a place for both.
For example, if we have a "Compare" command that supports different
operators, it may be used together with "If".
Still, I would prefer to design one clean syntax rather than to have many
random additions that are "easy to implement".
> aviable in fvwm config file without the need of external commands run by
> PipeRead.
I guess you don't consider FvwmPerl as an option for string operations or
mathematics.
Maybe we should have "Eval" (or PerlEval) command built-in?.. That will
fetch FvwmPerl on the first use, so there is no overhead for other users.
I thought about such generic autoload-module-on-demand idea, but the
current module interface is not flexible enough to implement it cleanly.
A quick hack would be to add definition of Eval in ConfigFvwmDefaults.
Regards,
Mikhael.
