These are chat archives for got-lambda/expression

4th
Nov 2017
Magnus Therning
@magthe
Nov 04 2017 06:43
I hope this isn't too off topic, but since many in the group work in companies that seem to be constantly hiring: http://www.gp.se/nyheter/ekonomi/botar-brist-p%C3%A5-kompetens-med-integration-1.4773068 (in Swedish)
Jean-Louis Giordano
@Jell
Nov 04 2017 07:17
is it subtyping vs parametric polymorphism with Ceylon vs Haskell @jensli ?
cool, reading about it seems like Ceylon has both! Will have to read more about this
Jean-Louis Giordano
@Jell
Nov 04 2017 09:04
I've been working on an article to try to put a balanced perspective on my preferences and thoughts around types, I will be sharing on social media a bit later, but I'd welcome some feedback before that! http://jawaninja.com/programming/2017/10/29/on-types-and-intent
(it's a bit long, sorry about that)
Pierre Krafft
@Zalastax
Nov 04 2017 10:56
@jensli I had a discussion about union types last week! I love them but my friend is not sold. His main gripe was that at least in TypeScript you need to check the type at run-time (using typeof or some unique tag you add manually). Erasing types is important to dissallow making tricks like specializing generic functions (e.g. an id function x => x + 1 for ints).
jensli
@jensli
Nov 04 2017 11:03

@Jell I like your essay. I like the sensible tone of it. You're reasoning, not evangelising. (I'm at the same time both very bored and provoked by evangelists.)

I didn't read the article very carefully (It really is a bit long, maybe a summary of the different section in the introduction would be a good idea?)

I agree with what seems to be your main points

  • Types are not so much about catching bugs as it is about explicitly specifying properties about the software to human readers. (You call this "communicating intent" and "assumptions".)
  • Both static and dynamic systems comes with costs and benefits. Understanding the this tradeoff is mainly a social and psychological problem.

Article

I read an interesting article some time ago about the value of static types. Perhaps it would interest you (despite the title it really isn't bigoted at all, for example it contains a long list of the costs of a static system): http://www.draconianoverlord.com/2010/11/24/why-im-a-static-typing-bigot.html

Dynamic-static Hybrid languages

Have your considered dynamic-static hybrid languages? To me it seems that this could give many of the benefits of a static type system, while only a getting a little of the cost. There is a nice little language that is called Fantom which takes this approach. It want to improve on Java by making simplifications and making it easier to use dynamic types. It is like the total opposite of Scala, fixing Java by taking inspiration from Ruby and Python instead of from Haskell.

Sadly, almost no one is using it.

http://fantom.org/

Some minor thoughts and nit-picking

That’s not how euclidian distance works though, those are not very useful comparison.

I use to think about these kind of relationships as Euclidean distances in a multi-dimensional space. Maybe that makes sense.

Because Haskell relies on the knowledge that a function is pure to perform all sorts of optimisations, which is really good for performance. Like in our code above, it chooses to memoize the execution of foo11 because its type signature says it’s pure.

I wouldn't really say this this is an "optimisation" which the compiler "chooses" to do, since this memoisation is a specified part of the language semantics.

jensli
@jensli
Nov 04 2017 11:25

@Zalastax Interesting. Does TypeScript have non-tagged union types, like Ceylon? Haskells data type are also unions, but you have to declare them and have special tags for each case, that is kind of a different thing.

The whole point of union types is the be able to tell the objects apart at runtime... But that doesn't mean that you can tell what runtime type an arbitrary value has... For example:

fn1 :: (Int | Bool) -> Bool  -- Inside this function your can tell if the argument is Int or Bool
fn2 :: a -> a -- But you can't in this function, its argument doesn't have a union type
Pierre Krafft
@Zalastax
Nov 04 2017 11:33
@jensli yes it does https://www.typescriptlang.org/docs/handbook/advanced-types.html ! The nice thing about Haskell's union is that the tag can be small, in contrast to Java or Erlang where every type needs a unique identifier. Maybe it's not a problem to have a globally unique tag, as long as you don't expose that primitive to the user. Your example seems like the best approach to me
jensli
@jensli
Nov 04 2017 11:35
I think in Ceylon (as in Java) you would be able to check the type of the argument in fn2. But that is not because of the union types.
Pierre Krafft
@Zalastax
Nov 04 2017 11:36
What I really like with TypeScript's approach is that as you do your normal if-checks the type gets refined according to the interface, basically just enhancing the normal JS patterns. Pattern matching is of course a perfectly good alternative
Jean-Louis Giordano
@Jell
Nov 04 2017 11:37
@jensli Thanks for the tips on Fantom will have a look!
is it really true that memoization is part of the language spec? I thought this was left up to the specific implementation
Pierre Krafft
@Zalastax
Nov 04 2017 11:38
Yes, I don't think any languages adhere to the rules in your example. If they have Ceylon/TS style unions they have some run-time checking that can break e.g. the id function
jensli
@jensli
Nov 04 2017 11:43
@Zalastax But if the language doesn't doesn't have any mechanism for checking the runtime type for types other than unit types? Then it wouldn't be possible to ruin the id function. I don't know it there are languages like that, though...
Pierre Krafft
@Zalastax
Nov 04 2017 11:45
@jensli that's what I was trying to say. The best solution would be to add a global tag but only expose runtime type checking between the unions you have stated explicitly
jensli
@jensli
Nov 04 2017 11:46

is it really true that memoization is part of the language spec?

Eh, maybe I'm mixing it up... It is the values that are always "memoised" as part of the spec, (what they call call-by-need). The functions can probably be memoised as a optimisation by the compiler. You're right, sorry!

Pierre Krafft
@Zalastax
Nov 04 2017 11:49
A good explanation of call-by-need https://stackoverflow.com/a/8822824
A really useful trick in Haskell to get performance is to restructure your code so those Promises gets made
Jean-Louis Giordano
@Jell
Nov 04 2017 11:53
@jensli ah I see! makes sense
jensli
@jensli
Nov 04 2017 11:59

@Jell I don't know how your example with foo11 = unsafePerformIO ... would behave...?

I would guess that, by the language standard, it would be evaluated only once. The value of foo11 would be a thunk, which after first evaluation would be replaced by the resulting value. Have to try this out.

I think that the story for functions with arguments is different, though.

Jean-Louis Giordano
@Jell
Nov 04 2017 12:36
I the article I show the result of calling it twice at the REPL
only prints "yo" the first time in GHC
jolod
@jolod
Nov 04 2017 15:04
@Jell I have some feedback, but I don't have time to write it down now. Maybe tonight.
Jean-Louis Giordano
@Jell
Nov 04 2017 15:27
looking forward to it @jolod
Erik Svedäng
@eriksvedang
Nov 04 2017 17:01
Reading!
"Maybe this will come as a shocker, but Haskell IO is pure by convention. " -- to anyone who reads the article and understands the second part of the sentence, it's probably not a shocker, right?
Jean-Louis Giordano
@Jell
Nov 04 2017 17:02
you mean it's perhaps unnecessarily adversarial?
I should probably rephrase that, re-reading this part in isolation feels like unnecessary emphasis
Erik Svedäng
@eriksvedang
Nov 04 2017 17:03
yeah, I think the article is advanced enough to scare off anyone who is not already pretty familiar with Haskell
which is fine, I really like the idea of the article
I also think you need to add some extra verbs and things in some places, like "Not possible in the general case..." should probably be "This is not possible in the general case..."
"future so still not foolproof" => "future, so it's still not fool proof"
I like the conversational tone though
Erik Svedäng
@eriksvedang
Nov 04 2017 17:09
s/maintenable/maintainable
Jean-Louis Giordano
@Jell
Nov 04 2017 17:12
I've added some verbs, removed the shocker and fixed the typos :+1:
Erik Svedäng
@eriksvedang
Nov 04 2017 17:15
I'll tell you if I find something more to complain about :)
Jean-Louis Giordano
@Jell
Nov 04 2017 17:15
please do!! :)