8 ms·

If it isn't the type problem, then what is the type signature of the shift operator?

nothrabannosir 9y ago
No type expert, but: << :: Int -> Int | Long -> Int | Long << :: Long -> Int | Long -> Long ? If you can express a dynamic type system at all, then this seems intuitive?
- toolslive 9y ago
  Yes, and it means (<<) is not closed over Int, which means that you will need to be able to compare instances of Int to instances of Long. Before you know it you're wondering what the result is of >>> -1j * -1j == -1 and >>> f(-1j * -1j) == f(-1) where f is some pure function. Some people think it's the road to perdition.
  - acjohnson55 9y ago
    Are you basically saying that programmers want intuitive interpretation of numeric literals, without having to suffix them to indicate their type? This strikes me as a situation where editing programs as plain text holds is back. Most languages have complex and error prone implicit type conversions between numeric types so to keep the text representation of the program looking clean. But if there were a way for the source to contain explicit type annotations on numbers without necessarily requiring the programmer to have to look at them or specify them in most cases, that seems like a much better situation. I think there are many such ways we are held back by plain text representation.
deleted 9y ago
[deleted]
guipsp 9y ago
Wouldn't << :: Integer -> Integer -> Integer be good enough?
kccqzy 9y ago
Use union types. (Which are different from sum types, confusingly.)
- uryga 9y ago
  Could you expand on the difference? I heard those two terms used interchangeably. edit: saw union/intersection types mentioned in another comment - I guess that's what you were referring to?
  - kccqzy 9y ago
    Yes. Sum types are essentially discriminated unions. Given a value of a sum type, it is possible to tell which alternative it is. This is commonly done through pattern matching. Union types are a bit like C's undiscriminated unions in that you cannot tell what the actual type is. This makes them significantly less useful, and thus very few functional languages have them. Essentially when you get back a union type of A | B, you can only perform actions that make sense on both of them. This essentially means functions with a type variable (parametrically polymorphic) in typical functional languages. If we additionally have subtyping (which ML-like languages don't) this can be more useful. Side note: things like the `typeof` operator in JavaScript is muddling the water a bit. But I'm talking about the theoretical perspective.
barrkel 9y ago
Its static type is something like: dynamic -> dynamic -> dynamic That's because that's how dynamic type systems work, from a static typing perspective. They defer typing until runtime. Properties of the code proven before execution aren't usually very interesting.

No type expert, but: << :: Int -> Int | Long -> Int | Long << :: Long -> Int | Long -> Long ? If you can express a dynamic type system at all, then this seems intuitive?

toolslive 9y ago
Yes, and it means (<<) is not closed over Int, which means that you will need to be able to compare instances of Int to instances of Long. Before you know it you're wondering what the result is of >>> -1j * -1j == -1 and >>> f(-1j * -1j) == f(-1) where f is some pure function. Some people think it's the road to perdition.
- acjohnson55 9y ago
  Are you basically saying that programmers want intuitive interpretation of numeric literals, without having to suffix them to indicate their type? This strikes me as a situation where editing programs as plain text holds is back. Most languages have complex and error prone implicit type conversions between numeric types so to keep the text representation of the program looking clean. But if there were a way for the source to contain explicit type annotations on numbers without necessarily requiring the programmer to have to look at them or specify them in most cases, that seems like a much better situation. I think there are many such ways we are held back by plain text representation.

deleted 9y ago

[deleted]

guipsp 9y ago

Wouldn't << :: Integer -> Integer -> Integer be good enough?

kccqzy 9y ago

Use union types. (Which are different from sum types, confusingly.)

uryga 9y ago
Could you expand on the difference? I heard those two terms used interchangeably. edit: saw union/intersection types mentioned in another comment - I guess that's what you were referring to?
- kccqzy 9y ago
  Yes. Sum types are essentially discriminated unions. Given a value of a sum type, it is possible to tell which alternative it is. This is commonly done through pattern matching. Union types are a bit like C's undiscriminated unions in that you cannot tell what the actual type is. This makes them significantly less useful, and thus very few functional languages have them. Essentially when you get back a union type of A | B, you can only perform actions that make sense on both of them. This essentially means functions with a type variable (parametrically polymorphic) in typical functional languages. If we additionally have subtyping (which ML-like languages don't) this can be more useful. Side note: things like the `typeof` operator in JavaScript is muddling the water a bit. But I'm talking about the theoretical perspective.

barrkel 9y ago

Its static type is something like: dynamic -> dynamic -> dynamic That's because that's how dynamic type systems work, from a static typing perspective. They defer typing until runtime. Properties of the code proven before execution aren't usually very interesting.