There is some experimentation with a related issue going on in the 
DataFramesMeta package: https://github.com/JuliaStats/DataFramesMeta.jl. 
There, @with(df, expr) creates an environment in the which "local 
variables" in expr refer to column names of the dataframe df. The objective 
is parallel to what you're asking about.

In DataFramesMeta, when referring to a column named 'col' inside of the 
@with "environment", one denotes it by ':col'. So, for instance, you'd have 
"@with df :col .> 1", which returns a boolean data array that is the result 
of applying the function x -> x .> 1 to df[:col]. Possibly, then, a similar 
strategy could be used to address Stefan's point, and perhaps to a lesser 
extent David's. That is, one could do "@with foo begin body end" and 
require that references to fields of foo be formed as ':fieldname', 
'^fieldname' or some other variant that's parsable by Julia's 
metaprogramming capacities. Unless I'm mistaken, this approach would at 
least let the program know what the field names of 'foo' are *supposed* to 
be, and which names in 'body' are actually just local variables. It would 
also help to distinguish to fresh eyes which are the field names of 'foo' 
and which aren't. I don't know if this approach would completely assuage 
the worries posed above, but it may help to make the project more feasible. 
It would also put more responsibility on the coder and take a bit of magic 
out of the macro, which I believe is generally considered a good thing?

On Thursday, May 21, 2015 at 9:13:28 AM UTC-4, Magnus Lie Hetland wrote:
>
> A couple of decades ago, I remember using the with statement in Pascal. I 
> have since wished for it in several languages, but I guess in Julia, it 
> would probably be feasible without altering the language?
>
> Basically, it'd be something like
>
> type Foo
>     a
> end
>
> foo = Foo(42)
>
> @with foo do
>     a = 1
>     b = "frozzbozz"
>     # ...
> end
>
> # foo.a is now 1
>
> That is, let the fields of a composite type be available (syntactically) 
> as local variables.
>
> Now, hacking together something like this wouldn't be hard – but making it 
> really work (without weirdness or performance degradation) seems harder. 
> And maybe it's a bad idea to begin with. Or maybe someone has already done 
> it?-)
>
>
>
>

Reply via email to