I decided that I was actually fairly demanding in what I want from a language, and I think most others are also. What I want , anyway, is not only to be informed with a descriptive error message, but to be informed at a certain time, e.g., an early pass, pre-runtime. For example,
if I type:
Blockquote
abstract type abstractparentaltype end
julia> struct mystruct abstractparentaltype **
** x
** end**
julia> mystruct(19) ERROR: MethodError: no method matching mystruct(::Int64) The type mystruct exists, but no method is defined for this combination of argument types when trying to construct it.
Closest candidates are:
** mystruct(::Any, ::Any)**
** @ Main REPL[27]:1**
I get an error message alright, but one that does not help (me) solve what is going on. I would much rather see (before the program is run). a message like:
Improving error messages is a very long-tail sort of problem, but something we care enough about to have a dedicated label on the issue tracker: GitHub Ā· Where software is built
Having concrete examples where things can be better is useful ā and while improving them can sometimes be tricky, itās a great way to get involved!
yes,
struct A B
C
end is legal,
but
struct A B
C D is illegal
I think it would involve a combination of knowing the current run time information (error)
combined with the text of the program then you could deduce the answer.
OR
if you made illegal
struct A B
end
forcing
struct A
B
end
or
struct A <:B
C
end
that would work also.
given that struct A <: B
C D
end
does not work I was surprised that
struct A B end
works
so the rule is
You can have 0 or 1 names after the name of the struct and then on lines after that you can only have 1 name on a line by itself.
Not a nice rule.
should be
after the name of the struct you can have ā<: abstract nameā
or you can have
<< nothing>>
Itās weird that struct A B end is allowed but not struct A B C end. I guess the former is āniceā for 1-field structs (although a semicolon is hardly imposing)⦠but then why wasnāt this pattern good enough for n-field structs? Maybe it was never a deliberate choice and merely emerged from more generic parser rules.
I expect disallowing struct A B end (instead requiring struct A; B end) wouldnāt be controversial except that itād be breaking. Breaking changes have an extremely high barrier to integration, so I expect weāre stuck with this.
All this said, itās legal syntax (and arbitrarily distant from the MethodError thrown) so I think itād be tough to offer a āhelpfulā tip in this case.
Honestly, I donāt even bother trying to read messages from users that donāt bother to format their posts. You have been advised above to format the them with the triple back ticks.
I donāt think clarifying edge cases of ambiguous syntax specifications is ābreakingā. It would be breaking only if the documentation explicitly mentioned the old syntax
just thought of a near-trivial way to solve this and perhaps many other problems. The error message Julia spit out says
Blockquote
struct son abstractparent
field1
end
julia> son(3)
ERROR: MethodError: no method matching son(::Int64)
The type son exists, but no method is defined for this combination of argument types when trying to construct it.
Closest candidates are:
son(::Any,::Any)
@ Main REPL[2]:1
Blockquote
if it added the field names I think it would be near-trivial to debugā¦
so the eror message should look like this:
Blockquote
struct son abstractparent
field1
end
julia> son(3)
ERROR: MethodError: no method matching son(::Int64)
The type son exists, but no method is defined for this combination of argument types when trying to construct it.
Closest candidates are:
son(abstractparent::Any, field1::Any)
@ Main REPL[2]:1
struct son abstractparent
field1
end
julia> son(3)
ERROR: MethodError: no method matching son(::Int64)
The type son exists, but no method is defined for this combination of argument types when trying to construct it.
Closest candidates are:
son(abstractparent::Any, field1::Any)
@ Main REPL[2]:1
field1
end
that would tell you that it is getting confused about what the field names in the type are and that might lead you to the missing <:
@Tigerbyte you need to spend time and energy in formatting your posts and making sure they are readable.
You can edit your posts after theyāve been posted. Thereās a friendly editor interface to help you along the way if you donāt feel like using markdown; use the bar above the post.
when I click on the double quotes it puts the line in my file:
backquote
I am using this it just clearly is not having the desired effect. the post looks formatted to me
line breaks are in the right places, but no colors or bold. so Iām just doin it wrong somehow.
I do a backquote at the end of the thing I want to highlight or not ? I added one.
so I have one before and after the error message.
field1
end
julia> son(3)
ERROR: MethodError: no method matching son(::Int64)
The type `son` exists, but no method is defined for this combination of argument types when trying to construct it.
The syntax ambiguity would be arguable if Julia generally had more rigid rules about newlines, but there isnāt, and we can mostly space out one-liners with unpredictable exceptions e.g. let header, catch without a variable name, and struct fields after the first one. Adding narrower rules would be breaking, so this would have to be left to a v2 that probably wonāt come. A v2 could be nice for simplifying the syntax and thus parsing e.g. shortening function and not having 3 definition syntaxes with various parsing issues, and ; isnāt so bad as a substitute for spaces if there is a rule mandating newlines in the v2 documentation.