Redefining constraints

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Redefining constraints

Naelson Douglas
In Julia we can easily redefine a constraint in this way

julia> const a = 1
1

julia> const a = 2
WARNING: redefining constant a
2

With this all we get when changing a from 1 to 2 is a warning.
 It looks fine if we are interacting with the language via terminal, since otherwise we'd be "condemned" to use a = 1 for the entire session.

But the bad part here is when we have a source code file with some statement like:

#######-----MyCode.jl---------######

const a = 1
...
...
x = a + a
...
...
const a = 2
y = a*a

#####-----------------------#####

In this case (redefining the constraint inside a source file), we'd get the same warning, but I think in this case it should be an error instead of warning, now there's no longer the "condemnation" question and it would lead to some errors. If I want to have a constraint in my code and I want to change it, I don't need a constraint, I need a variable.

My idea is: when using include("MyCode.jl"), Julia should throw a redefinition error instead of a warning.


Thanks.

Naelson Douglas
Reply | Threaded
Open this post in threaded view
|

Re: Redefining constraints

Jameson Nash
If you were caught speeding in a rental car and the cop let you off with a warning, would you say, "I'm only trying out the car, so it's fine that the cop didn't condemn me. If it had been my own car, he should have thrown me in jail."

warning |ˈwôrniNG|
noun
a statement or event that indicates a possible or impending danger, problem, or other unpleasant situation
(courtesy of the New Oxford American Dictionary)


On Sat, Apr 9, 2016 at 11:53 AM Naelson Douglas <[hidden email]> wrote:
In Julia we can easily redefine a constraint in this way

julia> const a = 1
1

julia> const a = 2
WARNING: redefining constant a
2

With this all we get when changing a from 1 to 2 is a warning.
 It looks fine if we are interacting with the language via terminal, since otherwise we'd be "condemned" to use a = 1 for the entire session.

But the bad part here is when we have a source code file with some statement like:

#######-----MyCode.jl---------######

const a = 1
...
...
x = a + a
...
...
const a = 2
y = a*a

#####-----------------------#####

In this case (redefining the constraint inside a source file), we'd get the same warning, but I think in this case it should be an error instead of warning, now there's no longer the "condemnation" question and it would lead to some errors. If I want to have a constraint in my code and I want to change it, I don't need a constraint, I need a variable.

My idea is: when using include("MyCode.jl"), Julia should throw a redefinition error instead of a warning.


Thanks.


Naelson Douglas
Reply | Threaded
Open this post in threaded view
|

Re: Redefining constraints

Stefan Karpinski
Driving analogies aside, the reason it's not an error is that one often wants to reload files after changing code. Julia tries to allow you to do this whenever it can, which happens to be when the type of a constant doesn't change. Making this an error would force you to restart Julia any time you reload code that defines a constant.

On Sat, Apr 9, 2016 at 2:54 PM, Jameson Nash <[hidden email]> wrote:
If you were caught speeding in a rental car and the cop let you off with a warning, would you say, "I'm only trying out the car, so it's fine that the cop didn't condemn me. If it had been my own car, he should have thrown me in jail."

warning |ˈwôrniNG|
noun
a statement or event that indicates a possible or impending danger, problem, or other unpleasant situation
(courtesy of the New Oxford American Dictionary)


On Sat, Apr 9, 2016 at 11:53 AM Naelson Douglas <[hidden email]> wrote:
In Julia we can easily redefine a constraint in this way

julia> const a = 1
1

julia> const a = 2
WARNING: redefining constant a
2

With this all we get when changing a from 1 to 2 is a warning.
 It looks fine if we are interacting with the language via terminal, since otherwise we'd be "condemned" to use a = 1 for the entire session.

But the bad part here is when we have a source code file with some statement like:

#######-----MyCode.jl---------######

const a = 1
...
...
x = a + a
...
...
const a = 2
y = a*a

#####-----------------------#####

In this case (redefining the constraint inside a source file), we'd get the same warning, but I think in this case it should be an error instead of warning, now there's no longer the "condemnation" question and it would lead to some errors. If I want to have a constraint in my code and I want to change it, I don't need a constraint, I need a variable.

My idea is: when using include("MyCode.jl"), Julia should throw a redefinition error instead of a warning.


Thanks.


Naelson Douglas

Reply | Threaded
Open this post in threaded view
|

Re: Redefining constraints

Naelson Douglas
It's constant and not constraint. Sorry, sometimes my english fails. :)


@Jamerson
Yup. I got the meaning of warning.


@Stefen

Yep. I get the idea. But let-me make on more question: in the current implementation, what's the difference in using a const and a variable?
The ideia of constants is that we can bind the values in linking time, right? But if the value of the constant is dynamic, then its kinda impossible to link it. (correct me if I'm wrong)

Thanks.


Reply | Threaded
Open this post in threaded view
|

Re: Redefining constraints

Chris Foster
On Sun, Apr 10, 2016 at 8:23 AM, Naelson Douglas
<[hidden email]> wrote:
> Yep. I get the idea. But let-me make on more question: in the current
> implementation, what's the difference in using a const and a variable?
> The ideia of constants is that we can bind the values in linking time,
> right? But if the value of the constant is dynamic, then its kinda
> impossible to link it. (correct me if I'm wrong)

Basically, const is a promise to the compiler that you're not going to
later change the variable binding.  The compiler will assume it can
inline the values of any such bindings if it needs to.  For example:

julia> module A
       const a = 123
       foo() = a
       @code_native foo() # do this *before* redefining `a` to force compilation
       const a = 456
       bar() = a
       @code_native bar()
       end

# foo() has the value 123 inlined as an immediate value
        .text
Filename: none
Source line: 3
        pushq   %rbp
        movq    %rsp, %rbp
        movl    $123, %eax
Source line: 3
        popq    %rbp
        ret
WARNING: redefining constant a

# bar() has the value 456 inlined as an immediate value
       .text
Filename: none
Source line: 6
        pushq   %rbp
        movq    %rsp, %rbp
        movl    $456, %eax              # imm = 0x1C8
Source line: 6
        popq    %rbp
        ret

And to double check:

julia> A.foo()
123

julia> A.bar()
456


If you don't follow a promise to the compiler, things can act somewhat
inconsistently. It's a design decision as to whether this is an error
(premise: the compiler should save you from shooting yourself in the
foot at all costs) or a warning (premise: having the repl work in more
than trivial situations is too important to ignore.  premise2:
sometimes you know what you're doing and reaching into the guts of a
module to monkey patch something interactively lets you fix or
understand an otherwise intractable problem)


~Chris
Reply | Threaded
Open this post in threaded view
|

Re: Redefining constraints

Naelson Douglas
So it's all about a constant MEMORY binding and not VALUE binding.
In this case it all makes sense and happily I was wrong. :)

Thanks for your answer Chris. It help me a lot.
Reply | Threaded
Open this post in threaded view
|

Re: Redefining constraints

Yichao Yu
On Sat, Apr 9, 2016 at 10:17 PM, Naelson Douglas
<[hidden email]> wrote:
> So it's all about a constant MEMORY binding and not VALUE binding.
> In this case it all makes sense and happily I was wrong. :)

I'm not sure what you mean but the compiler is free to inline the
value of a const binding.

As others have already said, the reason for making this a warning is
to make REPL less annoy. You are right it is almost certainly a user
error if it is used outside REPL but disallowing that precisely is
hard and doesn't really worth doing since the warning should make you
worry enough and fix the issue anyway....

>
> Thanks for your answer Chris. It help me a lot.
Reply | Threaded
Open this post in threaded view
|

Re: Redefining constraints

Chris Foster
In reply to this post by Naelson Douglas
On Sun, Apr 10, 2016 at 12:17 PM, Naelson Douglas
<[hidden email]> wrote:
> So it's all about a constant MEMORY binding and not VALUE binding.
> In this case it all makes sense and happily I was wrong. :)

Kind of.  Binding to a name using `=` always has reference semantics
in julia, and const is a promise that the binding won't change.

However, julia doesn't promise anything about how the reference will
be implemented.  It may be an actual memory location, but if the type
is immutable the compiler has a lot of latitude to optimize and the
value may end up inlined as can be seen in the assembly above.

~Chris
Reply | Threaded
Open this post in threaded view
|

Re: Redefining constraints

Mauro
In reply to this post by Yichao Yu
Last, note that const forces a constant type:

julia> const a = 1
1

julia> a = 2
WARNING: redefining constant a
2

julia> a = 2.0
ERROR: invalid redefinition of constant a


On Sun, 2016-04-10 at 04:26, Yichao Yu <[hidden email]> wrote:

> On Sat, Apr 9, 2016 at 10:17 PM, Naelson Douglas
> <[hidden email]> wrote:
>> So it's all about a constant MEMORY binding and not VALUE binding.
>> In this case it all makes sense and happily I was wrong. :)
>
> I'm not sure what you mean but the compiler is free to inline the
> value of a const binding.
>
> As others have already said, the reason for making this a warning is
> to make REPL less annoy. You are right it is almost certainly a user
> error if it is used outside REPL but disallowing that precisely is
> hard and doesn't really worth doing since the warning should make you
> worry enough and fix the issue anyway....
>
>>
>> Thanks for your answer Chris. It help me a lot.