lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Thu, Nov 02, 2006 at 12:19:58AM +0100, Jerome Vuarand wrote:
> Spaghetti code come from carelessly used unconditionnal jumps (that is the bad goto). I aggree that it can complicate code maintenance, but the (bad) relationship between coders and goto is biased by the C implementation of that statement.
i'm biased from BASIC :-)

> Tagged loops translate that concept in a high level code. Breaking normal code execution path is not a good thing, it makes maintenance harder. In the tagged loops, it don't break code execution path. It just simplifies notation for some complicated code execution paths that are already possible in Lua. The proposal is just an idea, and I thought it was interesting enough to send it on the list.
> Concerning the dynamic aspect of these tagged loops, I think that there's no reason to limit the break parameter to integers, and for the same reason there should be no reason to limit the loop tag to integers. That not only provide a mechanism to (indirectly) solve the initial problem (break n), that also provide new ways to manage code execution paths at a higher level, way beyond break n or goto "label".
i'd prefer 'switch' statement for that.
> local mywhile = loop(...) -- new loop keyword, creating a loop object, getting tag(s) as parameters
>    if #({...})>0 then
>       error("Tagged loops not allowed")
>    else
>       while()
>    end
> end
> while = mywhile

sounds better, this is already partially doable using token filter. translating
the '<while> <cond> do <body> end' tokens into 'alterwhile(function() <cond> end, function() <body> end)'.
and then using special return values to sign either 'break' or
'continue', coroutines to escape multiple scopes ..
i plan to write something like this once i get token filter to report
parser state so one can hook entire blocks of tokens reliably.

however this will slow down everything to a crawl, because you'd be
possibly calling at least two functions for each iteration, not to
mention nested loops.
also, there are gotchas in current lua regarding "dynamic gotos"
due to semantics of OP_JMP. needs new opcode, no backward compat.

> That was just raw ideas to make the language even more flexible, and to eventually trigger interest. Rici's proposal you cited is a bit different, so I may hope to have more success :-) The concept of breaking several loops at once really interested me and I think I'll spend some time to elaborate the above concepts and make them as clean as possible.

i'd definitively go with:
function example()
	while cond do.parent
		local bah = true -- can be reached from anywhere
		print(parent) -- "scope (0xdeadbeef)"
		if bah then.child
			print(child) -- "scope (0xdeadbabe)"
			if bar then
				break(parent) -- break past parent
				continue(child) -- continue with then.child
			if baz() then
			-- ^^ this will continue with 'if bar then' scope
			example.parent.bah = false -- explicitly alter

that's right, every scope declares it's own local variable (classic
variable visibility rules apply) AND registers itself in parent scope
table with the "variable" name AND scope index (to allow walking) as a key.

however, this whole idea is part of much more large image where every
function is just comprised of blocks/scopes reachable via
regular tables, allowing one to change em at runtime etc etc.
basically: lisp with less obscure syntax.

if there will be interest, i can put some sort of proposal on wiki.

anyone interested in such a project please contact me privately or
discuss freely on the list. frankly, i don't have enough knownledge of lua
internals to even start planning what needs to be changed, if it
wouldn't be completele lua rewrite (i believe not).

.. That was just raw ideas to make the language even more flexible :)