Earlier quoted context omitted.
I think a better (subjective of course) lesson might be to enforce a style. I have been thinking about making a toy compiler (I wanted to write a borrow checker) that treats bad code as an error, solely aimed at numerical code - I have recently had "Scientific Programming in Python for physics etc." inflicted on me. Slight tangent, but I think if Haskell enforced some kind of whitespace a la Python it would be much m…
What do you mean? Whitespace does mean something in Haskell, see http://echo.rsmw.net/n00bfaq.html .
Language Design: Use 'ident: Type' not 'Type ident'
161–170 of 192 posts
Re: Language Design: Use 'ident: Type' not 'Type ident'
#162Earlier quoted context omitted.
I'd consider compile time as part of the UI, so in that sense I think we agree. (If the compile is long because the implementation is poor, that needs to be fixed.) Not sure what you mean on the dichotomy. If someone says that a language needs to have X because that will make things simpler for the computer, I say that they are wrong. The goal, the only reasonable goal, is to make things better for humans.
> If the compile is long because the implementation is poor, that needs to be fixed The compile time could be long because the implementation is poor. But it's also possible that the specific requirements do not allow for a significantly faster compile time. That's why the requirements matter. They determine the space of possible implementations. If the requirements eliminate all "fast" implementations, then the resu…
Its verifiers are awfully finicky, and tuning the parameters (including selecting the most appropriate verifier) can mean the difference between successful completion in a few seconds, and outright non-termination/timeout-with-failure.
It's true that the answer is to have better verifiers, but that's not just a matter of tweaking the verifier code, it's a serious research challenge. One of the most serious problems with formal methods is the ability to scale.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#163Earlier quoted context omitted.
I think the vast majority of code that exists in the world today has at most one space between a variable and its type.
There’s a difference between “things that are implemented in popular programming languages” and “things that are implemented in most programming languages”
Re: Language Design: Use 'ident: Type' not 'Type ident'
#164Earlier quoted context omitted.
Checking if a Brainfuck program is well formed (i.e. can be run) is a linear time operation. In C++ this can take forever. They have different complexities.
The original comment was about Turing completeness, and it was defined incorrectly. I was giving an example of a dead-simple language that was Turing complete, because the claim was that metaprogramming made C++ Turing complete.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#165Earlier quoted context omitted.
Metaprogramming in C++ is TC, but it's not what makes C++ TC by itself.
Yes, but it is the difference to other programming languages. In C you cannot encode a Turing machine that is executed by the compiler at compile time . In Brainfuck you cannot encode a Turing machine that is executed by the compiler at compile time . In C++ you can encode a Turing machine that is executed by the compiler at compile time . That is the difference we are discussing here.
But you can get quite close with macros
Re: Language Design: Use 'ident: Type' not 'Type ident'
#166Re: Language Design: Use 'ident: Type' not 'Type ident'
#167Re: Language Design: Use 'ident: Type' not 'Type ident'
#168Earlier quoted context omitted.
Fast er , yes. Still lots to do.
You're saying LLVM is slow even when generating code without optimisations?
The thing that will massively speed up rustc is the current re-architecting of it. We’re at the point of “few percent here, few percent there” with the current design. These add up over time, of course, but batch compilers are inherently slower than the newer style ones (after an initial compile).
Re: Language Design: Use 'ident: Type' not 'Type ident'
#169Earlier quoted context omitted.
Yes, but it is the difference to other programming languages. In C you cannot encode a Turing machine that is executed by the compiler at compile time . In Brainfuck you cannot encode a Turing machine that is executed by the compiler at compile time . In C++ you can encode a Turing machine that is executed by the compiler at compile time . That is the difference we are discussing here.
>In C you cannot encode a Turing machine that is executed by the compiler at compile time. But you can get quite close with macros
Yes, you can do a lot with the C preprocessor. You can also do a lot in languages that only have bounded loops and are therefore not Turing complete. You can either express nonterminating computations (Turing completeness), or you can't (still powerful, but dramatically less poweful). This question is binary. There is no fuzziness, there is no approximation, there is no "quite close".
Re: Language Design: Use 'ident: Type' not 'Type ident'
#170Strong disagreement here. "type ident" flows with the data during assignment, doesn't confuse the infix operators, and doesn't misuse ":" from a human-language standpoint. For example: val x: String = "hello" The type interrupts the flow of data from "hello" to x, so one thing that pops into mind is that this is typecasting the value to a string before storing it. Nope. Another possibility I instinctively see this as…
I was going to say the same thing about meaning flow. But here's an idea. The OP wants meaning to flow left to right for lambda declarations. Why not have assignment go that way too. "Hello" => x: string Might work. Computer science pseudocode uses notation kind of like that. Also, I understand now why Scala and Rust always seemed clunky to me.
Does it? In my time at the university, assignments in pseudocode were usually written as
x