121–130 of 131 posts
Earlier quoted context omitted.
I imagine they did, considering the head of LLVM is a (probably distant) coworker of theirs.
"The head of LLVM" - no such thing exists, but okay. (People have such weird ideas about how these projects work in practice).
Earlier quoted context omitted.
You are probably right, assuming input programs are correct. Rust (and Haskell) is not easy to _type-check_ though.
> Rust (and Haskell) is not easy to _type-check_ though. Is that really the case? It seems to me that a Prolog-like resolution system, coupled with a constraint solver, would get most of the job done with little effort. There are certainly many rules to keep track of, but in some cases the newer rules are strict generalisations of the older rules. For example, Haskell's original type classes are just a special-case o…
My usual approach to implementing a type system is to derive a flat list of Prolog equations out of the AST and leave it to Prolog for solving. If you ask what to do with error messages, I've got a comprehensive answer, but it is not for a mobile phone typing.
Earlier quoted context omitted.
I am talking about the backend optimisations, not the frontend parts. Ada frontend got tons of sweet static information for the backend to consume.
That makes more sense. Did you ever work on any Ada compiler I might have heard of?
Frontend was awful and I never finished it, but the LLVM-style backend wad very easy to build.
Earlier quoted context omitted.
Web Assembly is not even there yet, asm.js up until recent was more a toy and a standalone runtime, I have not seen it being routinely used for a fallback, nothing like, say, python with C modules. As for virtual methods, it is a problem of a bad C++, devirtualisation may help, but nobody cares in general. We have a cool curiously recurring template pattern instead. But for the integers you're right. And signedness i…
> Web Assembly is not even there yet, asm.js up until recent was more a toy and a standalone runtime, I have not seen it being routinely used for a fallback, nothing like, say, python with C modules. That's because (a) page performance is frequently gated on things other than JavaScript, so people don't go through a lot of trouble to write C++; (b) many modules that would be written in C in Python are provided by the…
As for C++ - there is a choice. With JS the choice is much more limited. You either rely on non-standard asm.js behaviour, lose DOM access with web assembly, or tolerate the stupidity and limitations of the language that far overgrown its tiny niche.
Btw., I am yet to hear how a language with a fixed syntax and no macros can be perceived as "highly expressive".
Earlier quoted context omitted.
And Go proves munificent's point: it doesn't have many compiler optimizations either. (This may change with the WIP SSA backend, but the point remains that Go gained huge popularity in spite of having a non-optimizing compiler.)
Yeah, more interesting is having them rediscovering Turbo Pascal compile speeds. EDIT: I wonder why the positive effect to re-discovering that not all compilers need to be like C and C++ compile speeds and that it was once upon a time mainstream, is worthy of downvotes.
Earlier quoted context omitted.
Dynamic languages are (generally) not compiled ahead of time. It is possible to have static typing in a dynamic language in the sense that the code is interpreted at runtime (but the types are set statically in the code), and there is no "binary" that one runs. It used to be called interpreted language or "scripting" language - but I think the vocabulary shifted so the word "dynamic" more encompasses what the languag…
By that definition, AFAIK, Swift is neither a dynamic language nor dynamically typed.
https://developer.apple.com/swift/
As to whether it is dynamically or statically typed - it's easy to tell - do you need to indicate a variable is an int or a char or a string before you start using it? and do you have to cast the variable to different types when using functions that expect a certain type? If so - it's statically typed. Dynamically typed languages allows you to give an character "5" to a function that expects an integer (ie the number 5) and then automatically converts it so for example the final result to 5+"5" is int(10). Or when you try to print it, it gives you a string literal "1" and "0" without you having to recast it yourself.
Obviously having dynamic typing makes things easier for humans, but the computer has to keep predicting what the programmer is going to do with that variable, so it has some runtime and compile time weaknesses in performance, memory usage, as well as less strictness in compile-time checking - which might allow certain types of errors to sneak by, whereas static typing is very direct - you have to instruct the computer to do every casting from one type to another, etc., and the statically-typed compiler is a sadist - it will fail all your code over and over again until you get all the types right. The difference is extremely noticeable even for a novice programmer.
https://developer.apple.com/library/ios/documentation/Swift/...
says that Swift is "type-safe" (compiler is a sadist and will halt on all type errors) but has type inference so you don't have to explicitly indicate the typing of a variable. I would consider it to be heavily on the statically-typed side though - since it seems the language won't let an integer variable all of a sudden also be a string - you have to cast it properly first.
Not sure where the confusion comes from, probably from people putting buzz words to everything that is new regardless of applicability.
Either way, you are correct, swift is not "dynamically-typed" and neither is it a "dynamic/interpreted" language.
Earlier quoted context omitted.
By that definition, AFAIK, Swift is neither a dynamic language nor dynamically typed.
According to Apple itself, Swift is a compiled language, and there is no use of the word "dynamic" or "dynamic language" on Apple's website https://developer.apple.com/swift/ As to whether it is dynamically or statically typed - it's easy to tell - do you need to indicate a variable is an int or a char or a string before you start using it? and do you have to cast the variable to different types when using functions…
This really has nothing to do with the dynamic/static axis. Many definitely dynamically typed languages (python, lisp variants, etc) do not allow this kind of conversions. This is just poor language design.
Often languages which allow this kind of implicit conversions are called weakly typed, but that's another very ill defined term. I like "stringly" typed.
Earlier quoted context omitted.
By that definition, AFAIK, Swift is neither a dynamic language nor dynamically typed.
According to Apple itself, Swift is a compiled language, and there is no use of the word "dynamic" or "dynamic language" on Apple's website https://developer.apple.com/swift/ As to whether it is dynamically or statically typed - it's easy to tell - do you need to indicate a variable is an int or a char or a string before you start using it? and do you have to cast the variable to different types when using functions…
Modern statically typed languages often don't require this, because type inference, so its a bad test.
> and do you have to cast the variable to different types when using functions that expect a certain type?
Modern statically-typed languages may not require you to do this (e.g., Scala if the types involved have appropriate implicit conversions defined.)
> Dynamically typed languages allows you to give an character "5" to a function that expects an integer (ie the number 5) and then automatically converts it so for example the final result to 5+"5" is int(10).
That's the canonical example of weak typing; many (maybe most) dynamically-typed languages do not do this type of conversion.
A better test for a dynamically-typed language is what kind of error is produced by sending a value of an unexpected tpe (including, as expected, anything that can be handled by the applicable implicit conversion rules) to a function: if it is a compile-time error, the language is statically typed. If it is a runtime error, it is a dynamic language.
Earlier quoted context omitted.
> Rust (and Haskell) is not easy to _type-check_ though. Is that really the case? It seems to me that a Prolog-like resolution system, coupled with a constraint solver, would get most of the job done with little effort. There are certainly many rules to keep track of, but in some cases the newer rules are strict generalisations of the older rules. For example, Haskell's original type classes are just a special-case o…
Hindley-Milner is already quite Prolog-like. But you're right, CLP(fd) rocks for typing. My usual approach to implementing a type system is to derive a flat list of Prolog equations out of the AST and leave it to Prolog for solving. If you ask what to do with error messages, I've got a comprehensive answer, but it is not for a mobile phone typing.
Earlier quoted context omitted.
Hindley-Milner is already quite Prolog-like. But you're right, CLP(fd) rocks for typing. My usual approach to implementing a type system is to derive a flat list of Prolog equations out of the AST and leave it to Prolog for solving. If you ask what to do with error messages, I've got a comprehensive answer, but it is not for a mobile phone typing.
I'd really appreciate further comments on what to do with type errors for prolog/minikanren-like tools as typecheckers
My approach to the typing error reporting is quite compatible with the Prolog codegen. What I do: for each AST node which produce one or more type equations I record the location data (cache it and give it an index), and then issue a Prolog term like this: with_location(Id, Term), for each of the terms generated by this location.
with_location semantics is simple, but may depend on the presence of a backtracking. If it's a plain Hindley-Milner, there is no backtracking, and it simply do call/1(Term), continue if true, store Id and the failed term with all the current bindings and fail/0() if false.
If there is a backtracking, I store a stack of location ids and failure reasons instead, but this required patching the Prolog execution engine a little bit (luckily, I'm using my own Prolog for this).
Now, the next step is to decipher the failed term. Most of the equations are in a trivial form: equals(A, B), so I simply report that prolog_to_type(A) failed to unify with prolog_to_type(B). For the other (rare) kinds of equations I define custom pretty-printing rules.