Re[4]: why no "continue" statement for loops?

[lb@...]

>> Programming would be sometimes easier if it was a possibility
>> to break or continue any of a few nested loops. For example:
>> 
>>    a = 0
>>    while a < 10 do
>>          a = a + 1
>>          if a == 5 then continue end
>> (...)

NT> Don't forget you have nested functions as well now. There is nothing to
NT> stop you using state tables which can passed between functions (and out
NT> of the scope of the nesting function). The following does not replicate
NT> the behaviour of the above example. You can get some complex flow
NT> control using nested functions and return.

NT> function foo()
NT>    local state = { a = 0, b = 0 }
   
NT>    local loop = function()
NT>        state.a = 0
NT>        while state.a < 10 do
NT>            if state.a == 5 then return end
NT>            io.write(state.a, " ")
NT>            state.a = state.a + 1
NT>        end
NT>    end
   
NT>    local loop2 = function()
NT>        while state.b < 10 do
NT>             loop()
NT>             state.b = state.b + 1
NT>         end
NT>    end
   
NT>    loop2()
NT> end

NT> foo()
   
You are right, of course. You touched an interesting issue here. As
far as programming language construction is considered, there are - at
least - two approaches to implementation and usage of basic features
of a language (loops, expressions, etc).

The first approach is a strict preservation of some principal
paradigms, like functional programming in Lisp/Scheme or
non-imperative logic in Prolog. Each construction is tested against
compliance with the paradigm and non-compliant constructs are
rejected.

The second approach is oriented towards `usability' of a language.
Usually there is more than one way to achieve a goal in this approach
- everything for sake of ease, flexibility and efficiency of
programming. Perl is probably the best example here, sometimes called
`the essence of UNIX culture'.

Your solution, Nick, seems to be close to the first approach. However,
I prefer the second one - simple things done in the simplest way. This
is the reason why I choose to enhance the language rather than explore
one paradigm.

Regards
Leszek Buczkowski