parse of string followed by number turned into @doc ?

[Michael Francis]

Julia 0.4 rc4 

I get the following unexpected (to me) behavior - 

julia> parse( "\"hello\"\n3.142" )

:(@doc "hello" 3.142)

is this intentional ? 

[Yichao Yu]

Yes, it is. A void string followedby anything is a doc.

>

[Michael Hatherly]

If you want to disable the automatic @doc then you can append a ; to the string or nest the expressions in a begin ... end block:

"hello";
3.142

begin
    "hello"
    3.142
end

— Mike

​

[Isaiah Norton]

I agree with MDC Francis that this is kind of odd. Is it common to doc arbitrary numbers? Supporting this isnt necessary to doc MathConsts...

(it also didn't seem to work properly for ints or floats when I tried -- the doc was added to meta, but help didn't seem to find it).

[Michael Hatherly]

Is it common to doc arbitrary numbers?

I can’t see much use for documenting things like that either. We could either throw an error in @doc if you try to document a number or change the parser to ignore cases such as that. I’d suspect it would be simpler to fix up @doc rather than the parser.

— Mike

​

[Scott Jones]

Since parse(val::AbstractString) is really for parsing *expressions*, this does seem correct behavior, although a bit surprising.

However, after investigating this, I think parse is not correctly documented. The documentation states that:

help?> parse
search: parse parseip parseint parsefloat ParseError sparse sparsevec
  parse(str, start; greedy=true, raise=true)
  Parse the expression string and return an expression (which could later be
  passed to eval for execution). start is the index of the first character to
  start parsing. If greedy is true (default), parse will try to consume as
  much input as it can; otherwise, it will stop as soon as it has parsed a
  valid expression. Incomplete but otherwise syntactically valid expressions
  will return Expr(:incomplete, "(error message)"). If raise is true
  (default), syntax errors other than incomplete expressions will raise an
  error. If raise is false, parse will return an expression that will raise an
  error upon evaluation.

However, this form does not return an expression, it always returns a tuple, with the expression as the first part, and the position in the string where it stopped parsing as the second part.

[Stefan Karpinski]

While it's a bit odd to document numbers, making the criteria for whether something is a doc string or not as simple as possible seems like it may be a good thing, even if this particular instance of the syntax isn't terribly useful.

[Michael Francis]

Coming back to this -- this appears to cause inconsistencies - It is not so much that that you can doc a float, but more that the behavior is surprising. 

julia> "hello" 2.3
  hello


julia> "hello" (x)->x+1


WARNING: deprecated syntax "hello (".
Use "hello(" instead.
ERROR: syntax: ""hello"(x)" is not a valid function argument name


julia> "hello" z() = 1
z (generic function with 1 method)


julia> "hello" "world"
  hello


julia> "hello" "world" "again"
ERROR: syntax: extra token """ after end of expression


julia> "hello" type foo end


julia>


julia> function bar()
       "hello" 1.23
ERROR: syntax: extra token "1.23" after end of expression

julia> "hello" x = 2

  hello

[Tony Kelman]

Are you on master? I believe we recently merged a PR by Michael Hatherly that got rid of documenting a string. Any remaining inconsistencies woukd probably be worth an issue.