gsg

21 ms·

181.
Building an Optimising Compiler for Dart(infoq.com)
3 points by gsg 13y ago|0 comments
182.
by gsg 13y ago
Get out of here with your undocumented opcodes! (Neat.)
183.
by gsg 13y ago
It's not uncommon for machines to have a branchless idiom for generating the value of a condition. For instance, in x86: cmp price, 100 setg reg movzx reg, reg lea reg, [reg + reg*4 + 5]
184.
by gsg 13y ago
Language semantics differ, full stop. Say you have x = 2147483647: x + 1 => -2147483648 (Java) x + 1 => Undefined behaviour (C, assuming int32_t and various things about the implementation) (1+ x) => 2147483648.0 (Ema
185.
by gsg 13y ago
"It's possible to program a computer in English. It's also possible to make an airplane controlled by reins and spurs." - John McCarthy.
186.
by gsg 13y ago
Cyclic lists might not be a good interview question, but working through some of the details is a great exercise. A good follow on from finding whether there is a cycle is finding the length of the lead-in and cyclic parts of the list, and
187.
by gsg 13y ago
You might find http://www.locklessinc.com/articles/dlist/ interesting: it describes a (perhaps excessively) clever way to do intrusive lists that gives type checking. (Unfortunately it does rely on `typeof`, an ex
188.
by gsg 13y ago
Unfortunately, general purpose text is not a clean simple thing that you can model nicely. Unicode is a mess because the problem it tries to solve is messy. Even if you could somehow come up with something obviously better, getting any new
189.
by gsg 13y ago
It is related, really. Polymorphic: many shaped. Monomorphic: single shaped. Isomorphic: same shaped.
190.
by gsg 13y ago
I just flicked through my copy of K&R (second edition), and at the beginning it clearly prefers preincrement. The introduction of for loops comes before that of ++, and the first for loop in the book is actually for (fahr = 0; fah
191.
A Crash Course for the MinCaml Compiler(esumii.github.io)
12 points by gsg 13y ago|0 comments
192.
by gsg 13y ago
I bet. All the more reason for the implementation to provide it for you - possibly transparently.
193.
by gsg 13y ago
That's a reasonable defense of std::shared_ptr, but I was not discussing C++ code (I was careful to mention "allocation heavy languages" in my post).
194.
by gsg 13y ago
"This brings the performance of reference counting on par with that of a well tuned mark-sweep collector." I'm not really convinced. How well does it stack up when the competition is a copying generational collector?
195.
by gsg 13y ago
Reference counting, even ignoring the additional expense C++ places on std::shared_ptr by requiring it be thread safe, is far too slow for allocation heavy languages. Only "we don't give a damn" implementations (like CPython)
196.
by gsg 13y ago
It's fine since all the detailed goop is at the implementation level. Programmers need not care. Making a distinction between known and unknown calls in the implementation is not only a good thing, but in a language with first-class fu
197.
by gsg 13y ago
Stack allocation needn't be unprincipled hackery. You can keep a buffer of static size on the stack (resp. in the struct) and fall back to dynamic allocation only if there is insufficient space.
198.
by gsg 13y ago
A lot of CPUs don't have a division instruction at all, let alone 64 bit division.
199.
by gsg 13y ago
The nesting can be taken care of: typedef struct list { int value; struct list *next; } list; #define cons(head, tail) ((list[]){{.value = head, .next = tail}}) list *xs = cons(0, cons(1, cons(2, NULL)));
200.
by gsg 13y ago
You might find http://perso.ens-lyon.fr/alain.darte/Master12/Cours2012_8a.p... interesting - it addresses the question of NP completeness head on.
201.
by gsg 13y ago
Throwing away sharing of code pages (and the security benefits associated with PIC) for a bit of inlining doesn't seem like the best idea.
202.
by gsg 13y ago
The author invokes the idea that writing assembly and writing compiler passes are similar enough activities that you can substitute one for another, but that is not the case. Good thing, too - I don't even want to think about how buggy
203.
by gsg 13y ago
I would argue that Javascript is not lexically scoped because the scope of a variable definition does not depend on the lexical structure of a program (with the sole exception of function boundaries). This is true even to the point of mul
204.
by gsg 13y ago
The point isn't that I don't like it (although I really don't), it's that Scheme doesn't work the same way as Javascript, and the Javascript-is-Scheme slogan contributes to non-understanding of those differences.
205.
by gsg 13y ago
Emacs lisp doesn't guarantee TCO (and in practice does not perform it at all), and yet few people claim that it is not a dialect of lisp.
206.
by gsg 13y ago
Quite the contrary. Javascript has a strange, ugly hybrid of lexical and function scope that is not that of Scheme, which I suspect that Bob understands very well given his interest in languages (and that he works on a language that compile
207.
by gsg 13y ago
This problem has been encountered and studied before: see Appel and Zhao's paper, Efficient and Safe-for-Space Closure Conversion.
208.
by gsg 13y ago
That's a much better, much more careful article. For example: > Just in case my Mea Culpa and Introduction did not cover it. Let me be clear: This article is not disqualifying the linked-list for other types of usages, such as when it c
209.
by gsg 13y ago
This is awful advice which is based on a complete misunderstanding of the use cases of linked lists. Linked lists apply in situations when you can't place things in arrays (because they are too large to copy, or because there will be pointe
210.
by gsg 13y ago
You get warnings. I guess the aim is to allow people to run their code no matter how broken it is, while still giving a way to detect some errors. Seems pretty odd to me.

More ›