Borrow-checking without type-checking

(scattered-thoughts.net)

55 points by jamii6 hours ago

3 comments

Panzerschrek3 hours ago
In my programming language I have some sort of "borrowing" too (although it's named differently). But my language has no dynamic typing, only static typing is used and thus all checks are compile-time and have no runtime cost. Why bothering with dynamic typing and paying runtime costs for it?
- jamii3 hours ago
 > The goal is that most of your code can have the assurances of static typing, but you can still opt in to dynamically-typed glue code to handle repls, live code reloading, runtime code generation, malleable software etc.
- Pay083 hours ago
 Dynamic typing is neat, I actually prefer it to static typing. Most people who think they have a problem with dynamic typing actually have a problem with weak typing.
 - choeger3 hours ago
 Dynamic typing is no typing.The point of types is to prove the absence of errors. Dynamic typing just has these errors well-structured and early, but they're still errors.
 - Pay082 hours ago
 Errors that you can recover from. I simply appreciate the added flexibility. Have you ever tried making a container of arbitrary types in C++?
 - SuperV12344 minutes ago
 You cannot do anything meaningful with a container of arbitrary types, it's just bad design.If you want to apply the same operation on all of them, then they share some API commonality -- therefore you can use polymorphism or type erasure.If they don't, you still need to know what types they are -- therefore you can use `std::variant`.If they really are unrelated, why are you storing them together in the same container? Even then, it's trivial in C++: `std::vector<std::any>`.
 - lmm1 hour ago
 If C++ was the only static type system I'd experienced, I would also think it was a bad idea. Have you ever used an ML-family language?
 Pay081 hour ago
 Nope. Closest thing I have used was probably Haskell.
 lmm1 hour ago
 Haskell ought to be good enough. Did you struggle with making your containers there?
 Pay081 hour ago
 Interestingly enough, I have never needed them there. Granted, I have written a few orders of magnitude less Haskell than I have C++. Still, the difference is worth interrogating (when I'm less sleep deprived).
 - teaearlgraycold3 hours ago
 Yes to dynamic typing. Yes to static analysis.
 - Pay082 hours ago
 What?
 - antonvs3 hours ago
 Technically, in a type theory context, there’s no such thing as “dynamic typing”. Types are a static, syntactic property of programs.The correct term for languages that don’t have syntactic types is “untyped”.> Most people who think they have a problem with dynamic typing actually have a problem with weak typing.All people who say things like this have never studied computer science.
 - _flux2 hours ago
 The term unityped is used as well, and at typing level this also makes sense: you have one type called object, you put that object alongside the value object ("tag"), and then at runtime all operations on that object check if its type object provides the operation the code is trying to apply on it (or maybe each value object directly knows the operations it supports). I think I prefer this term."syntactic type" is a weird term to me, though. Is that in common use?
drabbiticus23 minutes ago
Can someone help confirm whether I understand correctly the semantics difference between the final-line eval of<pre><code> x^ </code></pre> vs.<pre><code> x* </code></pre> ?It seems like either one evaluates the contents of the `box`, and would only make a difference if you tried to use `x` afterwards? Essentially if you final-line eval `x^` and then decide you want to continue that snippet, you can't use `x` anymore because it's been moved. Awkwardly, it also hasn't been assigned so I'm not sure the box is accessible anymore?
Serhii-Set1 hour ago
[dead]