I just noticed a bug in my earlier model
f=: g: f.
should have been
f=: g f.
(no colon after the g).
But students go on to other things - jobs, professorships, etc.. So
Julia has potential, even if currently its only value is as a model
for how things can be implemented.
(I'm not going to go out looking for a job programming in Julia though
- if nothing else, I don't have the background.)
Meanwhile, reading your two links, it sounds like there's a fair bit
of uncertainty about what they would want to do for this case (and
that they resolve the name the first time the containing definition is
executed, so my J model was not exact). And, also, that they're
building on llvm (http://llvm.org/) which apparently does a lot of the
heavy lifting.
Here's a model, in J, of how I currently think this "misfeature" works:
defn=:2 :0
(m)=:(m;<v`'') & firstUse
i.0 0
)
firstUse=:4 :0
'name body'=: x
((name)=: body jit) y
)
jit=:1 :0
(13 :m) f.
)
g''
9
'f' defn 'g y'
f''
9
'g' defn '20'
g''
20
f''
9
More specifically:
'f' defn 'g y'
f
('f';'g y')&firstUse
f''
20
f
20"_
In other words, the definition of a defined function changes the first
time it gets used. This is a feature of a "just in time compiler", and
changing it requires a whole new level of abstraction.
I'd have to parse each function definition twice, once to get
candidate dependencies and again during jit. And if these are
independent parsers I wind up with edge cases where they behave
differently. Meanwhile, the existence of jit with a read/eval/print
loop suggests that there will be edge cases. The language itself does
not constrain if or when the jit happens, and the timing of the jit
will have a huge impact on what a function means, if you are
redefining the words that a definition refers to.
So I can easily imagine why the language designers decided to leave it as it is.
Thanks,
--
Raul
On Tue, Feb 4, 2014 at 6:08 PM, Scott Locklin <[email protected]> wrote:
> Raul:
>
>>If it is a bug, the resolution would probably be to retain both
>>the original definition and the machine implementation and to also set
>>up a dependency so that whenever g gets update f gets rebuilt.
>
> As far as I can tell, it is a bug.
> It's
> been logged as an issue for at least two years. The response from one
> of the developers does not inspire a great deal of confidence: "I was
> hoping nobody would notice this..."
>
> https://github.com/JuliaLang/julia/issues/265
> People keep logging it too:
> https://github.com/JuliaLang/julia/issues/5308
>
> I
> realize this is coming from someone who has never done anything like
> rolling his own language. If I'm wrong, and there is a reason for Julia
> to work this way, I'm happy to eat my words. If I'm right,
> and Julia is some sort of half baked student project, it is incredibly
> irresponsible of the Julia team to be thumping the tub that their doodad
> is the future. Mind you, I use R in my day to day work, and it is sort
> of inherently problematic as a language, but I figure such issues should
> be faced up to.
>
> -Scott
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
