This is a bit of a rant against "do-everything" packages like this:
A/ "dynamic.jl" should be broken out as it's own package "Dynamic" as it's only export @dynamic is not used in Lazy and those who might have a use for it shouldn't need to add all the other features of Lazy.
B/ "tail.jl" should be broken out as its own package "TailCallOptimization", as @rec is only used four places in Lazy: by dorun in "lazy.jl", and by reduce, any, and all in "liblazy.jl"; all of these can easily just use conventional for/while loops, which is what the macro does anyway; the trampolining macro @bounce isn't used at all. Those who might have a use for these, such as for style reasons in wishing to write loops that appear "functionally" as recursive functions using @rec or full (slower) trampolined recursion using @bounce shouldn't need to add all the other features of Lazy.
C/ Although somewhat convenient in particular for the primes example, the use of the @>> macro requires casual users to have to look into what it means in order to understand the example, and the example is just as clear if anonymous functions and the existing pipeline operator |> are used, which is essentially what the macro does. This macro is also used in constantly, repeatedly, last, walk, any, and all in "liblazy.jl", where they can easily be replaced by what they mean with actually less just-as-easily-understood code than using it. The only other macro used is the @with macro in the partition and partitionby functions defined in "liblazy.jl" file, and is one of the few macros created in this package actually tested in "runtest.jl"; these use cases are just as clear if the conventional let/end block is used as the macro expands to. Therefore, I recommend that "macros.jl" be converted into its own package "UtilityMacros" to be more easily accessible by those who have a true need for them and to not clutter this Lazy package.
These simplifications are all the the name of good coding practice in not making packages too "bulky" and also in good coding style in not using macros unless they contribute something to clarity or brevity of code..
This is a bit of a rant against "do-everything" packages like this:
A/ "dynamic.jl" should be broken out as it's own package "Dynamic" as it's only export
@dynamicis not used inLazyand those who might have a use for it shouldn't need to add all the other features ofLazy.B/ "tail.jl" should be broken out as its own package "TailCallOptimization", as
@recis only used four places inLazy: bydorunin "lazy.jl", and byreduce,any, andallin "liblazy.jl"; all of these can easily just use conventionalfor/whileloops, which is what the macro does anyway; the trampolining macro@bounceisn't used at all. Those who might have a use for these, such as for style reasons in wishing to write loops that appear "functionally" as recursive functions using@recor full (slower) trampolined recursion using@bounceshouldn't need to add all the other features ofLazy.C/ Although somewhat convenient in particular for the
primesexample, the use of the@>>macro requires casual users to have to look into what it means in order to understand the example, and the example is just as clear if anonymous functions and the existing pipeline operator|>are used, which is essentially what the macro does. This macro is also used inconstantly,repeatedly,last,walk,any, andallin "liblazy.jl", where they can easily be replaced by what they mean with actually less just-as-easily-understood code than using it. The only other macro used is the@withmacro in thepartitionandpartitionbyfunctions defined in "liblazy.jl" file, and is one of the few macros created in this package actually tested in "runtest.jl"; these use cases are just as clear if the conventionallet/endblock is used as the macro expands to. Therefore, I recommend that "macros.jl" be converted into its own package "UtilityMacros" to be more easily accessible by those who have a true need for them and to not clutter thisLazypackage.These simplifications are all the the name of good coding practice in not making packages too "bulky" and also in good coding style in not using macros unless they contribute something to clarity or brevity of code..