On Saturday, December 19, 2015 at 6:17:18 AM UTC-5, Tim Holy wrote:
>
> Presumably you need an esc around the exp. See the metaprogramming
> chapter.
>
So the Julia maintainers never pulled my pull request from almost 2 years
ago that fixed that?
This would not have happened with my suggested reworking of macro hygiene,
I think. I am not set up to test it right now.
Here is my take for what it is worth as an observer of the Julia language:
I think your second method foo(x::Number) is unreachable because your first
method foo{T:Number}(x::T) is more specific and there are no arguments to
which only the second method is applicable. Having both methods would
that it wouldn't be as trivial as it sounds.
On Friday, 13 June 2014 02:01:28 UTC+1, David Moon wrote:
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
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
I have a pending pull request #6910 to fix macros to behave as you expect,
but until that gets integrated you will need to use the esc function in
your macro to tell the macro system that x, y, and expr are in the macro
caller's context, not the macro definition's context. There is no
in the sample code I
supplied, all named T. It would have been clearer if I had given them
distinct names, although that does not seem to be the usual practice in
Julia.
If you are interested in method reflection, I suggest looking at the output
of methods()
On Friday, May 30, 2014, David Moon
On Saturday, May 31, 2014 1:08:29 PM UTC-4, Iain Dunning wrote:
And I don't necessarily think this is wrong - look at the code it generates
f{t,n}(::Type{Array{t,n}},::Array{t,n}) at none:3
f{t,n}(::Type{Array{t,N}},::Array{t,n}) at none:2
There is nothing to distinguish these two from a
I noticed something strange about reflection on parameterized types.
Consider this simplified code:
julia type X{T : Number} x::T end
julia f{T}(::X{T}) = 1
julia XT = methods(f).defs.sig[1]
X{T}
julia XT : X
*false*
julia X : XT
true
julia type Y{T} y::T end
julia g{T}(::Y{T}) = 1
julia YT =
On Tuesday, May 20, 2014 4:53:38 PM UTC-4, Jameson wrote:
Can you open a pull request? That's the best way to send a diff and have
it evaluated.
Thanks for the direction. I don't know much about Git, but I can probably
figure out how to make a pull request. I am more of a Mercurial and
What bothers me about the @ is that it is too easy an answer for why if,
while, for, try, yieldto, etc. are hard-wired into the language instead of
being implemented as macros. Nobody wants to write @if x==y ; do this
@else do that @end! But the real answer has got to be more interesting
Google groups wouldn't let me send this by email. I apologize if there is
any duplication.
On May 9, 2014, at 10:37 AM, Adam Smith wrote:
My main reason for using eval() is to convert from a Symbol to a
Type. If they supplied a full expression like (1 + 1) as the
default value for an
Consider this:
someval=foo
def f(x::Int, @maybe y::String=someval) = (x,y)
f(1) = (1, foo)
someval=bar
f(2) = (2, foo) # should be (2, bar)
def g(x) = x + seen
def h(x::String, @maybe y::String=g(x)) = y
h(foo) # gives an error but should be foo seen
See what I am getting at now about when
On Tuesday, April 8, 2014 7:17:18 PM UTC-4, Cameron McBride wrote:
I've long enjoyed ruby's `loop` keyword for exactly this type of use.
Too bad Julia doesn't have (full featured) macros so you could write loop
yourself and just use it without first convincing a whole lot of people
it's a
In Julia-0.3.0-prerelease-d2d9bd93ed.app on Mac OS X 10.6:
The following test case was boiled down from a much larger piece of code.
function f(x)
answer = false
if (x 10)
anwser = true
end
return answer
end
does not issue any warnings, and always returns
On Friday, March 7, 2014 11:24:51 AM UTC-5, Gunnar Farnebäck wrote:
This is a long-standing issue. See
https://github.com/JuliaLang/julia/issues/265
I didn't know about that, thanks for the pointer. In that issue I see:
*malmaud https://github.com/malmaud *commented January 06,
I am not suggesting any change to :(x+y) so it would continue to be the
same as quote x+y end. I think that would return Expr(internal_symbol(+,
context), internal_symbol(x, context), internal_symbol(y, context)) to
use a sketchy syntax that might not actually be valid Julia.
I like using the
I should have said *quote* special form implicitly accessed a symbol
context created each time a *named* function is entered or a top-level form
is evaluated. Can't have anonymous functions implicitly create a symbol
context or you can't use functionak programming inside of macros and you
On Monday, February 24, 2014 6:54:59 AM UTC-5, andrew cooke wrote:
Maybe (I don't think so) Julia needs some kind of concept like abstract
methods, where you can name methods for Number that any subtype must
implement?
Long ago in Flavors this was called required methods. With multiple
On Tuesday, February 25, 2014 7:14:37 AM UTC-5, David Moon wrote:
The advantage of making it an explicit concept in the language, rather
than just defining a method that signals an error, is that it can be
checked at compile time.
In Julia, compile time is load time. Specifically, after
Hygienic macros could be both better and simpler. Julia's hygiene only
works in simple cases, I think, and requires too much manual intervention.
This is because it is done in the wrong place, in the output of macro
expansion, so the macro expander has to guess the context of each symbol.
21 matches
Mail list logo
