Tim,
in your implementation you are assuming all possible types for x implement
some operation performed inside the 'no do something with x' comment. Just
making this assumption explicit allows solving the problem in a type-stable
manner. Consider the following:
alias NumberArray union(Array{Int64,1}, etc. could use a macro to iterate
over Number subtypes, or be defined in Base.
function read_x_in_files(filenames)
x::Numberrray
for fn in filenames
read!(x, fn, "x")
# now do something with x
end
end
read_x_in_files(("file1.jld", "file2.jld"))
The above solution is just as fast (or faster) than the type-unstable one,
while being type stable, statically checkable before compilation. If the
type of x actually doesn;t support any needed opertaion the runtime error
would be raised in the 'read!' call. In the type-stable implementation it
could be raised in the exact place where you are trying to use the
unsupported operation, this could be anywhere inside the function. Here you
have a version that handles all possible error at runtime:
function read_x_in_files(filenames)
x::Numberrray
for fn in filenames
try
read!(x, fn, "x")
catch typeerror
message("skipping file "*fn*" because it contains an
incompatible type")
continue
end
# now do something with x
end
end
Doing the same today is harder. Another solultion would be to just keep it
type unstable inside a global scoped macro instead of a function, or inside
a function tagged as type unstable.
Mike,
What is so special about Markdown.jl? I know of Markdown parsers
implemented in statically typed languages (all 100% type stable) which are
small, efficient and flexible. See for e.g.
https://github.com/mfp/ocsiblog/blob/more-markdown-compat/simple_markup.ml
which uses ~250 LOCs for parsing and another ~50 for rendering to HTML. Its
said to be faster than discount which is written in C. Also how compliant
is the Markdown.jl implementation? There are many shortcuts you can do to
increase performance and code size/simplicity vs fully correct behavior. I
know of a few fast parsers which seem type stable, for e.g. Python mistune,
here: http://mistune.readthedocs.org/en/latest/
Anyway, the fastest Markdown must be sundown? (what github uses is based on
this one) its fully compatible, and type stable, and its 2K lines but in C.
I could simply traslate one of those, or even your implementation. I did
skimmed it coarsely but didn't find any obvious type instabilities
anyway... these can be hard to find even using tools
Now I guess I'll just conclude my point like this:
Type instability isn't really about speed. It's about reliably being able
to modify your program when it gets bigger. At work (a corporate one) I was
once promoting the use of Python, and I was always demonstrating how it is
fast enough. I presented Numba, Cython, IO bound applications, etc. It took
me a long time to understand that what people were really looking for is
type-checks. its like an always sync'd documentation. It enables efficient
refactoring, it compliments testing.
I don't like the terms 'dynamic' and 'static' to describe languages. I much
prefer 'interactive' and 'stable typed'. These seem more orthogonal
concepts. In fact stable typed languages could still be interactive, and
please don't think they are not flexible. We still have multiple dispatch,
macros, eval at global scope, etc.
I think Julia is very good just as it is now, and it allows for many static
checks to be performed, at least way more than other "dynamic" (or
"interactive") languages) like Python allow.
Just please lets keep type instability to a minimum within the language and
standard library. Lets also actively encourage type stability, all within
the reasonable of course :) Can we all agree on this?
