[julia-users] Re: Is a.(b) valid?

[Ivar Nesje]

Cross linking the issue for removing the a.(b) syntax: 
#6268

Ivar

kl. 09:49:15 UTC+1 onsdag 26. mars 2014 skrev Andreas Lobinger følgende:
>
> I remembered something with 13 and mapped it to R2013x ...
>
> On Tuesday, March 25, 2014 10:47:39 PM UTC+1, Tony Kelman wrote:
>
>>
>> To pick a nit, dynamic field names for structs have been around since 
>> R13, not what I'd call recent: 
>> http://blogs.mathworks.com/loren/2005/12/13/use-dynamic-field-references/
>>
>> The containers.Map version was added in R2008b.
>>
>

[julia-users] Re: Is a.(b) valid?

[Andreas Lobinger]

I remembered something with 13 and mapped it to R2013x ...

On Tuesday, March 25, 2014 10:47:39 PM UTC+1, Tony Kelman wrote:

>
> To pick a nit, dynamic field names for structs have been around since R13, 
> not what I'd call recent: 
> http://blogs.mathworks.com/loren/2005/12/13/use-dynamic-field-references/
>
> The containers.Map version was added in R2008b.
>

[julia-users] Re: Is a.(b) valid?

[Tony Kelman]

> The dynamic names for a field in a matlab struct is (btw: this is recent)

To pick a nit, dynamic field names for structs have been around since R13, 
not what I'd call 
recent: 
http://blogs.mathworks.com/loren/2005/12/13/use-dynamic-field-references/

The containers.Map version was added in R2008b.

Re: [julia-users] Re: Is a.(b) valid?

[Patrick O'Leary]

On Tuesday, March 25, 2014 1:27:47 PM UTC-5, J Luis wrote:
>
> Sure, sometimes you might *really* want to do this despite the drawbacks, 
>> but in that case using the getfield(foo,:bar) syntax for it is just fine.
>>
>
> I'm perfectly fine with that but PLEASE, add to the manual that one can 
> also do getfield(foo,symbol("bar"))
>

Should probably be in "noteworthy differences from MATLAB", along with a 
suggestion that a Dict is probably more suitable (and doesn't have the 
extreme performance penalty of containers.Map).

Re: [julia-users] Re: Is a.(b) valid?

[J Luis]

Terça-feira, 25 de Março de 2014 18:15:28 UTC, Stefan Karpinski escreveu:
>
> First, because it's a total gotcha that putting something in parentheses 
> changes its meaning. In Matlab, things are so inconsistent in terms of 
> where you can and can't use various syntaxes, that this is hardly the 
> biggest issue, but Julia's pretty consistent and this is the *only* place 
> in the language where parentheses have such an effect. Second, one really 
> ought to avoid dynamically looking up fields like this – the code generated 
> for the field lookup is slow and the system doesn't know what type of value 
> is returned so it completely destroys type inference. Giving it its own 
> syntax just encourages using it.
>

 

> Sure, sometimes you might *really* want to do this despite the drawbacks, 
> but in that case using the getfield(foo,:bar) syntax for it is just fine.
>

I'm perfectly fine with that but PLEASE, add to the manual that one can 
also do getfield(foo,symbol("bar"))

 

>
>
> On Tue, Mar 25, 2014 at 2:07 PM, J Luis >wrote:
>
>>
>>
>> Terça-feira, 25 de Março de 2014 17:47:28 UTC, Stefan Karpinski escreveu:
>>
>>> You just need to convert the string to a symbol first:
>>>
>>> julia> type Foo
>>>  bar
>>>   baz
>>>end
>>>
>>> julia> foo = Foo(1,2)
>>> Foo(1,2)
>>>
>>> julia> foo.("bar")
>>> ERROR: type: getfield: expected Symbol, got ASCIIString
>>>
>>> julia> foo.(symbol("bar"))
>>> 1
>>>
>>>
>> I would ... swear that I had tried that too 
>>  
>>
>>>
>>> The feature is likely to be removed rather than expanded.
>>>
>>
>> Why? It brings a potentially very useful behavior.
>> Better still would be to have the (symbol("bar") be done automatically
>>
>>  
>>
>>>
>>>
>>> On Tue, Mar 25, 2014 at 1:36 PM, J Luis  wrote:
>>>

 This is a somewhat dubious feature borrowed from Matlab. I think we 
> should deprecate and then drop it.
>

 That furthermore does not work like the Matlab one ... but would be 
 nice if it did
  
  

>
>
> On Mon, Mar 24, 2014 at 11:01 PM, Sam L  wrote:
>
>> After some experimentation, it looks like second way takes a symbol 
>> or variable who's value is a symbol. 
>>
>> julia> type MyType; a::Int; end
>>
>> julia> x = MyType(3)
>> MyType(3)
>>
>> julia> x.a
>> 3
>>
>> julia> x.(a)
>> ERROR: a not defined
>>
>> julia> x.(:a)
>> 3
>>
>> julia> b = :a
>> :a
>>
>> julia> x.(b)
>> 3
>>
>>
>> On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:
>>>
>>> The doc of getfield says
>>>
>>> getfield(*value*, *name::Symbol*) 
>>>
>>> Extract a named field from a value of composite type. The syntax 
>>> a.bcalls
>>> getfield(a, :b), and the syntax a.(b) calls getfield(a, b).
>>>
>>> but when I try the a.(b) variation, it errors (or it's me who 
>>> errors?)
>>>
>>> julia> gmt_modules.write
>>> "?O"
>>>
>>> julia> gmt_modules.(write)
>>> ERROR: type: getfield: expected Symbol, got Function
>>>
>>>
>>>
>>>
>>>
>
>>>
>

Re: [julia-users] Re: Is a.(b) valid?

[Stefan Karpinski]

First, because it's a total gotcha that putting something in parentheses
changes its meaning. In Matlab, things are so inconsistent in terms of
where you can and can't use various syntaxes, that this is hardly the
biggest issue, but Julia's pretty consistent and this is the *only* place
in the language where parentheses have such an effect. Second, one really
ought to avoid dynamically looking up fields like this – the code generated
for the field lookup is slow and the system doesn't know what type of value
is returned so it completely destroys type inference. Giving it its own
syntax just encourages using it. Sure, sometimes you might *really* want to
do this despite the drawbacks, but in that case using
the getfield(foo,:bar) syntax for it is just fine.


On Tue, Mar 25, 2014 at 2:07 PM, J Luis  wrote:

>
>
> Terça-feira, 25 de Março de 2014 17:47:28 UTC, Stefan Karpinski escreveu:
>
>> You just need to convert the string to a symbol first:
>>
>> julia> type Foo
>>  bar
>>  baz
>>end
>>
>> julia> foo = Foo(1,2)
>> Foo(1,2)
>>
>> julia> foo.("bar")
>> ERROR: type: getfield: expected Symbol, got ASCIIString
>>
>> julia> foo.(symbol("bar"))
>> 1
>>
>>
> I would ... swear that I had tried that too
>
>
>>
>> The feature is likely to be removed rather than expanded.
>>
>
> Why? It brings a potentially very useful behavior.
> Better still would be to have the (symbol("bar") be done automatically
>
>
>
>>
>>
>> On Tue, Mar 25, 2014 at 1:36 PM, J Luis  wrote:
>>
>>>
>>> This is a somewhat dubious feature borrowed from Matlab. I think we
 should deprecate and then drop it.

>>>
>>> That furthermore does not work like the Matlab one ... but would be nice
>>> if it did
>>>
>>>
>>>


 On Mon, Mar 24, 2014 at 11:01 PM, Sam L  wrote:

> After some experimentation, it looks like second way takes a symbol or
> variable who's value is a symbol.
>
> julia> type MyType; a::Int; end
>
> julia> x = MyType(3)
> MyType(3)
>
> julia> x.a
> 3
>
> julia> x.(a)
> ERROR: a not defined
>
> julia> x.(:a)
> 3
>
> julia> b = :a
> :a
>
> julia> x.(b)
> 3
>
>
> On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:
>>
>> The doc of getfield says
>>
>> getfield(*value*, *name::Symbol*)
>>
>> Extract a named field from a value of composite type. The syntax a.bcalls
>> getfield(a, :b), and the syntax a.(b) calls getfield(a, b).
>>
>> but when I try the a.(b) variation, it errors (or it's me who errors?)
>>
>> julia> gmt_modules.write
>> "?O"
>>
>> julia> gmt_modules.(write)
>> ERROR: type: getfield: expected Symbol, got Function
>>
>>
>>
>>
>>

>>

Re: [julia-users] Re: Is a.(b) valid?

[J Luis]

Terça-feira, 25 de Março de 2014 17:47:28 UTC, Stefan Karpinski escreveu:
>
> You just need to convert the string to a symbol first:
>
> julia> type Foo
>  bar
>  baz
>end
>
> julia> foo = Foo(1,2)
> Foo(1,2)
>
> julia> foo.("bar")
> ERROR: type: getfield: expected Symbol, got ASCIIString
>
> julia> foo.(symbol("bar"))
> 1
>
>
I would ... swear that I had tried that too 
 

>
> The feature is likely to be removed rather than expanded.
>

Why? It brings a potentially very useful behavior.
Better still would be to have the (symbol("bar") be done automatically

 

>
>
> On Tue, Mar 25, 2014 at 1:36 PM, J Luis >wrote:
>
>>
>> This is a somewhat dubious feature borrowed from Matlab. I think we 
>>> should deprecate and then drop it.
>>>
>>
>> That furthermore does not work like the Matlab one ... but would be nice 
>> if it did
>>  
>>  
>>
>>>
>>>
>>> On Mon, Mar 24, 2014 at 11:01 PM, Sam L  wrote:
>>>
 After some experimentation, it looks like second way takes a symbol or 
 variable who's value is a symbol. 

 julia> type MyType; a::Int; end

 julia> x = MyType(3)
 MyType(3)

 julia> x.a
 3

 julia> x.(a)
 ERROR: a not defined

 julia> x.(:a)
 3

 julia> b = :a
 :a

 julia> x.(b)
 3


 On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:
>
> The doc of getfield says
>
> getfield(*value*, *name::Symbol*) 
>
> Extract a named field from a value of composite type. The syntax a.bcalls
> getfield(a, :b), and the syntax a.(b) calls getfield(a, b).
>
> but when I try the a.(b) variation, it errors (or it's me who errors?)
>
> julia> gmt_modules.write
> "?O"
>
> julia> gmt_modules.(write)
> ERROR: type: getfield: expected Symbol, got Function
>
>
>
>
>
>>>
>

Re: [julia-users] Re: Is a.(b) valid?

[Stefan Karpinski]

You just need to convert the string to a symbol first:

julia> type Foo
 bar
 baz
   end

julia> foo = Foo(1,2)
Foo(1,2)

julia> foo.("bar")
ERROR: type: getfield: expected Symbol, got ASCIIString

julia> foo.(symbol("bar"))
1


The feature is likely to be removed rather than expanded.


On Tue, Mar 25, 2014 at 1:36 PM, J Luis  wrote:

>
> This is a somewhat dubious feature borrowed from Matlab. I think we should
>> deprecate and then drop it.
>>
>
> That furthermore does not work like the Matlab one ... but would be nice
> if it did
>
>
>
>>
>>
>> On Mon, Mar 24, 2014 at 11:01 PM, Sam L  wrote:
>>
>>> After some experimentation, it looks like second way takes a symbol or
>>> variable who's value is a symbol.
>>>
>>> julia> type MyType; a::Int; end
>>>
>>> julia> x = MyType(3)
>>> MyType(3)
>>>
>>> julia> x.a
>>> 3
>>>
>>> julia> x.(a)
>>> ERROR: a not defined
>>>
>>> julia> x.(:a)
>>> 3
>>>
>>> julia> b = :a
>>> :a
>>>
>>> julia> x.(b)
>>> 3
>>>
>>>
>>> On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:

 The doc of getfield says

 getfield(*value*, *name::Symbol*)

 Extract a named field from a value of composite type. The syntax a.bcalls
 getfield(a, :b), and the syntax a.(b) calls getfield(a, b).

 but when I try the a.(b) variation, it errors (or it's me who errors?)

 julia> gmt_modules.write
 "?O"

 julia> gmt_modules.(write)
 ERROR: type: getfield: expected Symbol, got Function





>>

Re: [julia-users] Re: Is a.(b) valid?

[J Luis]

> This is a somewhat dubious feature borrowed from Matlab. I think we should 
> deprecate and then drop it.
>

That furthermore does not work like the Matlab one ... but would be nice if 
it did
 
 

>
>
> On Mon, Mar 24, 2014 at 11:01 PM, Sam L  >wrote:
>
>> After some experimentation, it looks like second way takes a symbol or 
>> variable who's value is a symbol. 
>>
>> julia> type MyType; a::Int; end
>>
>> julia> x = MyType(3)
>> MyType(3)
>>
>> julia> x.a
>> 3
>>
>> julia> x.(a)
>> ERROR: a not defined
>>
>> julia> x.(:a)
>> 3
>>
>> julia> b = :a
>> :a
>>
>> julia> x.(b)
>> 3
>>
>>
>> On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:
>>>
>>> The doc of getfield says
>>>
>>> getfield(*value*, *name::Symbol*) 
>>>
>>> Extract a named field from a value of composite type. The syntax a.bcalls
>>> getfield(a, :b), and the syntax a.(b) calls getfield(a, b).
>>>
>>> but when I try the a.(b) variation, it errors (or it's me who errors?)
>>>
>>> julia> gmt_modules.write
>>> "?O"
>>>
>>> julia> gmt_modules.(write)
>>> ERROR: type: getfield: expected Symbol, got Function
>>>
>>>
>>>
>>>
>>>
>

Re: [julia-users] Re: Is a.(b) valid?

[Stefan Karpinski]

This is a somewhat dubious feature borrowed from Matlab. I think we should
deprecate and then drop it.


On Mon, Mar 24, 2014 at 11:01 PM, Sam L  wrote:

> After some experimentation, it looks like second way takes a symbol or
> variable who's value is a symbol.
>
> julia> type MyType; a::Int; end
>
> julia> x = MyType(3)
> MyType(3)
>
> julia> x.a
> 3
>
> julia> x.(a)
> ERROR: a not defined
>
> julia> x.(:a)
> 3
>
> julia> b = :a
> :a
>
> julia> x.(b)
> 3
>
>
> On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:
>>
>> The doc of getfield says
>>
>> getfield(*value*, *name::Symbol*)
>>
>> Extract a named field from a value of composite type. The syntax a.bcalls
>> getfield(a, :b), and the syntax a.(b) calls getfield(a, b).
>>
>> but when I try the a.(b) variation, it errors (or it's me who errors?)
>>
>> julia> gmt_modules.write
>> "?O"
>>
>> julia> gmt_modules.(write)
>> ERROR: type: getfield: expected Symbol, got Function
>>
>>
>>
>>
>>

[julia-users] Re: Is a.(b) valid?

[J Luis]

Short answer - no

A bit longer one. I am reasonably experienced Matlab and C user and too 
often I find myself in the position 
"how-do-I-port-this-ML(and-sometimes-C)-solution-to-julia". Unfortunately, 
concepts that are not so familiar to me tend to be left behind to a second 
round, a part of it because their documentation is too short.

One aspect where we are really spoiled in Matlab is the documentation, 
where each function has a short (or not so short) usage example.
I understand perfectly that documentation is the least interesting part of 
a software development (I have my own guilts on this subject), but for a 
widespread adoption o Julia it will be fundamental that the manuals give 
more easy to digest information.

Anyway, thanks for all the help provided in this list (a non-negligible 
part of it could land in some sort of manual)

Joaquim

Terça-feira, 25 de Março de 2014 8:20:34 UTC, Andreas Lobinger escreveu:
>
> Have you though about to replace this with a Dict (associative array)? The 
> dynamic names for a field in a matlab struct is (btw: this is recent) seen 
> as a sort-of dict implementation.
>
>

[julia-users] Re: Is a.(b) valid?

[Andreas Lobinger]

Have you though about to replace this with a Dict (associative array)? The 
dynamic names for a field in a matlab struct is (btw: this is recent) seen 
as a sort-of dict implementation.

Re: [julia-users] Re: Is a.(b) valid?

[Jameson Nash]

dynamic names can be handy, but they are also quite slow.

symbol(string(nomes[1])) === nomes[1]


On Mon, Mar 24, 2014 at 11:13 PM, J Luis  wrote:
> Thanks
>
> So this means we cannot do the dynamic names as in Matlab (where the "b" is
> the member name)
>
> BTW, I needed to extract the member name as a string to compare with another
> string and the only way I got it done was with
>
> julia> nomes=names(MyType)
> 1-element Array{Symbol,1}:
>  :a
>
> julia> @sprintf("%s", nomes[1])
> "a"
>
>
> but don't know how to do it the other way around. Not that I need it now but
> Matlab dynamic names are quite handy.
>
> Terça-feira, 25 de Março de 2014 3:01:13 UTC, Sam L escreveu:
>>
>> After some experimentation, it looks like second way takes a symbol or
>> variable who's value is a symbol.
>>
>> julia> type MyType; a::Int; end
>>
>> julia> x = MyType(3)
>> MyType(3)
>>
>> julia> x.a
>> 3
>>
>> julia> x.(a)
>> ERROR: a not defined
>>
>> julia> x.(:a)
>> 3
>>
>> julia> b = :a
>> :a
>>
>> julia> x.(b)
>> 3
>>
>>
>> On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:
>>>
>>> The doc of getfield says
>>>
>>> getfield(value, name::Symbol)
>>>
>>> Extract a named field from a value of composite type. The syntax a.b
>>> calls
>>> getfield(a, :b), and the syntax a.(b) calls getfield(a, b).
>>>
>>>
>>> but when I try the a.(b) variation, it errors (or it's me who errors?)
>>>
>>> julia> gmt_modules.write
>>> "?O"
>>>
>>> julia> gmt_modules.(write)
>>> ERROR: type: getfield: expected Symbol, got Function
>>>
>>>
>>>
>>>
>

[julia-users] Re: Is a.(b) valid?

[J Luis]

Thanks 

So this means we cannot do the dynamic names as in Matlab (where the "b" is 
the member name)

BTW, I needed to extract the member name as a string to compare with 
another string and the only way I got it done was with

julia> nomes=names(MyType)
1-element Array{Symbol,1}:
 :a

julia> @sprintf("%s", nomes[1])
"a"


but don't know how to do it the other way around. Not that I need it now 
but Matlab dynamic names are quite handy.

Terça-feira, 25 de Março de 2014 3:01:13 UTC, Sam L escreveu:
>
> After some experimentation, it looks like second way takes a symbol or 
> variable who's value is a symbol. 
>
> julia> type MyType; a::Int; end
>
> julia> x = MyType(3)
> MyType(3)
>
> julia> x.a
> 3
>
> julia> x.(a)
> ERROR: a not defined
>
> julia> x.(:a)
> 3
>
> julia> b = :a
> :a
>
> julia> x.(b)
> 3
>
>
> On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:
>>
>> The doc of getfield says
>>
>> getfield(*value*, *name::Symbol*)
>>
>> Extract a named field from a value of composite type. The syntax a.bcalls
>> getfield(a, :b), and the syntax a.(b) calls getfield(a, b).
>>
>> but when I try the a.(b) variation, it errors (or it's me who errors?)
>>
>> julia> gmt_modules.write
>> "?O"
>>
>> julia> gmt_modules.(write)
>> ERROR: type: getfield: expected Symbol, got Function
>>
>>
>>
>>
>>

[julia-users] Re: Is a.(b) valid?

[Sam L]

After some experimentation, it looks like second way takes a symbol or 
variable who's value is a symbol. 

julia> type MyType; a::Int; end

julia> x = MyType(3)
MyType(3)

julia> x.a
3

julia> x.(a)
ERROR: a not defined

julia> x.(:a)
3

julia> b = :a
:a

julia> x.(b)
3


On Monday, March 24, 2014 7:46:38 PM UTC-7, J Luis wrote:
>
> The doc of getfield says
>
> getfield(*value*, *name::Symbol*)
>
> Extract a named field from a value of composite type. The syntax a.b calls
> getfield(a, :b), and the syntax a.(b) calls getfield(a, b).
>
> but when I try the a.(b) variation, it errors (or it's me who errors?)
>
> julia> gmt_modules.write
> "?O"
>
> julia> gmt_modules.(write)
> ERROR: type: getfield: expected Symbol, got Function
>
>
>
>
>