"with" statement in Lua?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

"with" statement in Lua?

Dave Bollinger
   Food for thought:

   Back in the list archives there are several threads about pointer
aliasing, caching pointers to objects, and such - essentially describing
the functionality of Pascal's "with" statement.  I'd like to mention one
additional benefit of such a statement that I haven't yet seen mentioned: 
you could sweeten up the var:func() format calls so that they behave more
like the object/method model, giving them direct access to private
"properties".   Basically, var:func() would be sugar for:

  v.f = function(self, params)
    with self do

      -- you could now directly access v's contents without prefacing with
"self."

    end
  end

  I haven't delved into the source code, so perhaps I'm a bit naive, but it
seems like it would just involve an additional first pass through the
"with" frame when checking for symbolic names.  (in other words, it could
be just syntax for setting up a symbol frame - it needn't literally create
a pointer alias, although I'm sure someone out there would probably be
interested to have that as well)

  It could break code, though, if there were naming conflicts between the
table's members and a global variable or parameter.  :-(  OTOH, it
shouldn't preclude the use of "self.var", that syntax should still be valid
without conflict, even within the with frame for self (where "self" would
not exist, so it should fall back to the next frame and find the formal
parameter (psuedo-parameter)).

   Well, I don't know how feasible/desirable it really is, but I thought
I'd toss it out for comments?

   Cheers,

   Dave

Reply | Threaded
Open this post in threaded view
|

Re: "with" statement in Lua?

Luiz Henrique de Figueiredo
>From [hidden email] Tue Jul 13 02:59:53 1999
>From: Dave Bollinger <[hidden email]>

>   Back in the list archives there are several threads about pointer
>aliasing, caching pointers to objects, and such - essentially describing
>the functionality of Pascal's "with" statement.

There's no way this can work given Lua's table semantics: there's no notion
of a field being present in a table, because tables are dynamic.
In other words, there's no way you can "test" whether "v" may refer to a field
in a table and not to a global variable, because it's legal to write t.v.
So,
	with t do
		w=a
		v=20
	end
would not work. Which of the three a,v,w are global?

unless you write something like:
	with t do
		.w=a
		.v=20
	end
(which is ambiguous because it conflict with w=a.v)
Plus, if you're writing .w, why not write t.w?
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: "with" statement in Lua?

Norman Ramsey-3
In reply to this post by Dave Bollinger
I've programmed in both Pascal and Modula-3 using the `with' statement.
Consensus seems to be that the M3 version (which is like `let' binding
in functional languages) is not too bad, whereas the Pascal version
is best avoided.  The key is the M3 `with' makes the names of
the new identifiers explicit, whereas in Pascal they are implicit.

Standard ML's `open' suffers from the same problem: you introduce a
whole host of names, from you know not where...

Norman

Reply | Threaded
Open this post in threaded view
|

Re: "with" statement in Lua?

Dave Bollinger
In reply to this post by Dave Bollinger
 >> Which of the three a,v,w are global?

   I knew I was overlooking something, creation, and I see how it would be
impossible to determine if the coder intended to create a new variable in
the table or globally.  I was approaching it thinking about fields that had
PREVIOUSLY been created in t, only those would have been table fields, the
others would've had to been assumed to be global, but that just doesn't
work if creating NEW fields in t.)

 >> with t do
 >>    .w=a
 >>    .v=20

   Understood.  This is similar to the syntax that Visual Basic uses, where
the "." is more stringently required as an accessor to the object, and
would be easier to establish context within.  In that case ".w" and ".v"
would be members of t, "a" would not.  (to access a field named "a" in t
within that with statement, you'd have to call it ".a")

 >> (which is ambiguous because it conflict with w=a.v)

   In that case, plain "w" would not be a member of t, nor would "a.v". 
They'd have to be specified as ".w" or ".a.v" to be members of t.  "w=av"
inside a with (if it were to require the . accessor as VB does) should work
exactly the same as if no with statement were present.

 >> Plus, if you're writing .w, why not write t.w?

   Laziness?  ;-)  It might save you from having to create your own alias
objects when you have a deeply nested "tables-within-tables-within-tables"
setup, but I agree that it's almost too trivial to consider.  I just wanted
to toss the idea into the mix again.  Since it wouldn't really DO anything,
even if it were possible, I certainly don't have a literal NEED for it.

   Cheers,

   Dave

Reply | Threaded
Open this post in threaded view
|

Re: "with" statement in Lua?

Luiz Henrique de Figueiredo
In reply to this post by Dave Bollinger
>From [hidden email] Tue Jul 13 22:46:51 1999
>From: Dave Bollinger <[hidden email]>

> >> Which of the three a,v,w are global?
>
>   I knew I was overlooking something, creation, and I see how it would be
>impossible to determine if the coder intended to create a new variable in
>the table or globally.  I was approaching it thinking about fields that had
>PREVIOUSLY been created in t, only those would have been table fields, the
>others would've had to been assumed to be global, but that just doesn't
>work if creating NEW fields in t.)

Like I said, there's no notion of "previously created fields".
I mean, there's no way the parser can know about this, because there are no
type declarations for tables.
It *could* be done at runtime, but I think that would be slow.
Plus, like you said, it wouldn't buy us much.

About Modula 3 "with" statement, it seems to me that DO...END with local
declarations is almost equivalent.
--lhf