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 andrew...@gmail.com
javascript: wrote:
process5 (state::CircuitModel, input::Float)
@withonly state::CircuitModel, input begin
v1 = 1 # fine since v1 is a
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 andrew...@gmail.com
wrote:
process5 (state::CircuitModel, input::Float)
@withonly
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 andrew...@gmail.com
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 are
coming from and what's happening to them – and that's really valuable
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
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 andrewsim...@gmail.com wrote:
No problem Mike, thanks for taking the
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
[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
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
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*
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
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)
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
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
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
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)
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 –
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
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.
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
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
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
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
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
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
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
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!
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
wasted
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 -
Personally, I'm not super excited about this idea.
-- John
On Jun 11, 2014, at 9:13 PM, Andrew Simper andrewsim...@gmail.com 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
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
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
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
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
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 map a
35 matches
Mail list logo
