# File organization in Base, and modularity

**URL:** <https://discourse.julialang.org/t/file-organization-in-base-and-modularity/2019>\
**Category:** Internals & Design\
**Created:** [February 10, 2017, 6:39am UTC](https://discourse.julialang.org/t/file-organization-in-base-and-modularity/2019 "2017-02-10T06:39:15Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![andyferris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andyferris/32/235_2.png) [@andyferris](https://discourse.julialang.org/u/andyferris)\
**Post date:** [February 14, 2017, 12:24am UTC](https://discourse.julialang.org/t/file-organization-in-base-and-modularity/2019/4 "2017-02-14T00:24:52Z")

</div>

> BLAS.jl should be internally divided into … and generic/fallback implementations (which could hopefully eventually become fast enough that whether to include a vendor blas is just a configuration option).
> 
> It seems to me that all of linalg/matmul.jl should be part of BLAS.jl, as well as the BLAS-like parts of linalg/generic.jl.

Like Andreas said, I was suggesting to have “BLAS” as being wrappers for an external library that makes matrix multiplication _faster_. Not loading the the `BLAS` submodule shouldn’t mean generic matrix multiplication is impossible - I don’t see the upside of that.

(For example, it would be interesting to build Julia with less dependencies and still have generic code work, e.g. [this](https://discourse.julialang.org/t/julia-memory-overhead/1861). I do realize we don’t (yet) have generic replacements for everything in LAPACK, ARPACK and SuiteSparse, but that’s _not_ a reason not to have a modular system like that common in large systems of packages (`MathProgBase` is one example, but I’m not that familiar with it)).

---

_[View the full topic](https://discourse.julialang.org/t/file-organization-in-base-and-modularity/2019)._