lazy evaluation
Johannes Schacht
[f1] && [f2] && [f3] ...
where fx are boolean function which run quite a while.
When evaluating this expression with tcl in, say, an
if-statement, all functions are called, bevor the expression
itself is evaluated.
I would like lazy evaluation, i.e. stop evaluation as soon
as possible. The only way I can think of is to write my
own expression evaluator. Hopefully, there's a better idea.
Johannes
D. Richard Hipp
>
> I have an expression like:
>
> [f1] && [f2] && [f3] ...
>
> where fx are boolean function which run quite a while.
>
> When evaluating this expression with tcl in, say, an
> if-statement, all functions are called, bevor the expression
> itself is evaluated.
Not so, if you put the expression inside {...}. Consider
this test program:
proc hi {x} {
puts "hi $x"
return $x
}
if {[hi 1] && [hi 0] && [hi 2]} {
puts yes
}
Running the above (with tclsh7.6 and tclsh8.0) yields
hi 1
hi 0
As you have requested.
--
D. Richard Hipp -- d...@acm.org -- http://www.hwaci.com/drh/
Bryan Oakley
braces. Without them, tcl is forced to evaluate the entire expression
before passing it to the if statement. By enclosing them in curly braces
you ensure that the evaluation is done by the if statement rather than
the command parser.
Johannes Schacht wrote:
>
> I have an expression like:
>
> [f1] && [f2] && [f3] ...
>
> where fx are boolean function which run quite a while.
>
> When evaluating this expression with tcl in, say, an
> if-statement, all functions are called, bevor the expression
> itself is evaluated.
>
> I would like lazy evaluation, i.e. stop evaluation as soon
> as possible. The only way I can think of is to write my
> own expression evaluator. Hopefully, there's a better idea.
>
> Johannes
--
Bryan Oakley
ChannelPoint, Inc.
jeff_...@my-dejanews.com
Johannes...@t-online.de (Johannes Schacht) wrote:
> [f1] && [f2] && [f3] ...
> where fx are boolean function which run quite a while.
> When evaluating this expression with tcl in, say, an
> if-statement, all functions are called, bevor the expression
> itself is evaluated.
Tcl has lazy (or short-circuit) evaluation. It will only go
as far as it needs. Illustrated below:
(vu) 5 % set i 0
0
(vu) 6 % if {[incr i] || [incr i] || [incr i]} { puts $i }
1
(vu) 7 % set i -2
-2
(vu) 8 % if {[incr i] && [incr i] && [incr i]} { puts $i }
(vu) 9 % set i
0
In the OR case, it stop at the first incr because that is OK.
In the AND case, it stop at the second, where 0 is received and
then all must fail. You must be giving a case where all the
functions must be evaluating to 1 (since it is AND, it must go
through to the last if each preceding is 1).
--
jeff.hobbs at acm.org
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Cameron Laird
Bryan Oakley <oak...@channelpoint.com> wrote:
>I suspect the reason is that you don't have your expression in curly
>braces. Without them, tcl is forced to evaluate the entire expression
>before passing it to the if statement. By enclosing them in curly braces
>you ensure that the evaluation is done by the if statement rather than
>the command parser.
.
.
I'm trying to figure out a different way to say this.
People coming from other languages consistently come
up with inspirations about neat interpretations like
lazy evaluation, ... People who *get* the point of
the utterly simple Tcl parser understand how obvious
it is that you can't have lazy evaluation (or func-
tion evaluation, ...) outside curlies. How can we
communicate that Tcl is really, *really* simple?
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX
Alexandre Ferrieux
> How can we
> communicate that Tcl is really, *really* simple?
Our persistent failure to do so now and then bursts into our faces when
some Tcl stranger passes by and says:
"Hey, Tcl syntax is sooo complex... I went back to Perl."
Despite the sad implication on our (collective) teaching abilities,
quotes like this one always amuse me <shrug>.
Okay Cameron, will you be the one, to write that one-page killer Tcl
introduction ?
-Alex
Cameron Laird
I've done it seven times now--and each time it over-
ran that one page. I'm not giving up, though ...
Bryan Oakley
> I'm trying to figure out a different way to say this.
> People coming from other languages consistently come
> up with inspirations about neat interpretations like
> lazy evaluation, ... People who *get* the point of
> the utterly simple Tcl parser understand how obvious
> it is that you can't have lazy evaluation (or func-
> communicate that Tcl is really, *really* simple?
That's a tough question. From the man page I've always dreamed of
writing:
The way tcl works: a line of code is parsed once. Only
once. Only ever once. Once, once, once. No exceptions at
all. None. Zero. Zip. Nada. After substitutions are performed
the first word becomes the command and all the other words
become the arguments. Always. Always, always. Always.
Always.
To avoid substitutions, place a \ before special characters,
or place a whole string of special characters inside curly
braces. Things in curly braces will never, ever, ever, ever
be parsed before being passed to the command. Never, ever,
ever. No exceptions.
The only tricky part (the _only_ tricky part) is knowing
that some commands will do their own parsing of arguments.
But only *after* the line of code is parsed in the usual
manner. Examples of these commands are "if", "expr",
"while" and a few others.
Unless you know for certain what you are doing, and know
for a fact that you want something to potentially be
evaluated twice, always, always, always provide such
arguments in curly braces. Always. Unless you know what
precisely what you are doing.
When you truly understand the above, you are a tcl expert.
from "Bryan's Practical Guide to Tcl Programming", vol 0, page 0.
:-)
I've always found tcl to be somewhat zen-like. I think people tend to
think too hard when writing tcl. There's no magic. No special cases.
Everything is just so incredibly consistent. You shouldn't ever have to
think "How will tcl treat _this_?", since the answer is the same for
every single line of code.
Cameron Laird
Bryan Oakley <oak...@channelpoint.com> wrote:
.
.
.
>That's a tough question. From the man page I've always dreamed of
>writing:
>
> The way tcl works: a line of code is parsed once. Only
> once. Only ever once. Once, once, once. No exceptions at
> all. None. Zero. Zip. Nada. After substitutions are performed
> the first word becomes the command and all the other words
> become the arguments. Always. Always, always. Always.
>
> Always.
.
.
>I've always found tcl to be somewhat zen-like. I think people tend to
>think too hard when writing tcl. There's no magic. No special cases.
>Everything is just so incredibly consistent. You shouldn't ever have to
>think "How will tcl treat _this_?", since the answer is the same for
>every single line of code.
.
.
'Looks right to me. I think the single thing I most
often say when debugging with others is, "You're
working too hard."
Ilya Zakharevich
<cla...@Starbase.NeoSoft.COM>],
who wrote in article <6vsu78$7g0$1...@Starbase.NeoSoft.COM>:
> I'm trying to figure out a different way to say this.
> People coming from other languages consistently come
> up with inspirations about neat interpretations like
> lazy evaluation, ... People who *get* the point of
> the utterly simple Tcl parser understand how obvious
> it is that you can't have lazy evaluation (or func-
> tion evaluation, ...) outside curlies. How can we
> communicate that Tcl is really, *really* simple?
Did not it ever occured to you that the reason why you cannot do it is
*really* simple?
You cannot communicate simplicity of Tcl because there is no such guy.
The fact that the parser of Tcl is very primitive has nothing to do
with simplicity of the language. Human brain is not created to follow
a *very* simple finite automaton, which Tcl parser is. One *can* do
it, but it requires a lot of training and flaggelation.
Perl's parser, on the other hand, is *very* hairy. This also creates
zillions of problems, but on the higher level of complexity of the
code. It is the medium-to-experienced programmers which get bitten,
not beginners-to-medium as it is with Tcl.
No language can completely avoid transfering responsibility for
language deficiencies to the programmer. Tcl is not better in this
category than most others. It *is not* simple.
Ilya
Bryan Oakley
>
> Did not it ever occured to you that the reason why you cannot do it is
> *really* simple?
>
> You cannot communicate simplicity of Tcl because there is no such guy.
[snip]
You seem convinced that tcl is not a simple language. Can you please
provide some examples of what makes tcl complex? I'm sorry, but I just
fail to see it. Perhaps it is because tcl is so simple and straight
forward, that experienced programmers accustomed to complexity have
trouble dealing with it.
> The fact that the parser of Tcl is very primitive has nothing to do
> with simplicity of the language. Human brain is not created to follow
> a *very* simple finite automaton, which Tcl parser is. One *can* do
> it, but it requires a lot of training and flaggelation.
No offense, but that is just absolutely laughable. You are saying our
human brains can't handle simple, and that we are only able to
comprehend the complex? You have to be the first person I've ever heard
to postulate *that*.
This just *has* to be flame bait. (and here I am, taking that bait!)
>
> Perl's parser, on the other hand, is *very* hairy. This also creates
> zillions of problems, but on the higher level of complexity of the
> code. It is the medium-to-experienced programmers which get bitten,
> not beginners-to-medium as it is with Tcl.
So, you're saying a beginner will not get bitten by perl? I'd like to
see that. I'd like to see *anyone* who hasn't gotten bitten by perl.
Anyone that's actually used it, that is.
Now, I'm not flaming perl by any stretch. It's the second best language
on the planet, after all :-). I just fail to see how anyone can claim
perl, by nature of its complexity, is simpler for beginners than the
syntax of tcl.
Cameron Laird
Bryan Oakley <oak...@channelpoint.com> wrote:
>Ilya Zakharevich wrote:
>>
>> Did not it ever occured to you that the reason why you cannot do it is
>> *really* simple?
>>
>> You cannot communicate simplicity of Tcl because there is no such guy.
>
>[snip]
>
>You seem convinced that tcl is not a simple language. Can you please
.
.
>So, you're saying a beginner will not get bitten by perl? I'd like to
>see that. I'd like to see *anyone* who hasn't gotten bitten by perl.
>Anyone that's actually used it, that is.
>
>Now, I'm not flaming perl by any stretch. It's the second best language
>on the planet, after all :-). I just fail to see how anyone can claim
>perl, by nature of its complexity, is simpler for beginners than the
>syntax of tcl.
.
.
Maybe I can explain, Bryan. The argument is
that Perl maps to the problem domain better.
The problem domain--dealing with the usual
run of textual filtering, ...--is messy and
complex, and it's better that Perl match
that than that newbies be left on their own.
Beginners often learn by rote, and they're
utterly indifferent to whether a '&' is
discretionary in a particularly subtle con-
text, 'cause they're just cutting and pasting
anyway. Perl is easy for them to learn, in
the sense that there are few characters to
cut and paste.
You two are talking about different things.
The syntax of Tcl is very simple. However,
the semantics of [text], say, are complex.
Parsing Tcl is a feat reserved to those with
supernatural powers. However, whatever
you're doing, there's already one in CPAN
(roughly).
Stefaan A Eeckels
il...@math.ohio-state.edu (Ilya Zakharevich) writes:
> Did not it ever occured to you that the reason why you cannot do it is
> *really* simple?
>
> You cannot communicate simplicity of Tcl because there is no such guy.
almost anything, you need to *know* it. Some people have a natural
ability to appreciate Tcl's simplicity, and barf at Perl's
syntactical subtleties. Other people wax lyrically over Perl, and
dislike Tcl. Computer languages are like music - they need to be
in tune with your brain waves :-)
> The fact that the parser of Tcl is very primitive has nothing to do
> with simplicity of the language. Human brain is not created to follow
> a *very* simple finite automaton, which Tcl parser is. One *can* do
> it, but it requires a lot of training and flaggelation.
I've got to agree with you: humans like complexity and ambiguity,
because these conveniently hide their ignorance and stupidity.
> Perl's parser, on the other hand, is *very* hairy. This also creates
> zillions of problems, but on the higher level of complexity of the
> code. It is the medium-to-experienced programmers which get bitten,
> not beginners-to-medium as it is with Tcl.
newbie.
> No language can completely avoid transfering responsibility for
> language deficiencies to the programmer. Tcl is not better in this
> category than most others. It *is not* simple.
Take care,
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exupéry
Doug Hughes
> I've always found tcl to be somewhat zen-like. I think people tend to
> think too hard when writing tcl. There's no magic. No special cases.
> Everything is just so incredibly consistent. You shouldn't ever have to
> think "How will tcl treat _this_?", since the answer is the same for
> every single line of code.
Now THAT'S a quote that belongs in a book! Dibs? ;)
--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
do...@eng.auburn.edu
Ilya Zakharevich
<oak...@channelpoint.com>],
who wrote in article <3622623A...@channelpoint.com>:
> > The fact that the parser of Tcl is very primitive has nothing to do
> > with simplicity of the language. Human brain is not created to follow
> > a *very* simple finite automaton, which Tcl parser is. One *can* do
> > it, but it requires a lot of training and flaggelation.
>
> human brains can't handle simple, and that we are only able to
> comprehend the complex? You have to be the first person I've ever heard
> to postulate *that*.
>
> This just *has* to be flame bait. (and here I am, taking that bait!)
Hmm, is it that you *really* cannot see the point? Can you multiply
two (decimal) numbers on a scratch of paper? Is the algorithm simple?
Now do
1234567890123456789012 * 1234567890123456789012
This is exactly the same as with Tcl. The rules of syntax are simple
for a computer, but not for a human brain.
The other side of the medal is that the simplicity of syntax leads to
complexity of "abstract expressions" when mapped to this syntax, which
leads to hard-to-parse-by-human programs.
> > Perl's parser, on the other hand, is *very* hairy. This also creates
> > zillions of problems, but on the higher level of complexity of the
> > code. It is the medium-to-experienced programmers which get bitten,
> > not beginners-to-medium as it is with Tcl.
>
> So, you're saying a beginner will not get bitten by perl? I'd like to
> see that. I'd like to see *anyone* who hasn't gotten bitten by perl.
> Anyone that's actually used it, that is.
Beginners bitten by Perl *syntax*? Do not think so (I monitor clpm,
and do not remember seeing this *often*). Complexity of the Perl
syntax maps well into abilities of human brain (at least for beginner
to medium range, later you got bitten by ambiguities).
Beginners are bitten by the semantic mostly.
Ilya
Ilya Zakharevich
<cla...@Starbase.NeoSoft.COM>],
who wrote in article <6vts05$97o$1...@Starbase.NeoSoft.COM>:
> Maybe I can explain, Bryan. The argument is
> that Perl maps to the problem domain better.
> The problem domain--dealing with the usual
> run of textual filtering, ...--is messy and
> complex, and it's better that Perl match
> that than that newbies be left on their own.
In fact I was not discussing this. My point was about *syntax*, not
semantic. "The simplicity of TCL for the computer leads to complexity
when dealing with a human."
Ilya
Ilya Zakharevich
<Stefaan...@ecc.lu>],
who wrote in article <6vu3as$9j5$1...@justus.ecc.lu>:
> > Did not it ever occured to you that the reason why you cannot do it is
> > *really* simple?
> >
> > You cannot communicate simplicity of Tcl because there is no such guy.
> Unfortunately, in order to see (and appreciate) the simplicity of
> almost anything, you need to *know* it.
This reminds me juice boxes which have a label with "Easy opening
instructions". ;-) The instructions are really "easy", but the actual
act of opening is not.
The problem with your approach is that when you *really know* the
simplicity of Tcl (which takes *a lot* of time, as you probably know),
there is a significant chance you hate it already.
> > The fact that the parser of Tcl is very primitive has nothing to do
> > with simplicity of the language. Human brain is not created to follow
> > a *very* simple finite automaton, which Tcl parser is. One *can* do
> > it, but it requires a lot of training and flaggelation.
> I wish you were joking, but after the last stock exchange debacle,
> I've got to agree with you: humans like complexity and ambiguity,
> because these conveniently hide their ignorance and stupidity.
Thank you for an independent estimate of my intellect. ;-)
Ilya
Bryan Oakley
> The problem with your approach is that when you *really know* the
> simplicity of Tcl (which takes *a lot* of time, as you probably know),
> there is a significant chance you hate it already.
Obviously, YMMV. I recall pretty much "knowing" the simplicity of tcl
after one afternoon of using it. And I've loved it ever since. I can't
ever recall there being a time in my own personal life where the tcl
syntax or sematics was the least bit difficult to understand, use or
master. But I guess that's just me.
Rolf Ade
>Cameron Laird wrote:
>> [...] How can we
>> communicate that Tcl is really, *really* simple?
>
>writing:
>
> The way tcl works: a line of code is parsed once. Only
> once. Only ever once. Once, once, once. No exceptions at
> all. None. Zero. Zip. Nada. After substitutions are performed
> the first word becomes the command and all the other words
> become the arguments. Always. Always, always. Always.
>
> Always.
I've left this alone, because I love this emphasis. But I'm afraid it
isn't _that_ simple (from the viewpoint of a beginner).
Let us read your text carefully. Your first sentence is: "The way tcl
works: a line of code is parsed once." Sounds really simple. But what
does this mean in tcl: "parsed"? Beside the fact, that this is defined
in detail there is an intuitive rule: tcl breaks the line into words
and the words are separated by white space. And if your in need to
express a word with white spaces in it, you have to protect your word
with double-quotes: "parsed as a single word". Already simple up to
now. But if you try
set a("b c") d
your shoot yourself into feed, as you know. Surely, [set "a(b c)" d]
works. And it is clearly defined, that double-quotes protect against
splitting into words only if the first quote are the left most
character of the word_with_spaces. But I guess this rule isn't obvious
to everyone. [Latest chance to learn this: use user input as array
keys without checking against white space in the user input.]
OK, let's skip to your next sentence: "After substitutions are
performed the first word becomes the command and all the other words
become the arguments." Again, sounds really simple. But what mean
"substitution" in tcl? Let's pick up a simple example:
set var key
set a(key) somewhat
puts $a($key)
With tcl experience this works obviously. But take a close look at the
substitution steps. It is obviously too, that the substitution isn't
applied in a very simple left to right matter: Since there is no
$a(\$key), the substitution process left the first $ beside,
substitutes the second $, than goes back and substitutes the first
$. You may say this is a quite stupid example, but then you forget,
that you have a feeling - due to experience - about this back and for
substitution. From what, do you think, comes the questions "How to get
$$var work?" every month?
The Tcl man page counts 11 rules about the syntax and semantics of
tcl, most of them with more then 10 lines. And they aren't loquacious
in any way.
I doesn't stand up to say tcl is complicated: tcl _is_ simple. But
it's difficult to measure simplicity, especially because you have to
measure simplicity correlated to specific tasks. I feel tcl is a good
choice because of its well-balance of relative simplicity _and_ power
for a wide range of tasks.
rolf
bo...@aol.com
One difference between tcl and other languages is the way arguments are
grouped. In most other languages there is only one way to group each
argument, but in tcl you there are several ways. In other languages the
compiler/interpreter will tell you if you did it wrong. This leaves the
option of creating code in tcl that works in some cases and not in others.
This is, of course, the other side of the sword that gives tcl it's
extensibility.
Once a programmer has learned to properly group the core commands, it becomes
transparent to him/her and the code just flows, properly grouped, without
even thinking about it. But where is this learned? Not from the man pages.
The man pages mostly just describe the arguments and their functions. If a
type of grouping is suggested, it is in an example. To get the whole story,
you have to go to books and faqs, and this newsgroup.
The other thing that can be confusing at first is the data types. Strings and
lists are distinct data types that can cause trouble when mixed.
A good syntax checker could warn of both of these problems and then be
abandoned after a programmer has learned the ropes. I don't know if the cd
has one on it, but it should.
Christopher Nelson
> The other thing that can be confusing at first is the data types. Strings and
> lists are distinct data types that can cause trouble when mixed.
"distinct" yes, but indistinguishable. My best wishes and a hearty
"Huzzah!" to anyone who can complete this proc:
proc typeOf { x } {
if { <some mysterious operation on x> } {
return STRING
} elseif { <some mysterious operation on x> } {
return LIST
}
... int, etc.
}
so that the following two calls return appropriate values:
typeOf [list a b c]
typeOf "a b c"
Chris
P.S. An binary extension is cheating (but I'll take it).
--
Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!
James Ingham
> bo...@aol.com wrote:
> > The other thing that can be confusing at first is the data types. Strings and
> > lists are distinct data types that can cause trouble when mixed.
>
> "distinct" yes, but indistinguishable. My best wishes and a hearty
> "Huzzah!" to anyone who can complete this proc:
>
Lists are a subset of strings. EVERYTHING in Tcl is a string, so
typeOf would always return string... And of course an integer is a
list of length 1 as well...
You might do something like:
proc typeOf { x } {
set result STRING
if {![catch {llength $x}] } {
lappend result LIST
}
... int, etc.
}
At the C level you could return what the internal representation
currently is, but that is not conclusive, since if I do:
set x [list 1.0]
then the internal rep of x will be a list, but of course 1.0 is also
an float as well. So if I next did
set y [expr $x + 5]
Then the internal representation of x would be a float.
Except for arrays (which are always just arrays), all other storage
classes in Tcl are multifaceted.
Jim.
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jin...@cygnus.com
Cygnus Solutions Inc.
--
Laurent Demailly
more direct core support (c side) for that as I guess everybody
ends re-inventing his/her own version (more or less buggy) in plain
tcl), It took me quite a while to find (what I think is)
a good/complete/fast/accurate/... isInteger for instance (using ~)... :
extract from tclplugin2.0/plugin2.0/library/utils.tcl :
proc isBoolean {value} {
expr {![catch {expr {([Munge $value])?1:0}}]}
}
proc getBoolean {value {errorValue 1}} {
if {[catch {expr {([Munge $value])?1:0}} res]} {
return $errorValue
} else {
return $res
}
}
proc isInteger {value} {
expr {![catch {expr {~[Munge $value]}}]}
}
proc getInteger {value {errorValue 0}} {
if {[catch {expr {~[Munge $value]}} res]} {
return $errorValue
} else {
return [expr {int($value)}]
}
}
proc isFloat {value} {
expr {![catch {expr {double($value)}}]}
}
proc getFloat {value {errorValue 0.0}} {
if {[catch {expr {double($value)}} res]} {
return $errorValue
} else {
return $res
}
}
proc isList {value} {
expr {![catch {llength $value}]}
}
proc isAlphaWord {value} {
if {[string first \0 $value] >= 0} {
return 0
}
regexp -nocase -- {^[a-z0-9]+$} $value
}
proc getAlphaWord {value {errorValue {}}} {
if {[isAlphaWord]} {
return $value
} else {
return $errorValue
}
}
# This function prepares strings for expression testing
# it removes (trim) spaces and tabs around the string
# and then call quote to make sure special chars (like \0)
# will get noticed and will generate an error in the isXXX
# proc which use expr. (was determined to be needed
# by the test suite)
proc Munge {value} {
# only trim spaces, \r, \n ... might be 'dangerous'
quote [string trim $value " \t"]
}
[... you get the idea... it also has a test suite in the source release...]
Obviously what Jim said is also true,
but the above might help if what you try to determine
is if a given string is (also) of a valid type...
In article <36272F...@pinebush.com>,
Christopher Nelson <ch...@pinebush.com> wrote:
> bo...@aol.com wrote:
> > The other thing that can be confusing at first is the data types. Strings
and
> > lists are distinct data types that can cause trouble when mixed.
>
> "distinct" yes, but indistinguishable. My best wishes and a hearty
> "Huzzah!" to anyone who can complete this proc:
>
> proc typeOf { x } {
> if { <some mysterious operation on x> } {
> return STRING
> } elseif { <some mysterious operation on x> } {
> return LIST
> }
> ... int, etc.
> }
>
> so that the following two calls return appropriate values:
>
> typeOf [list a b c]
> typeOf "a b c"
>
> Chris
>
> P.S. An binary extension is cheating (but I'll take it).
--
http://www.demailly.com/~dl/