sjolsen

10 ms·

31.
by sjolsen 11y ago
That the data he chose can be expressed as a range is utterly inconsequential. The values are never even used. In all likelihood, the author just wrote for (auto item : {}) and then filled in the first sequence of numbers that popp
32.
by sjolsen 11y ago
Why? Because that's the most concise way in general to iterate over an arbitrary list of enumerated values. There's no "abuse" here, just a particular example that could have been written more concisely.
33.
by sjolsen 11y ago
My point isn't about templates or memory allocation (hence the code that doesn't check for overflow or worry about object construction). It's that implicit casts from void* are unnecessary in C++, addressing your complaint th
34.
by sjolsen 11y ago
>it very much changes the feel of the language, namely into one where you need to insert pointless casts to satisfy a whiney compiler You could use the exact same argument against any type-safety feature: inserting "pointless"
35.
by sjolsen 11y ago
>When C is the right tool, C++ is no more a substitute than Java or C# When C is the right tool, assuming that it ever truly is, C++ is a vastly better substitute than Java or C#. C++ uses the same machine model as C; Java and C# do not.
36.
by sjolsen 11y ago
If we're talking about "undocumented legacy code doing crazy casts," static_assert is probably not an option.
37.
by sjolsen 11y ago
>It seems to make code less portable Than what? Than a freshly designed C-like language? Yes. But ISO C wasn't an effort to invent a new language. It was an effort to standardize existing practice, and provide a platform for improvi
38.
by sjolsen 11y ago
I'd suggest that even if it's absolutely necessary, one could at least put something like #if (ULONG_MAX < UINTPTR_MAX) && !defined (SUPPRESS_TRUNCATION_ERROR) #error Truncating pointers to long is a bad ide
39.
by sjolsen 11y ago
>I'm a Unix person, so the notion of long being less than word-length seems pretty silly to me It's silly for Windows to do something a certain way just because that's not how Unix does it? What's silly is assuming th
40.
by sjolsen 11y ago
Maybe the coding standard was written by someone who was used to auto-indentation making this sort of mistake immediately obvious.
41.
by sjolsen 11y ago
>If A = ∅, then id_A = ∅, which is exactly the result we'd expect, so I don't see any issue. The issue isn't with the example you gave, but with the idea in general that being able to produce a term of a given type in Hask
42.
by sjolsen 11y ago
You have to be careful when using Haskell for this sort of thing, because you can, for example, have a term of type Void: inhabitantOfZero :: Void inhabitantOfZero = fix id (Side note: the empty type can also be interpreted as
43.
by sjolsen 11y ago
>they are definitely not the same function This depends on what equivalence you're using, and the only one in which it's true (definitional equality) isn't very interesting. Extensionally, the functions are identical.
44.
by sjolsen 11y ago
>Not to detract from your point, but you don't need the expansion for that I just used the expansion given in the parent. It also makes it apparent that List is the closure.
45.
by sjolsen 11y ago
>Recently the use of derivations to implement regular expressions has become popular again And they're not limited to regular languages; with the right computational tricks (lazy evaluation, coinduction, whatever you want to call it
46.
by sjolsen 11y ago
>Isn't + == "or" and x == "and" like in boolean algebra? In a sense, yes. "×" denotes the product of two types— i.e., the type of pairs of one value of the first type, and one of the second. "+&q
47.
by sjolsen 11y ago
It's worth noting that if you take the expansion for List: L a = 𝟏 + a × (L a) = 𝟏 + a + a² + a³ + ⋯ and substitute 𝟏 for a: L 𝟏 = 𝟏 + 𝟏 + 𝟏² + 𝟏³ + ⋯ = 𝟏 + 𝟏 + 𝟏 + 𝟏 + ⋯ = 𝟏 + (L 𝟏) …
48.
by sjolsen 11y ago
>Our focus will be on closed semirings, which are semirings with an additional operation called closure (denoted * ) which satisfies the axiom: a* = 1 + a * a* = 1 + a* * a >In semirings where summing an infinite series makes sense, w
49.
by sjolsen 11y ago
If it's a specific program that's doing this, maybe you can wrap it with a script that executes ulimit.
50.
by sjolsen 11y ago
>So if we have a bounded set (and I've not given a technical definition of what that means) then we'd like the measure of that to exist Why in the world should this be true? I'd much sooner try to weaken this requirement t
51.
by sjolsen 11y ago
You're making the assumption that by "nice," he means "what society judges as nice," rather than what he personally considers to look nice, and that assumption is almost certainly wrong.
52.
by sjolsen 11y ago
>you have to make sure to recurse on the smaller partition first, otherwise you're using O(n) space in the worst case I haven't run the math, but I don't believe introsort fixes this. It's a constant-factor optimizati
53.
by sjolsen 11y ago
Quicksort is O(log n) space, not O(1).
54.
by sjolsen 11y ago
In the C code I've written, I've found there's really one major, common use for goto: stack unwinding. It usually looks something like status_t foo (result_t (*result)) { status_t status = good; res
55.
by sjolsen 11y ago
It's also worth pointing out that there are no array parameters. If you write void foo (char bar [42]) { // ... } then within the scope of foo, bar will be a pointer to char, not an array of char. You
56.
by sjolsen 11y ago
>I saw the majority of his complaints as basically "it's too hard/unfamiliar", a sentiment which I don't really agree with as I've noticed the steepness of learning curve of various software tends to be corr
57.
by sjolsen 11y ago
>You have profiled the program and determined that it is better to run the function at compile-time. For example, you might want to make `(regex "[a-z][a-z0-9]+")` compile the string to a regular expression at compile-time inst
58.
by sjolsen 11y ago
>When reading other people's code you now effectively have to learn what "language" they use too And? This is true of code in languages without macros, too. You have too learn all the vocabulary, all the types they use, al
59.
by sjolsen 11y ago
>Aren't macros breaking the homocionicity of the lisps? No. How would macros break homoiconicity? They expand into atoms and lists (and other datatypes), the same stuff of which macro-free programs are made. >And making maintenan
60.
by sjolsen 11y ago
I would imagine that anyone who just happens to have some nitric acid (or any strong acid of appreciable quantity and concentration) lying around would have the sense to at least Google the products of the reaction, if they didn't kn

More ›