Not saying it's impossible, but these might make interesting reading:
https://github.com/timholy/HDF5.jl/issues/88
https://github.com/timholy/HDF5.jl/issues/83
https://github.com/timholy/HDF5.jl/issues/37
If I have "file1.jld" and "file2.jld", both containing the variable "x" but the
types are different, what exactly does the implementation of
function read_x_in_files(filenames)
for fn in filenames
x = read(fn, "x")
# now do something with x
end
end
read_x_in_files(("file1.jld", "file2.jld"))
look like if I'm not allowed to have type instability?
--Tim
On Saturday, January 03, 2015 08:02:51 AM Tobias Knopp wrote:
> I cannot judge on your proposal as I have not much experience with macros
> (nor with staged functions). Jameson surely can because he has a clear
> opinion when to use macros and when not.
>
> I just wanted to make clear that defining the type can be a serious issue.
>
> Further I don't really see whats wrong with the following
>
> function a()
> data = read_data_from_file() # I am highly type unstable
> do_some_hard_computation!(data) # I am type stable
> end
>
> What would I gain if the function a would be typestable. The hard work is
> done in the inner function.
>
> Where you absolutely have a point is that it is currently hard to be sure
> if the inner function is type stable.
> Maybe it would be cool if one could annotated functions to be stable and
> raise an error if not?
>
> Cheers
>
> Tobi
>
> Am Samstag, 3. Januar 2015 16:23:22 UTC+1 schrieb Ariel Keselman:
> > But using a function for this is wrong because macros allow you to load
> > the vector at runtime w/o specifying types and without inner scope
> > type-instability. So why insisting using a function instead of a macro?
> > The
> > only scenario I can think of is if the name of the file is only known at
> > runtime and only inside some type-stable inner scope. But then some
> > type-stable macro could help getting rid of the mess. I just don't see
> > this
> > mess happening in julia where you can use staged functions and macros; The
> > solution would look much different than in C++. It could be coded as some
> > DSL in a library which only exposes a nice API where you list the expected
> > types and structure and that's it. Not a single 'if' would leak ;)
> >
> > There are no free lunches of course, and yes, you could run into some mess
> > but that seems would rarely happen. I would argue taht un that case no
> > other language either can help you (they cant help to get this both fast
> > clean) -- Julia, that's nothing to be ashemed of ;)
> >
> > Now if macros are somehow too constrained for such uses we could have a
> > tag for functions as "type-unstable" in a form that prevents the type
> > instability from leaking outside, but of course I'm looking for solutions
> > within the current Julia state
