Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

things we should deprecate, 0.6 edition #19598

Closed
16 of 22 tasks
StefanKarpinski opened this issue Dec 14, 2016 · 60 comments
Closed
16 of 22 tasks

things we should deprecate, 0.6 edition #19598

StefanKarpinski opened this issue Dec 14, 2016 · 60 comments
Labels
deprecation This change introduces or involves a deprecation
Milestone

Comments

@StefanKarpinski
Copy link
Member

StefanKarpinski commented Dec 14, 2016

I'd like to collect a list of things that should be deprecated before 0.6 is released, even if we don't implement the corresponding feature until 1.0. Some examples I can think of:

Probably in 1.0 rather than 0.6:

@StefanKarpinski StefanKarpinski modified the milestones: o.6, 0.6.0 Dec 14, 2016
@tkelman
Copy link
Contributor

tkelman commented Dec 14, 2016

@nalimilan
Copy link
Member

nalimilan commented Dec 14, 2016

macro parsing of ~ if the stats package can come up with a @formula replacement in time

Should probably go into StatsModels now.

@ararslan
Copy link
Member

Regarding formulas, see JuliaStats/StatsModels.jl#3.

@Sacha0
Copy link
Member

Sacha0 commented Dec 14, 2016

Alongside @tkelman's mention of vectorized & and |, remaining vectorized methods for abs, abs2, imag, trunc, floor, ceil, mod, div, rem, clamp, and a number of hyperbolic trig functions should be deprecated. Likely vectorized big methods as well, and possibly (discussion ongoing) vectorized float, real, and (two-argument) complex methods. (I have stale pull requests open for most of those deprecations, blocked on whatever mark we set for completion of the sparse broadcast overhaul.) (edit: These are done, less those struck through.)

With devectorization complete, deprecation of expm, logm, sqrtm, and friends (i.e. matrix functions specially named due to former conflict with vectorized scalar functions) in favor of non-m equivalents might be worth considering. Best!

Edit: Also full. (I hope to see deprecating full through after completing the sparse map/broadcast overhaul (post 0.6).)

@andreasnoack
Copy link
Member

andreasnoack commented Dec 14, 2016

I'd also propose depreaction of sumabs, sumabs2, maxabs and minabs which are not necessary with fast function arguments.

Edit: done in #19616 – @StefanKarpinski

@simonbyrne
Copy link
Contributor

Various special functions, pending #4301/#8536

@simonbyrne
Copy link
Contributor

For strings, the decision was to define a codeunit(s::String, offset::Int) function for people who need access to bytes.

@StefanKarpinski
Copy link
Member Author

If Jeff's recent String experiment pans out, we'll do that; otherwise we rename the .data field.

@tkelman
Copy link
Contributor

tkelman commented Dec 15, 2016

@vtjnash
Copy link
Member

vtjnash commented Dec 16, 2016

If Jeff's recent String experiment pans out, we'll do that; otherwise we rename the .data field.

I think we said that Jeff's recent String experiment is expected to merge in the next few months, otherwise we don't spend any other effort on changing the representation. Probably by 1.0, we will need to have the infrastructure in place to handle Arrays more efficiently via an underlying Buffer type. At that time, we can delete the special case code for String and go back to having a .data field, by showing that it gives the same (or better) performance.

@JeffBezanson
Copy link
Member

Another candidate: produce and consume, in favor of channels.

@amitmurthy
Copy link
Contributor

Another candidate: produce and consume, in favor of channels.

#17699

@blakejohnson
Copy link
Contributor

With devectorization complete, deprecation of expm, logm, sqrtm, and friends (i.e. matrix functions specially named due to former conflict with vectorized scalar functions) in favor of non-m equivalents might be worth considering.

I agree, but these need to wait one release so that we can suggest the alternate spelling without the m.

@ararslan
Copy link
Member

The manual has claimed the Array(T, dims) syntax to be "deprecated" for a while now, but no deprecation warning is emitted. If we really want that syntax to be deprecated, we should formally deprecate it.

@goszlanyi
Copy link

goszlanyi commented Dec 18, 2016

What was wrong with Array(T,dims)?
It was concise, easy to remember and similar to zeros(T,dims) and ones(T,dims).
Could you point to the issue where it happened, please.

@ararslan
Copy link
Member

What was wrong with Array(T,dims)?

It's not a proper type constructor; Array is a parametric type, so it should be constructed with a type parameter.

Could you point to the issue where it happened, please.

Jeff added the text in this commit: 23a6995

@StefanKarpinski
Copy link
Member Author

StefanKarpinski commented Jan 2, 2017

Ok, as far as I can tell the remaining items to deprecate are:

[List moved to top comment]

Everything else is either already deprecated or has a fresh PR pending.

@mbauman
Copy link
Member

mbauman commented Jan 3, 2017

partial linear indexing – any chance of this, @mbauman?

I can definitely deprecate it. I'm not sure I'll be able to resolve all the deprecations in a timely manner, though. Right now it's blocked on #18457. Once that is merged I can push a deprecation branch and we can crowd-source the deprecation fixes.

@ararslan
Copy link
Member

ararslan commented Jan 3, 2017

~ macro syntax – how do we do this?

This is what @tkelman suggested for that:

maybe Base could keep ~ parsing as a macro but always throwing a depwarn? Looks like this may not change in Base for 0.6, but if packages can be made ready then maybe we hard change the parsing during 1.0-dev and packages might not notice if they've transitioned to this?

That would be the least immediately-breaking course of action, I would think. Once we do stop parsing ~ as a macro, we just have to make sure it still parses as an infix call with the same precedence.

@simonbyrne
Copy link
Contributor

simonbyrne commented Jan 3, 2017

@JeffBezanson
Copy link
Member

JeffBezanson commented Jan 3, 2017

Also:

  • "Inner constructor" syntax. To be specific, the following constructor:
type Foo{T}
    x
    Foo(x) = new(x)
end

currently gets rewritten to

    (::Type{Foo{T}}){T}(x) = new{T}(x)

which is bad, because the definition looks like it defines Foo(x) but it doesn't.

  • Static parameter syntax. The above constructor should instead be written as
    Foo{T}(x) where T<:Any = new{T}(x)   # or possibly just `new(x)`

These require #18457.

@simonbyrne
Copy link
Contributor

There are also some changes to LibGit2 we should make before 1.0 (#19839), but I'm not sure if I'll have time to get to them before then.

@pabloferz
Copy link
Contributor

pabloferz commented Jan 3, 2017

I'd add

@quinnj
Copy link
Member

quinnj commented Jan 25, 2017

@nalimilan ^?

@StefanKarpinski
Copy link
Member Author

Can I have a link to a PR for the DataFrames ~ change so we can track it from here more easily?

@StefanKarpinski
Copy link
Member Author

I've reorganized this issue so that all the todos are in the top comment. A few comments:

  • @nalimilan (or anyone who knows): if you could fill in the relevant issue/PR links for the ~-related issues in the top comment, that would be helpful.

  • anyone: a PR in this repo changing ~ into an infix operator can be done in parallel and makes a pretty solid up-for-grabs project for someone wanting to hack on the parser a bit.

  • @timholy: differentiating the two meanings of one doesn't involve any deprecation afaict – we can just introduce a new function and people can start using it.

  • @JeffBezanson: are we realistically still going to deprecate inner constructor syntax and static parameter syntax in this release? If so cool, but obviously should happen soon.

  • @musm, @simonbyrne: what's the status of moving "various special functions" out of base and deprecating them? Is that realistically still going to happen in this release?

  • @Sacha0: is the full thing still plausible in this release?

If the answer to any of the above is "no", that's ok, just want to update the list so we know what we're still waiting on.

@nalimilan
Copy link
Member

@ararslan is the one to ask regarding the ~ changes, but at least the needed changes have been merged in StatsModels (JuliaStats/StatsModels.jl#9, I've added the link to the description). We still need to make DataFrames use that, though.

@StefanKarpinski
Copy link
Member Author

Now that the StatsModels change has happened (thanks, @ararslan!), I don't think the other two changes need to happen in order since they're about tagging new versions and getting the dependencies right. So the next action item there seems to be a PR to change ~ to an operator.

@timholy
Copy link
Member

timholy commented Jan 26, 2017

Yes, I agree that the changes for one are easy (docstring and adding a new function). Fixing base can come later.

@stevengj
Copy link
Member

stevengj commented Jan 26, 2017

I actually started on a patch for one. Making Base dimensionally correct requires a big effort

@stevengj
Copy link
Member

See #20268.

@mbauman
Copy link
Member

mbauman commented Jan 27, 2017

Is it possible to deprecate using _ as an rvalue?

@StefanKarpinski
Copy link
Member Author

Good call, @mbauman – need to do that now in order to use it for discarding values in 1.0.

@amitmurthy
Copy link
Contributor

Also

@ararslan
Copy link
Member

A few FYIs from me:

Special functions: I've been working on moving special functions out of Base. From a package standpoint it's nearly there, but from a modification to Base standpoint there's still a fair bit of work to be done. In particular, to remove the dependency on openspecfun, we'll need to reimplement rem2pi in pure Julia, which requires double-double arithmetic. Unless we can extend and use Base.TwicePrecision for this, we need a solid double-double arithmetic implementation in Base. I think it's unlikely that this will happen for 0.6.

FFTW: As another data point, I've also been working on moving FFTW into a package. That too is going well, though there is still quite a bit of work to be done in moving from makefiles to BinDeps. Similarly unlikely to make it into 0.6.

@StefanKarpinski
Copy link
Member Author

As a temporary solution, could we just copy-pasta the one function you need from openspecfun into libjulia for now, with the longer term plan of reimplementing it in pure Julia?

@ararslan
Copy link
Member

I'm cool with that.

@JeffBezanson
Copy link
Member

How about moving SharedArrays to a package?

@ararslan
Copy link
Member

ararslan commented Feb 1, 2017

Hm, SharedArrays seem pretty convenient for the parallel facilities we provide out of the box. If anything I would suggest that sparse arrays go first.

@JeffBezanson
Copy link
Member

I think SharedArrays are pretty limited and difficult to use. They are not used anywhere in Base itself and SharedArrays is very self-contained. Of course sparse should be moved too, but I have a sense it will be more difficult. It has binary dependencies for example.

@ararslan
Copy link
Member

ararslan commented Feb 1, 2017

Yeah, makes sense. Perhaps JuliaParallel could adopt a SharedArrays.jl package. @andreasnoack?

@ararslan
Copy link
Member

ararslan commented Feb 3, 2017

Special functions are on their way out! See #20427

@PallHaraldsson
Copy link
Contributor

PallHaraldsson commented Feb 3, 2017

"the elementwise meaning of | and & given we're about to have .| and .& #19791"

[EDIT: Made question clearer, I think..:] Does #19791 mean we already disallow overloading | and & ? I think that should be done; added to the list of deprecations if not already done.

@StefanKarpinski
Copy link
Member Author

Does this that we can disallow overloading | and & ? I think it should be added to the list of deprecation if not already done.

Apropos of what?

@JeffBezanson
Copy link
Member

I propose closing this. We can still entertain deprecation PRs as they are posted, but I think we're done actively seeking deprecations for 0.6.

@StefanKarpinski
Copy link
Member Author

Sure, I think this has served its purpose now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecation This change introduces or involves a deprecation
Projects
None yet
Development

No branches or pull requests