FrankHB

5 ms·

1.
by FrankHB 4y ago
This is not the only case. It harms not only performance, but also conformance, e.g. https://developercommunity.visualstudio.com/t/unable-to-move... . Microsoft is stupid enough since the first decision of the implement
2.
by FrankHB 4y ago
In some stricter sense, back-end is for target-depending stuff like ISA-dependent code generation. A great deal of work in both GCC and LLVM is in the so-called mid-end. Both have more than one IRs in the pipeline after the front-end.
3.
by FrankHB 4y ago
This is technically incorrect. A programming language can be designed with specification in mind, even with a formal one (e.g. SML). It is just true that the specification is not likely effectively verified before more than one real impleme
4.
by FrankHB 4y ago
There are simply lacking of such strong requirements in language standards. C/C++ even have the specific "linkage" concept to abstract the binary details under the source form away. And you may know, many libraries are distri
5.
by FrankHB 7y ago
It's about the ability, not the reality. As Racket, the base language can have no explicit rules for any type systems to be embedded. There can be more powerful candidates, e.g. Kernel: https://web.cs.wpi.edu/~jshutt&#x
6.
by FrankHB 7y ago
Types are closed terms of contracts encoded in a language within specific phases. If you really need any guarantees without further knowledge shaped before running, then, besides the typechecking, the typing rules should also be programma
7.
by FrankHB 7y ago
MSYS2 can do something better than Cygwin. I'm disappoint to "VM-like" behavior too, so I don't expect they would be totally replaced by WSL. But this is similar in the other direction. Many applications just rely on suc
8.
by FrankHB 7y ago
I'd like to continue to develop something based on vau calculi with some forms of partial evaluators, since I have lost interest in type theories.
9.
by FrankHB 7y ago
There are too many things to be improved, e.g. support of simple (enough) cases w/o any scriptish code, getting away of stupid syntaxes (like distinctions of indents with TABs vs. spaces) in makefiles, avoiding being relied on as a com
10.
by FrankHB 7y ago
This is simply not acceptable because it would silently break too much code. Parameter passing in C++ used to mean copy, not move. Perhaps a more important rule is that id-expressions should mean lvalues, not xvalues. Note that even express
11.
by FrankHB 7y ago
Dynamic scopes are not available in C++. I suppose them as in languages like Emacs Lisp. I get the point, though.
12.
by FrankHB 8y ago
It isn't. Quoted from the C++ standard: "the asm declaration is conditionally-supported; its meaning is implementation-defined". ISO C does not differ much in conformance (the asm keyword is common extension listed in annex J
13.
by FrankHB 8y ago
The problem is that pointers almost totally violate the single responsibility principle. Technically, the only dependencies on pointers are types of the allocation/deallocation functions which are mandated in ISO C++ even for freestand
14.
by FrankHB 8y ago
> Then C++ added new abstraction mechanisms on top of C, that were at first totally orthogonal: just classes and templates. Not quite. Classes are based on struct types in C. Templates are based on classes, function types, and more. >
15.
by FrankHB 8y ago
Now they should be surely aware of that. FYI, here was one of Chinese translation of the article, but the contents was just deleted 10 minutes ago: https://www.oschina.net/news/94805/deprecating-pointers