New answers tagged

1

You have to have some code that follows the grammar. Perhaps as a simple case, this can be a simple set of recursive routines, one for each term in the grammar. You have to have a notion of the intermediate state of the parse, such as <term>: this can be part of the recursive state of the routines as they are executing. The parser goes a long for a ...


-1

I have one simple objection against null: It breaks the semantics of your code completely by introducing ambiguity. Oftentimes you expect the result to be of a certain type. This is semantically sound. Say, you asked the database for a user with a certain id, you expect the resut to be of a certain type (=user). But, what if there is no user of that id? ...


0

The central problem of NULL is that it makes system unreliable. In 1980 Tony Hoare in the paper dedicated to his Turing Award wrote: And so, the best of my advice to the originators and designers of ADA has been ignored. …. Do not allow this language in its present state to be used in applications where reliability is critical, i.e., nuclear power ...


1

Why in nearly all modern programming languages (Go, Rust, Kotlin, Swift, Scala, Nim, even Python last version) types always come after the variable declaration, and not before? Your premise is flawed on two fronts: There are new-ish programming languages that have the type before the identifier. C♯, D, or Ceylon, for example. Having the type after the ...


2

Pascal does it too by the way, and isn't a new language. It was an academic language though, designed from scratch. I would say it is semantically clearer to start with the variable name. The type is just a technical detail. If you want to read your class like the model of reality that it is, it makes sense to put the names of your entities first and their ...


11

All of the languages you mentioned support type inference, which means the type is an optional part of the declaration in those languages because they're smart enough to fill it in themselves when you provide an initialization expression that has an easily-determined type. That matters because putting the optional parts of an expression farther to the right ...


1

Why x: int = 42 and not int x = 42? Is the latter not more readable than the former? In such a simple example, there's not much difference, but let's make it a bit more complex: int* a, b; This is an actual, valid declaration in C, but it doesn't do what it intuitively looks like it should do. It looks like we're declaring two variables of type int*, ...


3

Yes, of course it can. See Bohm & Jacopini's 1966 paper (Yes, fifty years ago), "Flow diagrams, turing machines and languages with only two formation rules" for the gory details. They showed that any program, even a mess of GOTO-spaghetti, can be converted into a WHILE-loop around a CASE statement, that together implement a finite-state machine. This ...


6

The Finite State Machine has less computational power than a Turing machine. That is, the Turing Machine can do things that the FSM cannot. This is true because the FSM is limited in memory by the number of (finite) states. The following diagram illustrates the relationship between a Finite State Machine and a Turing Machine. As you can see, the Turing ...


2

One of the key advantages with a (for example) 32 bit unsigned integer versus a 32 bit signed integer is overflow. Fixed precision unsigned integers operate via 2n arithmetic, a specialized form of clock arithmetic. While this may be counterintuitive, it cannot overflow. Fixed precision signed integers, on the other hard, pretend to operate via the standard ...


3

If you have a use case where you never have to deal with negative numbers inside of any big integer calculation, then you could use the signed big integers implementation as well, and your performance guess is what I would expect, too, the performance differences would most probably be negligible. If you have a use case where negative intermediate results ...


6

The original reason to have unsigned integers in a language in the first place is to extend the numeric range of a fixed-size type upwards at the cost of limiting it downwards. Beneficial effects such as sane semantics of bitwise operations (in C) or implicit enforcement of a non-negative constraint are not the primary reason. Big integers do not have the ...


1

As observed by Jules it's a fact that early C++ implementations (CFront pre-1.0) had a dot for scope identification. A dot was also used in C with Classes (1980). Indeed this is a simple snippet from Classes: An Abstract Data Type Facility for the C Language 1: class stack { char s[SIZE]; /* array of characters */ char * min; /* pointer ...


-1

There are a few reasons it may not have been allowed in C#. It makes it easier to see what namespaces are being used if they are all in a centralized area. It is much easier to declare the using in one location if you want to use it in multiple methods. Pretty much every IDE I have worked with and VS in particular will tell you the fully qualified name of ...


6

Because, the proposed feature is a little silly. Namespaces exist specifically to avoid naming conflicts. The using exists to DRY your code. It allows the omission of namespace prefixes for items therein that don't actually conflict with anything. That said, if there is no name conflict at the top level, you can put the namespace at the top. There's no ...


2

While he doesn't refer specifically to the using directive, Eric Gunnerson's article Minus 100 Points addresses the general question of "why doesn't C# have [feature X] which C++ has". The most relevant part reads: That wording implies that we started with an existing language (C++ and Java are the popular choices here), and then started removing ...



Top 50 recent answers are included