[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Syntax request (coming to terms with false)
- From: Victor Bogado da Silva Lins <bogado@...>
- Date: 18 Jan 2002 14:30:24 -0200
On Thu, 2002-01-17 at 20:26, RLake@oxfam.org.uk wrote:
>
> OK, I'm trying to come to terms with false. I've started going through my
> code looking for places where I assign the result of a boolean expression
> to a table expecting nil to delete the key (since false will no longer do
> that). Maybe I'm the only person with this problem.
>
> I've realised that I will need a lot more if statements and local variables
> than I used to have. It would be really nice if the syntax of "if" were
> extended to include
>
> if local-variable-list = expression-list then ...
>
> The scope of the local variables would be from the "then" to the matching
> "end", and the test would be on the truth value of the first variable in
> the list. The one problem with this syntax is that it would mask syntax
> errors resulting from the use of = instead of ==, but I think I could live
> with that.
>
> I was going to ask for the same thing with while, but I realised that
> scoping rules would make this less useful than it at first appeared.
> However, a combination of an if and a repeat until would generally do the
> trick.
>
> Rici.
>
> ej:
>
> if t = function_which_might_return_false(x) then
> a[x] = t
> else
> a[x] = nil
> end
>
> replaces the casual
> t = function_with_might_return_nil(x)
>
> and:
>
> if k, v = setFirst(set, nil) then repeat
> -- do something with k and v
> k, v = setNext(set, k)
> until not k
> end
>
> is more or less equivalent to the c "for" statement with local variables. I
> know that these are slightly contrived examples, but I hope they give the
> flavour of what I'm looking for.
>
> "for" cannot be extended in this fashion, as far as I can see, because it
> would be hard to parse, and I'm hesitant to suggest new statement keywords
> like:
>
> with vlist=elist while condition
> then
> -- advance chunk
> do
> -- action chunk
> finally
> -- exception chunk
> end
>
> because it's probably a bit much for Lua and it involves the introduction
> of too many new reserved words.
>
> It's a minor cosmetic; I could write:
>
> do local v1, v2 = e1, e2
> if v1 then
> -- do something
> else
> -- do something else
> end
> end
>
> It just makes the code a little shorter, and therefore a little easier to
> read.
>
> Thanks.
>
>
> Oxfam works with others to find lasting solutions to poverty and suffering.
>
> Oxfam GB is a member of Oxfam International, a company limited by guarantee and registered in England No. 612172.
> Registered office: 274 Banbury Road, Oxford OX2 7DZ.
> Registered charity No. 202918.
>
> Visit the web site at http://www.oxfam.org.uk
Why not alloing functions to return nil or false so yout could simply
use t = function_which_might_return_nil(x) in the first example.
Since the equality in lua can be used for several variables this
propose will be confusing at least, without prior knowledge of the
convention what value should a,b,c = 0,1,2 return? 1? 3? It could even
be 3 (the number of variables seted).
My propose is that you have two values nil and false. when you evaluate
nil in a boolean context (if for instance) it would be automaticly
converted to false. This would make the behaviour compatible with the
previuos versions of lua, that didn't knew anthing about the false
value. The only possible problem would be for programs that atribute
some value to the variable 'false'.
In my proposal you have these behaviour :
if (a == nil) <- is 'a' undefined?
if (not a) <- is 'a' undefined or it is defined with a false value?
if (a) <- is 'a' defined and not false?
if (a == false) <- is 'a' defined with a false value?
--
[]'s Victor Bogado da Silva Lins
victor@visgraf.impa.br