Some nice-to-have syntax

Internals & Design
#1

Here’s two syntax features I think would be nice additions:

  1. allow newline before where, so I can nicely align my arguments:
function f(x::T, y::S)
         where T <: AbstractMatrix{El}
         where S <: AbstractVector{El}
         where El <: Number
    <implementation>
end
  1. A “Not Implemented” syntax like Perl has. In Perl, ... is a valid expression (!), and it raises a not-implemented error:
$ perl <<PERL
> if (0) {
>     print "hello, world!\n"
> } else {
>     ... # TODO
> }
> PERL
Unimplemented at - line 5.

If I find a spare afternoon, would this be worth my time?

3 Likes
#2

You can easily define a function to error

julia> ⋯() = error("Not implemented")
⋯ (generic function with 1 method)

julia> ⋯()
ERROR: Not implemented
Stacktrace:
 [1] ⋯() at ./none:1
 [2] top-level scope at none:0

Or perhaps the double dot

julia> ..() = error("Not implemented")
.. (generic function with 1 method)

julia> ..()
ERROR: Not implemented
Stacktrace:
 [1] ..() at ./none:1
 [2] top-level scope at none:0
#3

Note that you can already do

function f(x::T, y::S) where {E1 <: Number,                            
                              T <: AbstractMatrix{E1},                 
                              S <: AbstractVector{E1}}
end

while I agree that it’s a little hard to know that’s exactly what you need to do (you need to remember to put E1 first), I think it’s fairly nice syntax. Perhaps some more documentation or examples are in order.

I think it would be nice if there were a NotImplementedError <: ErrorException in base. It’s easy enough to implement your own, but I like the idea of standardizing it by putting it in Base. I can’t say I like the ... because I don’t find it at all obvious that that’s what that means, though I guess opinions will vary on that.

9 Likes
#4

Or have a @todo macro:

macro todo()
    :(error("not implemented"))
end

Allowing where on the following line would be nice.

9 Likes
#5

Yes, me too. I like the @todo macro as a nice alternative as well. (One thing I like about ... is that many people will write that in code snippets anyway. I found it pretty cool when it turned out to be copy-pastable and runnable in Perl.)

Is it at all possible to put new symbols in Base in the 1.x series, with backwards compatibility in mind?

I might give that a stab some time.

#6

Note that ... is not a new symbol. It is used for function varargs and splatting (e.g. f(x,y,rest...))

I agree with @ExpandingMan that this usage of ... could be pretty confusing. I think @todo would be better.

5 Likes
#7

+1 for where on a new line

2 Likes
#8

The multiline where syntax would be essential, I have much too long lines of code on many functions because of that issue.

Could such a change be backported to 1.0 for compatibility, if implemented?

#9

Nope. Features are not backported.

4 Likes
#10

The new line before where is really a good idea!

#11

I almost thought it was easy to add newline-before-where, except that now the parser chokes on this one here :joy:

I’ll see if I can easily fix this.

Unrelatedly, I just remembered a similar use case:

n = iseven(n)
  ? div(n, 2)
  : 3n + 1

or (according to taste)

n = iseven(n)
    ? div(n, 2)
    : 3n + 1

That needs a similar peek on the next line. Any opinions about that one?

#12

We defined it ourselves in YaoBase.jl （I mean NotImplementedError)

1 Like
#13

This one should just be written

n = (iseven(n)
     ? div(n, 2)
     : 3n + 1)
2 Likes
#14

Why?

#15

Because it already works and it’s not horrifically ambiguous.

Making it work without the parens would put even more syntactic special cases on ? and : making new uses for them even more difficult.

3 Likes
#16

Why a macro, not just a todo function?

4 Likes
#17

Seems like slightly better syntax. But sure, it could also be a function. A macro could probably print a somewhat better message too.

2 Likes