Sterling Clover <[EMAIL PROTECTED]> writes:
> of course you could rewrite this in a while loop too
> although you'd have to use an assignment, but at least
> still not one with a silly "done" variable.
People seem to have overlooked the bit of Algol68 I posted,
so I'll repeat it
While If E
You get the logic and code blowup problems that require either local
variables, breaks, gotos, or continuations because you're working
with tests that generate side-effects. Mixing side-effects and tests
is going to generate a goto, sure, but if the code was rewritten in a
functional style
Vimal wrote:
Ah, yes, it is possible in this case, but you have used an extra variable.
It is okay, but our professor doesnt want to put emphasis on
Computability here (or maybe I dont realize it), but the point is: Are
such programming constructs really necessary in a programming
language? i.e.
>
> I hadn't interpreted the "reminding of Knuth" that way. I
> wouldn't count break as a goto -- what makes goto especially
> nasty is that the destination isn't indicated by the
> structure of the source; it could be just anywhere. Break is
> slightly more structured.
>
Maybe you might need to t
"Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]> writes:
> On Sep 4, 2007, at 5:02 , Miguel Mitrofanov wrote:
>
>>> It depends on arbitrary restrictions on what constitutes an
>>> (boolean) expression, something that is anathema to
>>> functional programmers :-) Spot the language:
>>> while if E
>>>
On Sep 4, 2007, at 5:02 , Miguel Mitrofanov wrote:
It depends on arbitrary restrictions on what constitutes an
(boolean) expression, something that is anathema to
functional programmers :-) Spot the language:
while if E
then S; F
else False
fi
do T
od
It reminds me of a paper
Miguel Mitrofanov <[EMAIL PROTECTED]> writes:
>> > It reminds me of a paper by Knuth, where he states that
>> > "goto" statement is necessary; don't remember the title,
>> > however.
>> I don't remember needing a goto in Haskell...
>
> Well, for imperative languages, of course.
I think my point i
> It depends on arbitrary restrictions on what constitutes an
> (boolean) expression, something that is anathema to
> functional programmers :-) Spot the language:
> while if E
> then S; F
> else False
> fi
> do T
> od
> > It reminds me of a paper by Knuth, where he states that
>
Miguel <[EMAIL PROTECTED]> writes:
>>On 9/3/07,Vimal<[EMAIL PROTECTED]> wrote:
>>>while E do
>>>S
>>>if F then
>>>break
>>>end
>>>T
>>>end
>>>
>>>He then asked us to *prove* that the above programming fragment cannot
>>>
>>>be implemented just using if and while statement, even if S and T can
>>>b
