REPL Environment

Hello!

There is only a command for total refresh, or restart, to make it possible to create a class with different variables in Julia.

Mathematically, it would help to have such command:
"Store “Package1"”

To have Julia replace the package names with “Package1”, so if I created a Class named “struct1”, I could access it with “Package1.struct1” and none of my functions would see the difference.

Tambet

I’m not certain I understand what you’re asking, but you can do this:

julia> module M
       struct A
           x::Int
       end
       getx(a::A) = a.x
       end
Main.M

julia> a = M.A(3)
Main.M.A(3)

julia> M.getx(a)
3

julia> module M
       struct A
           x::Int
           y::Float32
       end
       getx(a::A) = a.x
       end
WARNING: replacing module M.
Main.M

julia> a = M.A(3, 1.0f0)
Main.M.A(3, 1.0f0)

julia> M.getx(a)
3

It’s just that if you bring any of M’s internals into Main, then you need a new Main (which we can’t currently do). Likewise, you can’t use M in other modules and expect the replacement to automatically work. But as long as you have only independent modules, and always qualify each access to their internals, then you can do what you seem to be asking.

3 Likes

Well, this solved for me a few related things, but I better answer to your first line of what I’m asking:

  • Imagine I have my classes and methods, and I want to keep them first-class cityzens.
  • I enjoy my environment and I do not want to restart Julia, I want to keep my variables going.

So, it is clear that if you change some of the class variables (I think Class is my design pattern), you would run ambigious with the functions and classes you defined, thus, you need to restart the REPL environment. For me it’s like cancelling my discussion, which I don’t like philosophically - for Julia it’s repeating all the calculations in the middle.

Then, your answer - which seems to be to the point:

It’s just that if you bring any of M 's internals into Main, then you need a new Main (which we can’t currently do). Likewise, you can’t use M in other modules and expect the replacement to automatically work. But as long as you have only independent modules, and always qualify each access to their internals, then you can do what you seem to be asking.

Let’s say you have some internal name for module Main (let’s say it’s Env), so, things use this internally. Some of the functions use the variables directly, others take input. So let’s take your example;

Let’s imagine I created struct A with x::Int and getter getx for x; I made this directly to the Env (Main), thus I cannot create a new field y::Float32 any more.

Now let’s imagine I also created a function “duplicate(a::Int)”, which takes A as input, and returns a new A. Then, when I add a field “y”, I create two generic functions, “duplicate(a::Int)::A” and “duplicate(a::Int, y::Float32)” (I think I would check, inside duplicate, whether it has this field, or analyze carefully, what is the current task, but these functions definitely work).

Now, which is my desired method, is
Store M
, which would take Main, including struct A, and move all the objects into module M; then it would remove them from Main. Thus, now I have Main.M.A. The opposite I would call “Load M”, which would move it back - but Store M is already a very complete function as well, because it removes a lots of obstacles.

Now, let’s say I define a function loader:
loader(a::M.A)::A = duplicate(a, 0.0)

I create updated struct A with x::Int and y::Float32, then I am capable of copying the contents of old A into new struct.

If I used “Main.M” istead of M inside my functions, it should use a new Main.