I would add that we generally strive to do the thing the user wants when parsing, even if it adds complexity to the parser. On the other hand, we depart pretty significantly from other dynamic languages like Perl and Ruby – and even some static ones like C and C++ – in that parsing requires no knowledge of the state of a program. In other words, things parse the same, regardless of what has gone before. This is notoriously violated in C by the typedef construct, which forces the parser to maintain a table of typedefs in order to parse the language correctly. Parsing Perl is undecidable because you have to actually execute the code to know what it means. Parsing Ruby is complex, but as far as I can recall, doesn't require executing code or maintaining any tables like C. So in a sense, Ruby, for all its complexity is still easier to parse than C or Perl. Julia is easier to parse than all of these.
On Sat, Jul 19, 2014 at 4:38 PM, Jake Bolewski <jakebolew...@gmail.com> wrote: > Parsing julia most definitely context sensitive. Have you looked at the > implementation of the parser? going to the source always resolves any > ambiguity and is the definitive reference as to why things are parsed the > way they are. If scheme is not your cup of tea you can always play around > with the julia parser written in Julia (search for JuliaParser.jl). Muck > around and break things, play with turning on / off context sensitivity and > see what happens. If you have a better way to resolve an ambiguity in the > language I'm sure everyone here would love to hear about it. > > From experience I would say the only thing that bugs me about parsing > julia is how we deal with .operators. For instance there are ugly hacks to > get around the ambiguity of importing these operators from base (ex. > Import Base.+, likewise with extending the methods of these operators ( > .+(args....) = something). requiring parenthesis around dot operators when > importing them or extending them would resolve this ambiguity.m That is one > concrete suggestion I can make. > > Sorry no, I don't think we will ever adopt a parser generator approach to > parsing the language. doing it by hand allows you to tweak the performance > of the parser and to potentially give better error messages. End users do > not care if we use a parser generator framework or not, so there is really > no practical benefit. This is why almost allpopular languages rely on hand > written parsers ( the only exception I can think of is Go but the syntax > was designed from the beginning to be easy to parse). >
