3,414 reputation
514
bio website
location Illinois
age 45
visits member for 2 years, 10 months
seen yesterday

1d
comment Has any language become greatly popular for something other than its intended purpose?
@JonPurdy: I think "cross-platform" has changed meaning; the idea wasn't so much that one could write programs that would run usably on different platforms, but rather to allow a means of providing multiple programs with compilable languages.
1d
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@RobertHarvey: I suppose code could read files entirely using getc() which returns a byte in each int, and thus avoid ever doing anything with char, but that's hardly a recipe for performance. From what I can tell, a nicer solution that would allow more efficient code and save countless programmers a lot of time would be to change the spec to eliminate Undefined Behavior in this particular situation; I'm not 100% sure that change would be compatible with all existing code, though.
1d
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@RobertHarvey: The C standard has never defined any practical means by which code can use small unsigned types without integer promotion, since even in those cases where integer promotion would be totally useless it was harmless, and there has been no need to prevent it. The only problem is a situation where integer promotion would have no effect on any standard-defined behavior, but causes a behavior that would have been fully defined in the absence of promotion to be exempted from the C specification.
1d
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@RobertHarvey: Those types don't solve the fundamental problem of unsigned types smaller than int getting promoted to signed int. On a compiler where int is 32 bits, uint16_t would yield the same problem as unsigned short. Somewhat interestingly, 32-bit platforms, given int16_t i; uint16_t u;, are required to define the behavior of i*=i; for all values of i, but are allowed to interpret u*=u; any way they like, without having to say how, for u values over 46340. The latter expression could be safely written as u*=1u*u; but that's ugly.
1d
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@RobertHarvey: The compiler making such an inference would be conforming to the spec as written. Personally, I think the problem is a broken spec which could and should be fixed by saying the result in such cases must be as if computed with an unsigned type (yielding completely-defined behavior) but it's possible that code might exist somewhere that quite legitimately relies upon a compiler doing something unusual in the aforementioned cases, and specifying the common behavior might forbid a compiler from processing such code in the fashion it requires.
1d
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@RobertHarvey: If int is 32 bits and unsigned short is 16 bits, then because of integer promotion rules the behavior is undefined. The vast majority of compilers will in fact perform the computation according to the rules of modular arithmetic, but some hyper-modern compilers would instead treat code like x *= x; as an invitation to infer that in any circumstance where it is reachable, x must be less than 46341, and that if the code isn't reachable with x less than 46341 it must not be reachable at all. Such assumptions can severely break code that would otherwise work just fine.
1d
asked Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
2d
comment How to add a property to an object you can't change?
This is indeed one of the major purposes for which ConditionalWeakTable was built; an important thing to note, however, is that some classes may imply in their contracts that two instances for which Equals returns true should be considered interchangeable; attaching supplemental information to instances without their knowledge may cause contractual expectations to be violated.
Apr
29
answered Is it okay to have objects that cast themselves, even if it pollutes the API of their subclasses?
Apr
27
comment If null is bad, why do modern languages implement it?
@JimBalter: The intersection and union types sound very powerful, though at a brief glance I'm not quite sure how they handle binding in case of overlapped functionality. Were they not required to be commutative, ordering could be used to establish ranking, but otherwise I'm not quite clear how conflicts would get resolved.
Apr
27
comment If null is bad, why do modern languages implement it?
...having an assignment operator which would trap immediately if that isn't the case, in addition to the one which would let nulls pass through, would help make such intention clear, and provide fail-fast behavior if the intention is violated.
Apr
27
comment If null is bad, why do modern languages implement it?
@JimBalter: Traps are useful for the scenario where one wishes to ensure that a piece of code will not run when a particular invariant doesn't hold, but where one has no particular means of handling the situation beyond indicating that an operation couldn't be performed because of a broken invariant. Otherwise, I'd say that while it may be useful to have types that must be initialized when created and could only be written using a trap-if-null assignment (or, for parameters, trapping if null when they are passed), for places where a variable, although nullable, is supposed to be non-null...
Apr
27
comment If null is bad, why do modern languages implement it?
@JimBalter: What would you think of having distinct kinds of assignment operators, and allowing parameters to indicate which type of "assignment" should be used when passing them? One kind of assignment operator would allow null to be regarded like any other reference, and the other would assert that the reference in question is not null and trap if it is?
Apr
27
comment If null is bad, why do modern languages implement it?
@JimBalter: How is a Maybe<T> which either holds a non-nullable reference to a T or doesn't, different from a reference that can either identify a T or be null? If one wishes to duplicate the state of an array which has had some but not all items written, not necessarily in sequential order, having a type which can hold the state of any numbered element, empty or not, would seem a very useful thing to have, and using a combination of a reference and a flag seems more expensive than using a nullable reference.
Apr
27
comment If Scala runs on the JVM, how can Scala do things that Java seemingly cannot?
I don't think the issue was "broken compatibility" so much as "complicated interoperabilty". If code has an object Producer which constructs and returns a reference to an implementation of List, all of whose members are of type Animal, and another object Consumer which expects to be given a type-erased List<Animal>, the code can easily use the two objects together. If, however, Producer had expected a reified TList<T>, it would have been much harder to have an object which use Producer to supply things for Consumer.
Apr
24
comment Is String processing more complex than number processing in programming languages?
I find it curious that languages don't make any effort to simplify handling of strings which contain only ASCII characters, given that in many fields the vast majority of strings that get processed are intended to be machine-readable strings consisting only of ASCII characters. Having things like base64 strings stored using four bytes instead of eight for each trio of octets would seem like it should be a pretty big win.
Apr
24
comment Why don't Python and Ruby make a distinction between declaring and assigning a value to variables?
@delnan: The existence of syntactic options for the first two would not imply that code that wanted #3 couldn't keep using the existing syntax. Given the dynamic nature of Python (not sure about Ruby) I'm not quite sure how #1 could consistently be detected prior to execution.
Apr
24
comment Why don't Python and Ruby make a distinction between declaring and assigning a value to variables?
...even when reading code I would think it would be helpful to know which of the above was intended in case context doesn't make it clear.
Apr
24
comment Why don't Python and Ruby make a distinction between declaring and assigning a value to variables?
Would you be opposed to the idea of being able to syntactically distinguish the three cases: (1) I don't expect any variable already exists with this name, and if one does the code is overwriting something it shouldn't so execution should trap; (2) I expect that I'm updating something that already exists with this name, and if it doesn't the code isn't updating what it's supposed to so execution should trap; (3) I want this to create or update the thing in question as appropriate. There are times when #3 really is most useful, but...
Apr
24
comment Which arguments pass by value and which pass by reference in Java?
...had not been called (those latter issues attach a slightly stronger concept of identity than Java would otherwise have). From Java's perspective, objects #204 and #451 would be indistinguishable, but one of them would be the 204th object created and the other would be the 451st.