_tef
No user record in our sample, but _tef has activity below (stories or comments). Likely we have partial data — the full bulk-load will fill profiles in.
No user record in our sample, but _tef has activity below (stories or comments). Likely we have partial data — the full bulk-load will fill profiles in.
Related paper: Context threading http://www.cs.toronto.edu/syslab/pubs/demkea_context.ps The gist is you can structure your interpreter to improve branch prediction by keeping your vm & hardware in similar states.
Alternatively, the people who wax lyrical for 60 or so pages don't understand much either, and are compelled to pad out their document. I remember seeing this a while ago, but I didn't pay much attention to it then,…
it's nice to see a larger company not being so terrible :-)
Because depression doesn't work that way. It isn't a general feeling of malaise, it's somewhat a lack of positive value on everything (ish). It is a lack of momentum and a heavy inertia to stay miserable and avoid…
"you don't have to be mad to work here but ...." i've found smaller companies are much more tolerant & flexible with nutters (like me). there seems to be more focus on results than politics. in larger places I've…
one of two videos has a download link for me. one uploaded in 2008 has a link but not the one from 2006
prolog is an interesting take on programming and by comparison, the style in which you write code is still significantly different to approaches in other languages. sadly, most people when taught barely get past the…
Art of prolog makes an excellent first book, and the Craft complements it well with seasoned advice on elegant and efficient prolog.
As much as I agree with the title I find the contents of the article misleading. It is almost as if prolog didn't make him a better programmer, given the idea that prolog 'returns values' or uses 'method calls' is 'not…
prolog is actually impure logic language, and given the general lack of HOF i'd be reticent in labelling it functional. it's a declarative language though, and the model you have 'here is a query, what solutions exist'…
correct. the pratt parser is just a way of implementing such a parser. to be technical, it is a form of left-corner parsing
I agree with both of you - parsing isn't that mathematically demanding, and many papers are badly written. This is why 'parsing techniques' is a joy. It explains with clarity what is often nightmarish to gleam from…
I would also like to say that the second edition is one of the finest cs-books I have.
There is an extended bibliography online for the second edition you've linked ftp://ftp.cs.vu.nl/pub/dick/PTAPG_2nd_Edition/index.html ''' The printed book contains only the about 400 literature references that are…
If you want that sort of succinctness, it is already covered in many compiler text books. This is to complement the existing literature with a broad and deep coverage of parsing in specific. There is most to parsing…
The second edition is far superior to the first in terms of coverage and depth. edit: I read a draft copy and after getting sucked into it for a weekend I grabbed the hard copy.
I would like to say: awesome! And yes most of my left recursion fetish would be covered by an operator precedence parser/left corner parser
ambiguity is useful for error recovery/error detection. also, some languages have ambiguity in their syntax (ML). I don't buy the 'optimization' argument. there is no reason we cannot have our cake and eat it -…
notably: lpeg uses backtracking over packrat parsing
regular expressions (ala cs) are equiv to finite state machines. regular expressions can't count or match ()'s. ragel allows you to mix in code within the state machine, so it is actually far, far more powerful than a…
It actually sounds more like cancellation parsing than frost's approach (which iirc was more that left recursion is bounded by input length)
ragel is for writing state machines and automata in. many parsers are written as automata, but that does mean it is in the same category as parsing tools such as LR, LL, GLR, PEG or CFG based approaches.
I can't remember off hand if it dealt with nullable terms or hidden left recursion properly either. don't get me wrong: I like the earley parser :-) I just think the original paper has some omissions and the treatment…
it isn't cubic time either iirc
and while i'm here - the original earley paper is full of bugs.for a modern treatment you may find aycock & horspool's work on 'practical earley parsing' interesting, as well as the work on the Marpa Parser in perl.…