Tcl - Re: tcl8.5 new operator in expr

Author

Re: tcl8.5 new operator in expr

Adrian Davis

2006-01-18, 3:58 am

I do have to agree here. The "ne" and "eq" operators have made "if"
comparisons considerably less verbose - To my mind the only (widely
used) things missing now are "glob" and "regexp" string comparisons.
Some thing like:-

if {$myvar like *glob*}

....and...

if {$myvar match {^[Rr]egexp$}}

I have no idea how complex these would be to implement, but I can't
imagine any Tcl/Tk programmer who wouldn't like to see something along
these lines!!

Best Regards,
=Adrian=

Uwe Klein

2006-01-18, 7:58 am

Adrian Ho

2006-01-18, 7:05 pm

On 2006-01-18, suchenwi <richard.suchenwirth-bauersachs@siemens.com> wrote:
> I for one like "like" - the negated version might be "unlike" then,
> just as eq/ne, in/ni ...

IMO, "ni" is a *terrible* way to say "not in" -- it's far too easy to
accidentally type one when you mean the other, and it's not very distinct
visually. if/fi, case/esac et all make sense in shell programming because
[a] they're paired and [b] typo'ing them causes parse errors.

in/notin is a better choice.

Regards,
Adrian

Roy Terry

2006-01-18, 7:05 pm

"Adrian Davis" <adrian@satisoft.com> wrote in message
news:1137573896.947085.44500@g43g2000cwa.googlegroups.com...
> I do have to agree here. The "ne" and "eq" operators have made "if"
> comparisons considerably less verbose - To my mind the only (widely
> used) things missing now are "glob" and "regexp" string comparisons.
> Some thing like:-
>
> if {$myvar like *glob*}
>
> ...and...
>
> if {$myvar match {^[Rr]egexp$}}
Yes! nice idea.
>
> I have no idea how complex these would be to implement, but I can't
> imagine any Tcl/Tk programmer who wouldn't like to see something along
> these lines!!
>
> Best Regards,
> =Adrian=
>

Jeff Hobbs

2006-01-18, 7:05 pm

Donald Arseneau

2006-01-18, 7:06 pm

"Roy Terry" <royterry@earthlink.net> writes:

> "Adrian Davis" <adrian@satisoft.com> wrote in message
> news:1137573896.947085.44500@g43g2000cwa.googlegroups.com...

> Yes! nice idea.

I disagree with the keyword choices. Using "match" for regexp
is confusing because [string] uses "match" for glob.

--
Donald Arseneau asnd@triumf.ca

Roy Terry

2006-01-18, 7:06 pm

"Donald Arseneau" <asnd@triumf.ca> wrote in message
news:yfivewh1f15.fsf@triumf.ca...
> "Roy Terry" <royterry@earthlink.net> writes:
>
>
>
> I disagree with the keyword choices. Using "match" for regexp
> is confusing because [string] uses "match" for glob.
Yeah, good point. I do hope we stick with words or abbrevs.
instead of perl/awk style (~=, etc). Seems currently all
the expr non-match operators are alphabetic. So ....

Maybe

if {$s ma x*} ...

and

if {$s re ^x.*} ...

What's established or on its way
eq => equal
ne => not equal
in => in
ni => not in

IOW: two letters for non-negated operator,
leading 'n' negates,
single letter can stand for negated
operator and,
ops are 2 letters long.

Thus:

ma => str (glob) match (because we have [string match...]
nm => no str match

re => regexp match (because we have [regexp ...]
nr => no regexp match

This seem pretty clean so far if a bit
cryptic. OTOH, expressions are expected
to be a bit cryptic anyways :) I would vote
to go with these tidy little terms as the
point of the change would be compactness
and concision. Having all letter ops be 2
letters long could be helpful to verifying
memory and correctness for a lot of people.

Question is should the established
pattern stand, be revised, or simply
be ignored for these potential new operators.

Roy

>
>
> --
> Donald Arseneau asnd@triumf.ca

2006-01-18, 7:06 pm

In article <a2i1a3-iea.ln1@robert.houseofmax.de>,
Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>Adrian Davis wrote:
>
>This has been in tcl for a long time, it is called [switch]:
>
>switch -exact|-glob|-regexp
>
>switch -regexp -- $myvar \
> {^[Rr]egexp$} {
> } default {
> }
>
>It can be usefull to composite the argument like
>
>switch -- $test1,$subtest2 \
> VALUE_A,A_SUB_VALUE_1 {
> } ....
>
>
>
>which is IMHO very often the best solution to c-style if-spagetti
>and clean looking too.

I'm not picking on you specifically, Uwe..

While I use switch not infrequently in C/C++, I almost NEVER use it in Tcl,
simply because it just doesn't make a lot of sense to me - I always have to
look up the exact syntax, and even afterwards, I find it awkward to read.

I can EASILY read something like:
switch(x)
{
case 1:
...
...
break;
case 2:
...
...
break;
...
default:
...
}

TCL seems to go out of its way to make switch hard to read (IMHO).

Mattias

Bryan Oakley

2006-01-18, 7:06 pm

MH wrote:
> In article <a2i1a3-iea.ln1@robert.houseofmax.de>,
> Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>
>
>
> I'm not picking on you specifically, Uwe..
>
> While I use switch not infrequently in C/C++, I almost NEVER use it in Tcl,
> simply because it just doesn't make a lot of sense to me - I always have to
> look up the exact syntax, and even afterwards, I find it awkward to read.
>
> I can EASILY read something like:
> switch(x)
> {
> case 1:
> ...
> ...
> break;
> case 2:
> ...
> ...
> break;
> ...
> default:
> ...
> }
>
> TCL seems to go out of its way to make switch hard to read (IMHO).

That's a curious statement. How is that so much better than this?
Admittedly, with C you have to manually insert a break to prevent
fall-through, but claiming Tcl is "go[ing] out of its way to make switch
hard to read" is a bit far-fetched, isn't it?

switch $x {
1 {
...
...
}
2 {
...
...
}
default {
...
...
}
}

Donal K. Fellows

2006-01-18, 7:06 pm

Jeff Hobbs wrote:
> The adding of expr operators isn't that hard (but may lead to
> more bytecodes). I've wanted glob/re expr operators for a
> while as well. I had considered '=' based operators, like:

The adding of *specific* operators isn't hard (it's just a Simple Matter
of Programming, leaving aside what it takes to actually add any extra
bytecodes required) but the adding of a general mechanism for arbitrary
operators is rather more difficult. (It'd require a different kind of
expression parser to the simple LL(1) version we use now).

Donal.

Kevin Kenny

2006-01-18, 10:01 pm

Jeff Hobbs wrote:[color=darkred]
> Adrian Davis wrote:
>

I think that I'd like to see 'lt', 'le', 'gt', and 'ge' first - 'eq'
and 'ne' seem to be missing these counterparts.

I may have time at some point to write the TIP, but I have about four
other projects going at the moment, so now is not the time.

--
73 de ke9tv/2, Kevin

2006-01-18, 10:01 pm

In article <SsAzf.6073$_S7.3895@newssvr14.news.prodigy.com>,
Bryan Oakley <oakley@bardo.clearlight.com> wrote:
>MH wrote:

[cut]

>
>That's a curious statement. How is that so much better than this?
>Admittedly, with C you have to manually insert a break to prevent
>fall-through, but claiming Tcl is "go[ing] out of its way to make switch
>hard to read" is a bit far-fetched, isn't it?
>
> switch $x {
> 1 {
> ...
> ...
> }
> 2 {
> ...
> ...
> }
> default {
> ...
> ...
> }
> }

Ok, so maybe I went a little far.. For some reason, I've never been
comfortable with switch in Tcl..

I think it's the fact that the opening brace has to be on the same line as
the pattern.. Never liked that style (still don't - wish I could change that
about Tcl).

Mattias

Uwe Klein

2006-01-19, 4:08 am

Hi Mattias,

well, it took me some time to get fond of [switch]
and for me it has grown from using case/esac with
shell-scripts and using expect -re ..
switch in tcl is quite a bit more powerfull than
switch in C/C++. ( even without missing out on (no)break.)

usage varies: in my repository of nice_and_interesting
tcl scripts from the web it is about
10 if for 1 switch and tclstuff i wrote has about
5 if for 1 switch.
so its not about replacing if ;-)

if you have a look at http://wiki.tcl.tk/14928
using switch can look orderly and make adding and
changing cases easier.

my objection to using [if] was centered on repeated
stringcompares directly ripped from C/C++.

uwe

Uwe Klein

2006-01-19, 4:08 am

Bryan Oakley wrote:

> Admittedly, with C you have to manually insert a break to prevent
I would like to have control over (no)break in tcl as well.

switch -regexp -- $value \
<subselection of RE> {
prepare_special_value_for_general_case value
....
dontbreak
} <RE> {
process_value_for general_case $value
} ....

uwe

Donal K. Fellows

2006-01-19, 8:03 am

Uwe Klein wrote:
> my objection to using [if] was centered on repeated
> stringcompares directly ripped from C/C++.

That's what [switch] normally does too. However, in 8.5 we now compile
some ways of writing the [switch] command into a jump table, though it
is all made a bit more complicated by the fact that we're [switch]ing on
strings and not small integers. Many other forms of [switch] are also
compiled, but just into a slightly more efficient form of [if] chain.

Donal.

Bruce

2006-01-19, 8:03 am

Arjen Markus wrote:
> Well, Eiffel allows it, and it does not require a statement terminator.
> It simply determines if a statement is complete or not from a
> syntactical point of view ...
>
> Regards,
>
> Arjen
>

but without the open paren, the syntactical parser will always tell you
your command is complete unless it is an empty line ;)

Bruce

Uwe Klein

2006-01-19, 8:03 am

Donal K. Fellows wrote:
> Uwe Klein wrote:
>
>
>
> That's what [switch] normally does too. However, in 8.5 we now compile
> some ways of writing the [switch] command into a jump table, though it
> is all made a bit more complicated by the fact that we're [switch]ing on
> strings and not small integers. Many other forms of [switch] are also
> compiled, but just into a slightly more efficient form of [if] chain.
>
> Donal.

Didn't know that.

The required action is
compare "single value" to list of "match_values"
execute the script for first match.

written code should show this "one of many" selection.

if .. else if ... else if
needs carefull reading if it is really the same thing every if.
uf

uwe

Bruce

2006-01-19, 8:03 am

Jeff Hobbs wrote:
> Adrian Davis wrote:
>
> The adding of expr operators isn't that hard (but may lead to
> more bytecodes). I've wanted glob/re expr operators for a
> while as well. I had considered '=' based operators, like:
>
> $a =* $b # glob
> $a =~ $b # re
>
> The =~ is obviously from Perl, but they have more elaborate
> results and syntax related to it that I wanted to avoid. For
> negation, you could have !* and !~.
>

oh god Jeff, please please please don't do this!

> As to the words ... I don't like the choices. I might expect
> SQL syntax for like, and using glob would be only 4 chars too
> (but sounds clumsy). The 'match' doesn't immediately invoke
> re to me - why not use 're'? But what to negate with?
>
glob is good (I think)
for re you could use negreg ;)

but really why not use glob, !glob and re, !re ?

I agree that the right word/abbrev needs to be found, but again
please please no crazy messy made up operators.

Bruce

Andreas Leitgeb

2006-01-19, 8:03 am

Roy Terry <royterry@earthlink.net> wrote:
> if {$s ma x*} ...
> if {$s re ^x.*} ...

By the way, even when "ma"/"re" or any other such
operators are added to expr, it most likely won't
automatically legalize barewords in expr.

if {$s ma "x*"} ...
if {$s re {^x.*y$}} ...
(of course either type of quoting can be used for any operator)

I wonder how "implementable" are operators whose
name is combined of an exclam and a word for
the negated operators (as mentioned in some
other subthread)

I think going on with two-letter ops <x><y> and
having their negation as n<x> will much too soon
leave us out of good mnemonics.

Roy Terry

2006-01-19, 7:07 pm

"Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> wrote in message
news:slrndsv29o.56k.avl@gamma.logic.tuwien.ac.at...
> Roy Terry <royterry@earthlink.net> wrote:
>
> By the way, even when "ma"/"re" or any other such
> operators are added to expr, it most likely won't
> automatically legalize barewords in expr.
Yes. x* would be better typed "x*"
>
> if {$s ma "x*"} ...
> if {$s re {^x.*y$}} ...
> (of course either type of quoting can be used for any operator)
>
> I wonder how "implementable" are operators whose
> name is combined of an exclam and a word for
> the negated operators (as mentioned in some
> other subthread)
>
> I think going on with two-letter ops <x><y> and
> having their negation as n<x> will much too soon
> leave us out of good mnemonics.

How many other operators did you have in mind?
Kevin Kenny has already mentioned his desire for
string comparisons gt lt le ge which manage to
be 2 chars also.

So perhaps more creativity would be demanded yes.
OTOH, consistent length and negation rules
are really helpful. Or put another way, inconsitency
in forming expressions can be maddening.
So if Tcl broke the current
pattern of xy / nx, then the existing eq/ne and in/ni
should gain aliases in whatever the new format is
with the 2-letter versions left as legacy.

Roy
>

Andreas Leitgeb

2006-01-19, 7:07 pm

Roy Terry <royterry@earthlink.net> wrote:
> "Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> wrote in message
[color=darkred]
>
> How many other operators did you have in mind?
> Kevin Kenny has already mentioned his desire for
> string comparisons gt lt le ge which manage to
> be 2 chars also.

Who knows? At some point in future there might be
a consensus that a new operator for "newer than"
or "nicer than" or "naughtier than" shall be added,
and then there is the problem that the leading "n"
already has some meta-meaning :-)

Another comparable story is binary scan, where
mnemonically good characters were available for
all types of conversion - back then. But the
recently added couple of conversions (though
necessary they were) really lack mnemotechnically
good letters.
Had [binary scan] been designed to allow letter groups
to describe a single conversion, We'd be much more
flexible now and the new conversions had a chance
to be actually memorizable.
Lets not repeat this design mistake.

By sticking to a n<x> style for negation, we limit
ourselves to 26 operators, and practically far less,
because not all letters "lend" themselves to a
particular useful operator-name.
(that le/gt and lt/ge are pairwise negations lifts
the limit from 26 to 28. Whether other operators
also have a cononical non-n<x> negation is pure luck)
That's not meant that we shall strictly avoid
n<x>-style negations, especially not those that are
already there, but that we don't stick too hard to it.
better consider a "!op" scheme, which doesn't consume
the valuable space too greedily.

> So perhaps more creativity would be demanded yes.
> OTOH, consistent length and negation rules
> are really helpful.

Helpful, yes, but only as long as it doesn't hinder future useful
operators just for lack of good available two-letter names.

2006-01-19, 7:07 pm

In article <le34a3-fno.ln1@robert.houseofmax.de>,
Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>Hi Mattias,
>
>well, it took me some time to get fond of [switch]
>and for me it has grown from using case/esac with
>shell-scripts and using expect -re ..
>switch in tcl is quite a bit more powerfull than
>switch in C/C++. ( even without missing out on (no)break.)
>
>usage varies: in my repository of nice_and_interesting
>tcl scripts from the web it is about
>10 if for 1 switch and tclstuff i wrote has about
> 5 if for 1 switch.
>so its not about replacing if ;-)
>
>if you have a look at http://wiki.tcl.tk/14928
>using switch can look orderly and make adding and
>changing cases easier.
>
>my objection to using [if] was centered on repeated
>stringcompares directly ripped from C/C++.

Hmm. I'm probably guilty of that at some point.. Mostly in little utilities
that that are run 5 times a year, but so much faster than typing it in :-)

Next time I feel like "learning", I'll spend some time playing with switch
to see if I can get a better handle on it..

Mattias

Donal K. Fellows

2006-01-20, 7:59 am

Andreas Leitgeb wrote:
> Roy Terry <royterry@earthlink.net> wrote:
>
> Helpful, yes, but only as long as it doesn't hinder future useful
> operators just for lack of good available two-letter names.

I think "ni" was chosen in part because of it's joke potential. There's
absolutely no hard-and-fast rule about operator lengths, but they
probably still ought to be short.

Donal.

Jeff Hobbs

2006-01-20, 7:10 pm

Donal K. Fellows wrote:
> Andreas Leitgeb wrote:
>
> I think "ni" was chosen in part because of it's joke potential. There's
> absolutely no hard-and-fast rule about operator lengths, but they
> probably still ought to be short.

ni!

Andreas Leitgeb

2006-01-22, 3:57 am

Jeff Hobbs <jeffh@activestate.com> wrote:
> Donal K. Fellows wrote:
> ni!

O Tempora O Mores!
Who says "ni" to dear colleagues these times?
(sorry, don't know the original english wording...)

By the way, would the knights also say "!in" ?

Neil Madden

2006-01-24, 7:05 pm

Adrian Davis wrote:
> I do have to agree here. The "ne" and "eq" operators have made "if"
> comparisons considerably less verbose - To my mind the only (widely
> used) things missing now are "glob" and "regexp" string comparisons.
> Some thing like:-
>
> if {$myvar like *glob*}
>
> ...and...
>
> if {$myvar match {^[Rr]egexp$}}
>
> I have no idea how complex these would be to implement, but I can't
> imagine any Tcl/Tk programmer who wouldn't like to see something along
> these lines!!

They look quite cute, sure. But what about switches and sub-match vars
etc? Will we end up with:

if {$myvar match -nocase -line -expanded -start $idx -- $pattern -> sub1
sub2 sub3} { ... }

?

OK, that's over the top, but are these infix operators going to support
just the bare minimum basic functionality or are they going to become
complete duplicates of the commands?

Should every Tcl command have an infix equivalent in [expr]? Many now
do. Would it be nicer to adopt an OO-like approach to this? For
instance, $a eq $b can be accomplished simply via:

proc string: {str method args} {
uplevel 1 [linsert $args 0 ::string $method $str]
}
set s1 [list string: "my string"]
if {[$s1 equal $s2]} { ... }
# Careful below -- pattern is on left of operator!
if {[$s1 match $s2]} { ... }

Likewise, for regexp:

proc regexp: {pattern method args} {
array set map { match regexp replace regsub }
uplevel 1 [linsert $args 0 $map($method) $pattern]
}
set re [list regexp: {([^:]+):(?://)?([^:/]+)(:\d+)?(/.*)}]
if {[$re match $str -> proto host port path]} {
...
}

These examples assume auto-expansion of leading word when resolving
commands [1]. This is a nice extensible mechanism that works simply with
Tcl's existing command infrastructure. I'm not overly against adding new
operators to [expr] but it seems like duplication of functionality just
to get a prettier infix syntax.

For reference, you can get around the lack of auto-expand now by
avoiding variables:

proc define {name = args} {
uplevel 1 [linsert $args 0 interp alias {} $name {}]
}
define myre = regexp: $somepattern
if {[myre match $str -> var1 ...]} { ... }

[1] http://www.cs.man.ac.uk/~fellowsd/tcl/future.html

-- Neil

Andreas Leitgeb

2006-01-24, 7:05 pm

Neil Madden <nem@cs.nott.ac.uk> wrote:
> They look quite cute, sure. But what about switches and sub-match vars
> etc?

As soon as you need options conciseness is gone,
anyway, so you can just as well go the old way:
if {[somecmd -opt1 -opt2 $val1 $val2]} ...

Sponsored Links