_tef

7 ms·

1.
by _tef 15y ago
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.
2.
by _tef 15y ago
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, because punishing those
3.
by _tef 15y ago
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 change. It becomes a sun
4.
by _tef 15y ago
"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 felt more pressure not
5.
by _tef 15y ago
one of two videos has a download link for me. one uploaded in 2008 has a link but not the one from 2006
6.
by _tef 15y ago
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 'parents and grandfather
7.
by _tef 15y ago
Art of prolog makes an excellent first book, and the Craft complements it well with seasoned advice on elegant and efficient prolog.
8.
by _tef 15y ago
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 even wrong'.
9.
by _tef 15y ago
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' is reasonably accurat
10.
by _tef 16y ago
correct. the pratt parser is just a way of implementing such a parser. to be technical, it is a form of left-corner parsing
11.
by _tef 16y ago
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 papers.
12.
by _tef 16y ago
I would also like to say that the second edition is one of the finest cs-books I have.
13.
by _tef 16y ago
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 referred to in the book i
14.
by _tef 16y ago
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 than just the front end
15.
by _tef 16y ago
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.
16.
by _tef 16y ago
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
17.
by _tef 16y ago
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 - ambiguity and incremental p
18.
by _tef 16y ago
notably: lpeg uses backtracking over packrat parsing
19.
by _tef 16y ago
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 finite state machine
20.
by _tef 16y ago
It actually sounds more like cancellation parsing than frost's approach (which iirc was more that left recursion is bounded by input length)
21.
by _tef 16y ago
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.
22.
by _tef 16y ago
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 of earley parsing in '
23.
by _tef 16y ago
it isn't cubic time either iirc
24.
by _tef 16y ago
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. to me: the earley pa
25.
by _tef 16y ago
It has several bad properties too. The algorithm they outline is exponential. The challenge to make it run in cubic time will certainly turn it into a GLR or an Earley parser. (They can be formed from each other) To me: it is just another w
26.
by _tef 16y ago
I have a couple of loosely connected points and links: You want to buy 'Parsing Techniques 2nd Ed' -- this book is fantastic and will give you the understanding and clarity you seek. It is wonderfully comprehensive. And schmitz' thesis is a
27.
by _tef 16y ago
it is driven by pure sine waves -- you can't have polyphony or voice spectra (easily...)
28.
by _tef 16y ago
coffeescript is only a syntactic change and introduces no new semantics. it will always win in terms of code generated
29.
by _tef 16y ago
print [1,2,3].unique() whoops.
30.
by _tef 16y ago
I had a go on this. It was awesome fun. It happened on a whim - it was noticed the tesla coils were powered by audio, and we could easily get audio output from a kinect.

More ›