Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > microsoft.public.scripting.vbscript > #11181 > unrolled thread

Weird bug

Back to article view | Back to microsoft.public.scripting.vbscript

Contents

  Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-16 13:28 -0500
    Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-16 19:50 +0100
    Re: Weird bug "Dave \"Crash\" Dummy" <invalid@invalid.invalid> - 2015-11-16 15:28 -0500
    Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-16 16:13 -0500
      Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-16 22:57 +0100
        Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-16 18:10 -0500
          Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 01:20 +0100
            Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-16 21:11 -0500
    Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 10:44 +0100
      Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 11:19 +0100
        Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 11:31 +0100
      Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-17 09:06 -0500
        Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 15:24 +0100
          Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-17 10:35 -0500
            Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 16:45 +0100
        Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 17:13 +0100
          inline "End If" bug, was Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 17:41 +0100
            Re: inline "End If" bug, was Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 18:27 +0100
              Re: inline "End If" bug, was Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 19:37 +0100
                Edsger Wybe Dijkstra was: Re: inline "End If" bug, was Re: Weird bug "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-11-17 19:44 +0100
                Re: inline "End If" bug, was Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 20:47 +0100
          Re: Weird bug "Mayayana" <mayayana@invalid.nospam> - 2015-11-17 12:01 -0500
            Re: Weird bug "R.Wieser" <address@not.available> - 2015-11-17 18:47 +0100
    Re: Weird bug "R. Roesler" <worm.composter@nospam.arcornews.de> - 2015-11-19 13:12 +0100

Page 1 of 2  [1] 2  Next page →

#11181 — Weird bug

I just wasted hours before discovering this:

x = -18

x = x + 9: If x > 10 Then x = 10: If x < 0 Then x = 0

MsgBox x

'  Returns -9, but, this works:

x = -18

x = x + 9: If x < 0 Then x = 0

MsgBox x

Why? Is only one colon allowed? I've never noticed that

problem before. It works fine in VB6.

[toc] | [next] | [standalone]

#11182

"Mayayana" <mayayana@invalid.nospam> wrote on 16 Nov 2015 in 
microsoft.public.scripting.vbscript:

> I just wasted hours before discovering this:
> x = -18
> x = x + 9: If x > 10 Then x = 10: If x < 0 Then x = 0
> MsgBox x
> 
> '  Returns -9, but, this works:

no "but", as it works according to specs!

The [original] inline form of If..Then 
excludes all statements following on the same line, 
as the young William Gates intended. 
The multiline If..Then appeared much later in Basic.

So:

If false Then MsgBox 1 : MsgBox 2

excludes both messages.

If false Then MsgBox 1 : If true Then MsgBox 2

does likewize.

Only[!!!] the inline Else or ElseIf ends this behavour.

If false Then MsgBox 1:MsgBox 2 ElseIf true Then MsgBox 3

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11183

Mayayana wrote:
> I just wasted hours before discovering this:
> 
> x = -18
> 
> x = x + 9: If x > 10 Then x = 10: If x < 0 Then x = 0
> 
> MsgBox x
> 
> '  Returns -9, but, this works:
> 
> x = -18
> 
> x = x + 9: If x < 0 Then x = 0
> 
> MsgBox x
> 
> Why? Is only one colon allowed? I've never noticed that
> 
> problem before. It works fine in VB6.

Operations after "Then" on the line are only carried out if the
conditional statement is true. In your first example, the condition is
false and everything else on the line is ignored. In the second example,
the condition is true and the subsequent operations are carried out.
AFAIK the only limit to the number of operations that can be chained
with colons is the character length of the line.

-- 
Crash

"I am not young enough to know everything."
~ Oscar Wilde ~

[toc] | [prev] | [next] | [standalone]

#11184

  You both seem to be right, but for the wrong
reason. I've always known : as the same as
a line return, simply used for formatting. It
should matter what code is in between the
colons as long as they're valid lines. Yet when
I tried this exact example in VB6 it failed there,
too! I guess I need to be more careful with :
in the future.

[toc] | [prev] | [next] | [standalone]

#11185

"Mayayana" <mayayana@invalid.nospam> wrote on 16 Nov 2015 in 
microsoft.public.scripting.vbscript:

>   You both seem to be right, 

There is no "you both", if you do not quote.

> but for the wrong
> reason. I've always known : as the same as
> a line return, simply used for formatting. It
> should matter what code is in between the
> colons as long as they're valid lines.

Well, you are wrong in VBS.

VBS is not VB or VBA.

> Yet when
> I tried this exact example in VB6 it failed there,

Off topic, we are talking VBS.

> too! I guess I need to be more careful with :
> in the future.

Well no, you nieed to understand how VBS works.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11186

| Well no, you nieed to understand how VBS works.


  Try this one. It seems to work fine unless there's
a multiple If/Then:

Dim x, y, z

x = 7: y = 6: z = 2: y = z + 5: x = 4

MsgBox x

[toc] | [prev] | [next] | [standalone]

#11187

"Mayayana" <mayayana@invalid.nospam> wrote on 17 Nov 2015 in 
microsoft.public.scripting.vbscript:

> 
>| Well no, you nieed to understand how VBS works.
> 
> 
>   Try this one. It seems to work fine unless there's
> a multiple If/Then:
> 
> Dim x, y, z
> 
> x = 7: y = 6: z = 2: y = z + 5: x = 4
> 
> MsgBox x

No I won't, there is no If..Then here.

If you want to explain something, please do.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11188

| >   Try this one. It seems to work fine unless there's
| > a multiple If/Then:
| >
| > Dim x, y, z
| >
| > x = 7: y = 6: z = 2: y = z + 5: x = 4
| >
| > MsgBox x
|
| No I won't, there is no If..Then here.
|

  Yes. That's my point. You're talking about a
very sepcific use of colons with If/Then to execute
multiple statements. I'm talking about the other
use of colons -- to serve as line returns in order
to write compact code. The line I wrote above is
a sample. It works perfectly well. Here's another one:

Dim x, y, z

x = 4: y = "apple": z = Instr(y, "l") + 10: x = x + z

MsgBox x

  Those are 4 lines written without carriage returns.
The sample I originally posted was also not a compound
If/Then. It was 3 lines of code, each a complete line
on its own, 2 of which happened to be If/Then
statements.

   I'm only posting this to warn people who may
not be aware of this inconsistency. You may
not use colons as line returns. If not then this
issue will be of no concern to you. But many people
do use colons in that way, and I'm one of them.
Now I know to be on the lookout for complications
in the future. 

[toc] | [prev] | [next] | [standalone]

#11189

Mayayana,

Evertjan is right, it works as designed.

Lets look at it from another angle, and regard the following: If a condition
is met, I want both X and Y to be set to Zero.   I would, and always have
written that as :

if condition then x=0: y=0

You on the other hand would be reading it as:

if condition then x=0:
y=0

To be more specific, you would not be able to write a one-line,
multy-command "then" ....

> as the same as a line return, simply used for formatting

Well, that is where you problem exists.   The line return terminates a
*line* (which can hold one or more commands), the colon only terminates a
single command.

> It works fine in VB6.

I strongly doubt that.  Using it predecessor (VB5) a line like:

if False then debug.print "1": debug.print "2"

prints neither the "1" nor the "2".

> I'm talking about the other use of colons -- to serve as
> line returns in order to write compact code

Suggestion: Do not try to take a feature on one programming language and
expect another one (even though deceptivly named almost the same) to adhere
to it.  Each language "does its own thing".   No ammount of "yes but ...."
will change anything to that I'm afraid.

Regards,
Rudy Wieser



-- Origional message
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
n2d78f$639$1@dont-email.me...
> I just wasted hours before discovering this:
>
> x = -18
>
> x = x + 9: If x > 10 Then x = 10: If x < 0 Then x = 0
>
> MsgBox x
>
> '  Returns -9, but, this works:
>
> x = -18
>
> x = x + 9: If x < 0 Then x = 0
>
> MsgBox x
>
> Why? Is only one colon allowed? I've never noticed that
>
> problem before. It works fine in VB6.
>
>
>
>
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#11190

"R.Wieser" <address@not.available> wrote on 17 Nov 2015 in 
microsoft.public.scripting.vbscript:

> Evertjan is right, it works as designed.

Thanks for enhancing my self-esteem, Rudy.

Most "weird bugs" are just misinterpreting the design.

cf 2003:
<https://groups.google.com/d/msg/microsoft.public.scripting.vbscript/P72yYHF
o16c/lGdII2Ezmb0J>

cf 2007:
<https://groups.google.com/d/msg/microsoft.public.scripting.vbscript/95IzaEP
uGpA/7DmYnVv45bMJ>

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11191

Evertjan,

> Thanks for enhancing my self-esteem, Rudy.

You're welcome. :-)

> Most "weird bugs" are just misinterpreting the design.

Or, as in Mayayana's case, expecting one language to adhere to another
languages method-of-working ...

... Which I also have made myself guilty of in the past, so I cannot really
blame him. :-| :-)

Regards,
Rudy Wieser


-- Origional message:
Evertjan. <exxjxw.hannivoort@inter.nl.net> schreef in berichtnieuws
XnsA555733215E9Feejj99@194.109.6.166...
> "R.Wieser" <address@not.available> wrote on 17 Nov 2015 in
> microsoft.public.scripting.vbscript:
>
> > Evertjan is right, it works as designed.
>
> Thanks for enhancing my self-esteem, Rudy.
>
> Most "weird bugs" are just misinterpreting the design.
>
> cf 2003:
>
<https://groups.google.com/d/msg/microsoft.public.scripting.vbscript/P72yYHF
> o16c/lGdII2Ezmb0J>
>
> cf 2007:
>
<https://groups.google.com/d/msg/microsoft.public.scripting.vbscript/95IzaEP
> uGpA/7DmYnVv45bMJ>
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11192

| To be more specific, you would not be able to write a one-line,
| multy-command "then" ....
|
| > as the same as a line return, simply used for formatting
|
| Well, that is where you problem exists.   The line return terminates a
| *line* (which can hold one or more commands), the colon only terminates a
| single command.
|
   It seems that the colon terminates any line
*except* an If/Then without problem. My
example above includes 2 operations in one
segment. I don't know how you can say that's
not a line:

x = 4: y = "apple": z = Instr(y, "l") + 10: x = x + z

  Those are all lines. [z = Instr(y, "l") + 10] is a
compound operation. I don't know how you're
defining a command vs a line.

  A colon acts as a line break. An example is in the
WSH help, under ExecuteGlobal:

'Include multiple statements in the statement argument, using colons or 
embedded line breaks to separate them.'

"Sub Proc2: Print X: End Sub"

--------------
  Here's another sample that works perfectly well:

Dim FSO: Set FSO = CreateObject("Scripting.FileSystemObject"): 
FSO.DeleteFile "C:\windows\desktop\test1.txt", True: Msgbox "file deleted.", 
64

 That's a whole script in a single line. Each segment
must be a separate line. Thus, the colon is acting
as a line return.

| > It works fine in VB6.
|
| I strongly doubt that.  Using it predecessor (VB5) a line like:
|

   You're right. It turns out that a double If/Then
doesn't work in VB6. That's disconcerting, as I've
been using colons for years.

   For me the issue here is not what's officially
correct or who's right. The point is simply that
the design is a "gotcha". I would have expected
my complete If/Then line to be processed in
the same way as if I had used a line return. It
seems to be the only case where the colon doesn't
work properly as a line return.

  The multiple statement If/Then, by contrast,
is not written in the same way. From the help:

If A > 10 Then A = A + 1 : B = B + A : C = C + B

  That's not what I was writing. I wrote complete
lines that were not related:

 If A > 10 then A = A + 1: If B < 10 then B = 0

    Anyway, at this point anyone who uses colons
should understand what I'm talking about and be
adequately warned. That's the only reason for my
posting. I'm not concerned whether Bill Gates is
exonerated or sentenced to hang by his thumbs. :)

[toc] | [prev] | [next] | [standalone]

#11193

"Mayayana" <mayayana@invalid.nospam> wrote on 17 Nov 2015 in 
microsoft.public.scripting.vbscript:

>  That's a whole script in a single line. Each segment
> must be a separate line. Thus, the colon is acting
> as a line return.

Nonsense.

A line is just a line, terminated by an end of line.
A statement is just a statement.

A statement that is not part of another statement
needs to be preceded by an end of line, a colon 
or it is at the start of the code.

A statement does not need any termination.

There is no requirement for a statement 
to "have" a separate line.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11194

  I knew you'd have some kind of cranky rebuttal.
I'm done. You're only further confusing a simple
point.

[toc] | [prev] | [next] | [standalone]

#11195

"Mayayana" <mayayana@invalid.nospam> wrote on 17 Nov 2015 in 
microsoft.public.scripting.vbscript:

[you forgot to quote, in your anger perhaps]

>   I knew you'd have some kind of cranky rebuttal.
> I'm done. You're only further confusing a simple
> point.

You think it cranky that I find a line must be a line?

What is not simple about that?

What is cranky about that?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11196

Mayayana,

> I don't know how you can say that's not a line:

Thats easy to explain: I never said that.

What I however *did* say that, as you have quoted in your message, "You
would not be able to write a one-line multy-command *THEN*" ....

And yes, your example is a single-line containing multiple commands
(assignments actually).  But it also has got *nothing* to do with your
stated problem, the (as far as you think) quirks of the "if" command ...

>   A colon acts as a line break.

Nope, it does not.    The line break also has another function, namely the
termination of an(y) open "if" (in the case the "then" is, on the same line,
followed with more code).

> 'Include multiple statements in the statement argument,
> using colons or embedded line breaks to separate them.'

In itself that is correct.  But I think you know as well as I that that is
not the full documentation about the language, and that several commands
mention their own exceptions to it.

> Here's another sample that works perfectly well:

And alas, again having nothing to do with the "if" command, and how it alter
the flow of the program.  As is your "whole script in a single line." :-(

> Thus, the colon is acting as a line return.

Only if you ignore the line returns other effects, which your example code
does not make any use of.

> That's disconcerting, as I've been using colons for years.

Obviously not in VB6 .... :-D

> The point is simply that the design is a "gotcha".

Only if you tried to use this design when having used another design first.
Would you have used this design first the other design would have the
gotcha.

To quote myself:
<quote>
Suggestion: Do not try to take a feature of one programming
language and expect another one to adhere to it.  Each language
"does its own thing".   No ammount of "yes but ...." will
change anything to that I'm afraid.
</quote>
(typo fixed: "on one" -> "of one". Also left out a bracketed sub-sentence)

> For me the issue here is not what's officially correct or who's right

Than please don't try to create a problem where there is none.  Its just a
difference in what you think is true (how something should work), and what a
programming/scripting language has been defined to how it works.


But a question: Have you already thought about the problem I described in my
initial reply, where I wanted to set both "X" and "Y" to zero when a
condition was met ?

How would you, using your approach, set that "Y" to zero ? -- without
turning the "if" in a multi-line construction ofcourse.

Maybe the designer of the programming language saw something you (still)
have not  .... :-)

Regards,
Rudy Wieser


-- Origional message
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
n2fc8p$aal$1@dont-email.me...
> | To be more specific, you would not be able to write a one-line,
> | multy-command "then" ....
> |
> | > as the same as a line return, simply used for formatting
> |
> | Well, that is where you problem exists.   The line return terminates a
> | *line* (which can hold one or more commands), the colon only terminates
a
> | single command.
> |
>    It seems that the colon terminates any line
> *except* an If/Then without problem. My
> example above includes 2 operations in one
> segment. I don't know how you can say that's
> not a line:
>
> x = 4: y = "apple": z = Instr(y, "l") + 10: x = x + z
>
>   Those are all lines. [z = Instr(y, "l") + 10] is a
> compound operation. I don't know how you're
> defining a command vs a line.
>
>   A colon acts as a line break. An example is in the
> WSH help, under ExecuteGlobal:
>
> 'Include multiple statements in the statement argument, using colons or
> embedded line breaks to separate them.'
>
> "Sub Proc2: Print X: End Sub"
>
> --------------
>   Here's another sample that works perfectly well:
>
> Dim FSO: Set FSO = CreateObject("Scripting.FileSystemObject"):
> FSO.DeleteFile "C:\windows\desktop\test1.txt", True: Msgbox "file
deleted.",
> 64
>
>  That's a whole script in a single line. Each segment
> must be a separate line. Thus, the colon is acting
> as a line return.
>
> | > It works fine in VB6.
> |
> | I strongly doubt that.  Using it predecessor (VB5) a line like:
> |
>
>    You're right. It turns out that a double If/Then
> doesn't work in VB6. That's disconcerting, as I've
> been using colons for years.
>
>    For me the issue here is not what's officially
> correct or who's right. The point is simply that
> the design is a "gotcha". I would have expected
> my complete If/Then line to be processed in
> the same way as if I had used a line return. It
> seems to be the only case where the colon doesn't
> work properly as a line return.
>
>   The multiple statement If/Then, by contrast,
> is not written in the same way. From the help:
>
> If A > 10 Then A = A + 1 : B = B + A : C = C + B
>
>   That's not what I was writing. I wrote complete
> lines that were not related:
>
>  If A > 10 then A = A + 1: If B < 10 then B = 0
>
>     Anyway, at this point anyone who uses colons
> should understand what I'm talking about and be
> adequately warned. That's the only reason for my
> posting. I'm not concerned whether Bill Gates is
> exonerated or sentenced to hang by his thumbs. :)
>
>
>

[toc] | [prev] | [next] | [standalone]

#11197 — inline "End If" bug, was Re: Weird bug

"R.Wieser" <address@not.available> wrote on 17 Nov 2015 in 
microsoft.public.scripting.vbscript:

> Maybe the designer of the programming language saw something you (still)
> have not  .... :-)

The only bug here that was introduced in VBS is 
that the following is illogically allowed:

If boolean Then statement Else statement End If

as the "End If" is only part of the multiline If,
not used or needed in the inline If syntax.

Correct is:

If boolean Then statement Else statement

It is said that years ago [2003??] MS did put in an exception
for that error during an update and immediately sites 
like cnn.com came tumbling down, so they restored the error.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11199 — Re: inline "End If" bug, was Re: Weird bug

Evertjan.

> The only bug here that was introduced in VBS is
> that the following is illogically allowed:

Please explain why its illogical.  All I see is a method to terminate a
"then" before an line-end is encountered.  It would definitily solve
Mayayana's initial problem:

x = x + 9: If x > 10 Then x = 10 *end if*: If x < 0 Then x = 0

That a line-end *can* be used to terminate a single-line "if" does not mean
it should be the *only* way to do it.  :-)

> Correct is:
>
> If boolean Then statement Else statement

Nope.   Its just how quite a few (but definitly not all!) languages have
defined it.   It does not mean its the *only way* anyone may implement it in
his language.

I know of languages which use your above description and work as Mayayana
described (continuing after a "then" if no "else" is found, or after the
first command after the "else").

Ofcourse, several of those languages have "command grouping" commands and/or
symbols, making it again possible to have a "then" or "else" execute an
abitrary number of commands/equations.  Just think of how C++ does it, using
"{" and "}" to group commands together.

VBS (and a number of other languages) do not have such command-grouping
symbols/commands/methods, so they needed to think of something else.

Regards,
Rudy Wieser


-- Origional message:
Evertjan. <exxjxw.hannivoort@inter.nl.net> schreef in berichtnieuws
XnsA555B3EE5C6F5eejj99@194.109.6.166...
> "R.Wieser" <address@not.available> wrote on 17 Nov 2015 in
> microsoft.public.scripting.vbscript:
>
> > Maybe the designer of the programming language saw something you (still)
> > have not  .... :-)
>
> The only bug here that was introduced in VBS is
> that the following is illogically allowed:
>
> If boolean Then statement Else statement End If
>
> as the "End If" is only part of the multiline If,
> not used or needed in the inline If syntax.
>
> Correct is:
>
> If boolean Then statement Else statement
>
> It is said that years ago [2003??] MS did put in an exception
> for that error during an update and immediately sites
> like cnn.com came tumbling down, so they restored the error.
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11201 — Re: inline "End If" bug, was Re: Weird bug

"R.Wieser" <address@not.available> wrote on 17 Nov 2015 in
microsoft.public.scripting.vbscript: 
>> Correct is:
>>
>> If boolean Then statement Else statement
> 
> Nope.   Its just how quite a few (but definitly not all!) languages have
> defined it.   It does not mean its the *only way* anyone may implement
> it in his language.
> 
> I know of languages which use your above description and work as
> Mayayana described (continuing after a "then" if no "else" is found, or
> after the first command after the "else").

I am not interested in "other languages" here, 
only in the developement of this:

Beginners All-purpose Symbolic Instruction Code.

Seen in the light of other languages,
Basic was as bad as Edsger Wybe Dijkstra promised it to be, IMO:

"BASIC programmers are mentally mutilated beyond hope of regeneration"
said Edsger Wybe Dijkstra in
How do we tell truths that might hurt? (1975-06-18) 

[In fact our Edsger was primarily fighting a language that did everything 
with GoTo, no subroutines, no functions, so no modularity or black box 
testing, just making a unresolvable knot of even the smallest logical 
construct. And no possibility to sensibly name variables other than by a 
single Capital letter plus a number. Referring to his 1975 words however is 
a joy in itself]

=========================

In principio [in the beginning] there was only:

If boolean GoTo linenumber

then came:

If boolean Then statement

and then:

If boolean Then statement Else statement

after that the multiline If was introduced:

If boolean Then
   statement 
Else 
  statement
End If

The multiline "ElseIf" addition even later.

The "End If" was never, formally or otherwise planned, introduced 
in the older single line If, it only was discovered in this NG
and recognised as a bug by MS.

> 
> Ofcourse, several of those languages have "command grouping" 

[snip]

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11202 — Edsger Wybe Dijkstra was: Re: inline "End If" bug, was Re: Weird bug

"Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote on 17 Nov 2015 in 
microsoft.public.scripting.vbscript:

> "BASIC programmers are mentally mutilated beyond hope of regeneration"

> said Edsger Wybe Dijkstra in
> How do we tell truths that might hurt? (1975-06-18) 

<https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD498.PDF>

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | microsoft.public.scripting.vbscript

csiph-web