On Tue, Aug 09, 2005 at 11:16:05AM +0000, Mikhael Goikhman wrote:
> 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.
And I agree with you. This was just the simplest way to get what I
needed at that time. But we can of course make it better now. ;-)
At least if it will not take next 10 months... ;-)
> > > 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.
I don't like "eq","ne" names. It's hard to tell them apart from compared
strings. I don't care if it's "perl's" or anything else, I just want to
have clear and easy to read syntax. Standard mathematical operators are
for me more natural and so easier to read.
> > 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).
I don't see the usefulness of them, but that's not important. I just
don't care if they'll be there or not.
> 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 agree there should be only one set of operators, so numbers can be
compared just the same as strings, but I'm not sure if we really need
so extended functionality in core fvwm...
> > 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
I didn't knew it, but that's not a solution for me anyway, because I
need only simple comparisions for choosing right config options. I don't
want to run FvwmPerl just for that. It's almost the same as PipeRead'ing
shell scripts doing comparision.
> > > 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".
I can't disagree with you, but I also want to have this simple
comparision functionality ASAP (so preferably before 2.6).
> > 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.
As I said before runing FvwmPerl for couple of simple comparisions is
almost the same as using PipeRead and shell scripts.
> 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.
The problem is: this will make fvwm consume much more memory just
because of simple comparision test. I like fvwm for it's lightweight
and flexibility and don't want to sacarifice any piece of them without
a strong reason.
--
Rafal Bisingier
pgpTFS5QUNpqb.pgp
Description: PGP signature
