This is an issue that DataFrames has struggled with and it's not an easy one.
It would be good to figure out a convenient way do deal with it, but it's a
tough design problem.
> On Jun 14, 2014, at 9:51 AM, Andrew Simper wrote:
>
> No problem Mike, thanks for taking the time to considering it!
No problem Mike, thanks for taking the time to considering it!
The @with macro you have already written means I can get on and do exactly
what I want, and I'll only use the @with f::Foo syntax in very specific
cases, just like the ones I've shown, which is basically processing a
complicated alg
Ok, I see what you mean – make the global scope explicit so that the local
scope can be implicit. This is actually a really interesting idea and could
make for a neat solution, but it also has problems of its own and would be
tricky to implement well. I'll definitely think about it some more when I
On Saturday, June 14, 2014 5:22:23 PM UTC+8, Mike Innes wrote:
>
> function process8 (state::CircuitModel, input::Float)
> state.a = 5
> end
>
> You're right that you can't tell whether the code above is correct without
> knowing about CircuitModel, but it is obvious where all the variables
function process8 (state::CircuitModel, input::Float)
state.a = 5
end
You're right that you can't tell whether the code above is correct without
knowing about CircuitModel, but it is obvious where all the variables are
coming from and what's happening to them – and that's really valuable
if/wh
On Saturday, June 14, 2014 3:41:16 PM UTC+8, Andrew Simper wrote:
>
>
>
> On Saturday, June 14, 2014 3:32:02 PM UTC+8, Andrew Simper wrote:
>>
>>
>>
>> On Saturday, June 14, 2014 3:06:46 PM UTC+8, Stefan Karpinski wrote:
>>>
>>> On Sat, Jun 14, 2014 at 1:18 AM, Andrew Simper
>>> wrote:
>>>
On Saturday, June 14, 2014 3:32:02 PM UTC+8, Andrew Simper wrote:
>
>
>
> On Saturday, June 14, 2014 3:06:46 PM UTC+8, Stefan Karpinski wrote:
>>
>> On Sat, Jun 14, 2014 at 1:18 AM, Andrew Simper
>> wrote:
>>
>>> process5 (state::CircuitModel, input::Float)
>>> @withonly state::CircuitModel
On Saturday, June 14, 2014 3:06:46 PM UTC+8, Stefan Karpinski wrote:
>
> On Sat, Jun 14, 2014 at 1:18 AM, Andrew Simper > wrote:
>
>> process5 (state::CircuitModel, input::Float)
>> @withonly state::CircuitModel, input begin
>> v1 = 1 # fine since "v1" is a name of "CircuitModel
On Sat, Jun 14, 2014 at 1:18 AM, Andrew Simper
wrote:
> process5 (state::CircuitModel, input::Float)
> @withonly state::CircuitModel, input begin
> v1 = 1 # fine since "v1" is a name of "CircuitModel"
> v5 = input # fine since "v5" is a name of "CircuitModel", and
> "inp
Hi Stefan,
I agree with Keno that a macro is the best way to tackle this problem, I
just didn't realise that the entire body of the code could easily be inside
the macro, and in the end core language features are handled in a similar
way. So if you are happy with the @with var (name1, name2) sy
Sorry for spamming, but after reading the discussion it seems like a
(slightly polished) version of the @extract macro I mentioned above (I know
the name is not great) already basically does that and a bit more, IIUC the
discussion here. Some more examples and documentation are in the code at
h
Absolutely – I didn't want to get into correct/incorrect when I implemented
@with but I definitely think the
@with Foo::(a, b)
syntax is preferable. I think I'll disable the type syntax, add support for
indexing and then send a PR to see if there's any chance of having it in
Base.
(Personally I
Keno's example showed how a simple error like forgetting that you had
assigned to `a` would cause problems, but it's even worse – that's just a
matter of making an error about the current state of the program. It's
worse than that though: if someone adds a field to a type that is used
*anywhere* wi
Not by default, but it should be simple enough (and correct, I think) to
just call macroexpand on macro calls.
macro test(expr)
(expr,)
end
(@test @foo x) == (:(@foo x),)
All I meant about the let binding is that the mutating version expands to:
let a = Foo.a
# code
Foo.a = a
end
AFAIK
[I can't get this damned thing not to include a quote of all previous
messages. I guess it only works in Google Chrome; what a pain. So sorry
about the unnecessarily long post.]
In the argument to a macro all nested macro calls are already expanded, I
think. It's certainly true that for comp
That was my first thought, too – and it's fine in principle, but remember
for that macro to be correct you'd have to handle let bindings, quoting,
local variable declarations and expanding any macros that might result in
these, then test all of those things carefully to make sure it's working
c
Mike Innes' atsign with macro is good, but it would be better if it would
iterate over the AST for its last argument and replace each occurrence of
"field" with "obj.field". That way there wouldn't be any unexpected
assignments to fields which were not actually changed, and in general no
waste
On Thursday, June 12, 2014 6:14:15 PM UTC+8, Mike Innes wrote:
>
> If there's any interest in having this in Base you're welcome to it,
> otherwise I'll probably just clean it up and store it in Lazy.jl.
>
>
Yes please, having this in Base would be brilliant for all the c++ hacks
like me!
Hi Keno,
I said this in another post, but in case you missed it I now understand
what you mean by the phrase "but this might be nice in a macro". I didn't
realise until Mike pointed out that you could enclose the entire code block
inside the macro to do what I wanted. Mike has written an @with
Thanks Carlo, that is almost what I wanted, but that macro doesn't quite
fit in this case. Thanks for pointing me towards your utilities, I'll have
a look through them and see if there is some other stuff I like.
On Thursday, June 12, 2014 9:04:09 PM UTC+8, Carlo Baldassi wrote:
>
> Sorry, I hav
I'm all for keeping people from making stupid mistakes, so I'm happy to
keep the use of local / global exactly how it is. With the help of Mike I
now have exactly what I wanted to achieve, which is perfect for me, so the
macro solution is great since I don't make those kinds of mistakes, and if
No problem!
The non-mutating version of this is exactly equivalent to writing a = Foo.a
etc., so there should be zero overhead. The mutating version uses a let
binding, which I think has a very small additional overhead, but I would
just benchmark it to make sure.
On 12 June 2014 15:03, Andrew S
Mike, you rule!
That is a serious cool macro, thankyou so much for taking the time to write
this!! I like dot notation sometimes, when you have two things like
Coordinates / Points / Complex etc it makes perfect sense to be able to see
which one you are talking about, but for crunching numbers
Sorry, I haven't had the time to read the whole discussion, but it seems
you may be interested in the @extract macro which can be found at
https://github.com/carlobaldassi/MacroUtils.jl#extract and which I have
written for this exact reason of reducing 1) code obfuscation 2) overhead
3) typing
> Having the local keyword like it is makes most sense to me, but I suppose
it isn't a big deal to me that if you don't explicitly specify local you
could be referring to something outside the current scope, which is the
case with for loops.
Javascript does this. It also has the "using" block that
Ok, managed to have a quick go at this – source with some examples:
https://gist.github.com/one-more-minute/668c5c7cdd8fd8b81d35
Currently it does nothing to avoid the issue Keno pointed out, but in
principle you could throw an error when the mutating version is used
without explicit types.
If
Brilliant Mike! This is exactly what I was after, I just want a way to
write shorthand names for things within a scope, and the @with macro does
just that :) In the example I posted I split the coefficients away from the
state so that only the state needs to be returned, I think this is good for
Actually, the mutating case is easier than that, you'd just transform the
code to:
function foo(a::Foo)
a = Foo.a
# do stuff with a
Foo.a = a
end
So long as you don't access Foo.a directly this would work fine.
At some point I'm going to make a repository of "Frequently Asked Macros" –
j
FWIW – putting to one side the question of whether or not this is a good
idea – it would be possible to do this without new language syntax.
However, you'd have to either pass a type hint or be explicit about the
variables you want:
e.g.
function tick(state::SvfSinOsc, coef::SvfSinOscCoef)
On Thursday, June 12, 2014 2:16:30 PM UTC+8, Andrew Simper wrote:
>
> It seems that the local keyword is a bit of a language kludge to me, since
> it is implied in most cases, apart from stating the new scope in the form
> of a for loop etc. It would seem more natural and consistent to me to add
It seems that the local keyword is a bit of a language kludge to me, since
it is implied in most cases, apart from stating the new scope in the form
of a for loop etc. It would seem more natural and consistent to me to add
the local keyword in front of all variables you want to be local in scope
Yep, that makes sense, thanks for showing the example. I already have
another thread going on sorting out a "fetch" macro to introduce a local
copy of the names in a type.
Out of interest, what is the "local" keyword for?
http://julia.readthedocs.org/en/latest/manual/variables-and-scoping/
On
There is no plans for namespace support other than what's already in with
modules.
I'll try to explain. Say you have a mutable
type foo
a::Int
b::Int
end
Then to modify it in a function you have to explicitly say
function bar(f::foo)
f.a = 2
f.b = 3
end
etc., for it to modify my argument
Are namespaces going to be supported in julia? It would be the same
mechanism as that, an order of preference to choose what a particular name
is referring to, no more. So if julia is not going to support "using" on a
namespace then I completely understand not wanting to support it on
variables
In my opinion, looking at that example this is way to magical. Plus the
general consensus is that you should only add syntax if it is something
extremely special that requires compiler support. For the non-mutable case,
that's not the case here. The mutable case has me worried. It introduces
the po
The problem with using a macro is that you will always have to make a local
copy of the data, if it was a language feature then then a mutable type
could be passed in as the argument and the same non-obfuscated code could
be used to update the state in place, which may be preferable depending on
I don't think it warrants syntax, but might be nice in a macro. I've had
cases where I just put my entire simulation state in a single object, so I
don't need to give 100s of parameters to every object. In that case (where
the object is more of a container than an abstraction), it might be nice to
Personally, I'm not super excited about this idea.
-- John
On Jun 11, 2014, at 9:13 PM, Andrew Simper wrote:
> So just to post again to make things clearer, right now algorithms tend to
> look pretty ugly and obfuscated since you have to prefix function arguments
> with the argument names us
So just to post again to make things clearer, right now algorithms tend to
look pretty ugly and obfuscated since you have to prefix function arguments
with the argument names using dot notation:
function tick (state::SvfSinOsc, coef::SvfSinOscCoef)
local v1::Float64 = coef.g0*state.ic1eq - c
Hi Billou, thanks for letting me know about the |> esc part! I'll make a
new topic to cover the macro part of this post.
On Friday, June 6, 2014 5:33:38 PM UTC+8, Billou Bielour wrote:
>
> For the macro problem, note that arguments of macro are expressions, or
> Symbols:
>
> Just as functions m
For the macro problem, note that arguments of macro are expressions, or
Symbols:
Just as functions map a tuple of argument values to a return value, macros
> map a tuple of argument expressions to a returned expression. They allow
> the programmer to arbitrarily transform the written code to a
41 matches
Mail list logo
