Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Types as Interfaces

two-wrongs.com

Post reply on HN
Print view View original

191–197 of 197 posts

Re: Types as Interfaces

#191

Post by auggierose »

agentultra wrote: post #189
auggierose wrote: post #187

Earlier quoted context omitted.

I have trouble parsing your sentence, to be honest. What are you asking? Are you asking how am I sure that/if my specification is correct? Are you asking how do I make sure I have no bugs without a proof? Maybe you are asking something else entirely?

Because the type system is unsound, you could add an error to your implementation and the type system will not catch it. It will happily tell you that everything type checks. How do you use that to prevent errors?

Yes, that can happen. Just as a sound type system will also not prevent all possible bugs. So what? TypeScript's type system helps me to prevent many bugs by performing standard sanity checks, and is a very practical tool.

Just rephrase your question as "How will a pervasive system of sanity checks help me prevent errors?", and I hope you agree that it kind of answers itself.

Re: Types as Interfaces

#192

Post by anamax »

user3939382 wrote: post #33

I’ve come to believe that a type should be capable of reflecting any arbitrary rules a programmer knows about the bounds of a value. The only real implementations of this I see are mostly academic with a dependent type system like Idris. We’re many years from that becoming mainstream, if it ever will be.

That sounds like you're using "type" to mean "representation", albeit with a lot of detail.

I may be odd, but my programming problems are rarely due to the number of bananas or how bananas are represented, but whether I'm working with the correct bananas.

Re: Types as Interfaces

#193

Post by eddd-ddde »

valcron1000 wrote: post #143
spankalee wrote: post #110

This is a lot of complication for in what most OOP languages with interfaces would simply be something like: interface Timestamped { timestamp: UTCTime; } interface Msg { sender: PlayerId; } class Quote implements Timestamped, Msg { timestamp: UTCTime; sender: PlayerId; } Why is this so hard in Haskell? It doesn't have interface polymorphism?

It's not hard at all and it's actually what the second approach listed by the author shows: class HasRecipient a where get_receiver :: a -> PlayerId which adjusted to your example would be class Timestamped a where timestamp :: a -> UTCTime The problem with this approach is that you'll have duplicated data on all instances. In your example, `Quote` has the fields `timestamp` and `sender` in order to satisfy with `Tim…

Doesn't PHP solve this with traits?

IIRC you can have traits automatically implement this sort of behavior with a centralized implementation.

Re: Types as Interfaces

#194

Post by mahguy »

derdi wrote: post #11
posix_monad wrote: post #3

MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…

OCaml's first-class modules allow you to do this: https://ocaml.org/play#code=bW9kdWxlIHR5cGUgRk9PID0gc2lnCiAg...

The most consistent solution with the least ceremony. Now it is a module, not a type though.

Re: Types as Interfaces

#195

Post by mjarrett »

posix_monad wrote: post #3

MLs require a lot of ceremony modelling simple record types. What we want to express here is an object with a map of properties (name to type): string Type map For the OOP minded: Map And also compose those: type Foo = { "_foo", int } type Bar = { "_bar", string } type FooBar = mergeMaps Foo Bar But at compile-time, of course. Have any languages achieved this? I know TypeScript can do some of these things, but it's c…

Hence, Objective Caml! This can be modeled in OCaml as an object type,

  type foo_bar =
For a family of types matching any object with those methods, I think you can write something like

  type 'a has_foo_bar =  as 'a

Re: Types as Interfaces

#196

Post by derdi »

mahguy wrote: post #194
derdi wrote: post #11

Earlier quoted context omitted.

OCaml's first-class modules allow you to do this: https://ocaml.org/play#code=bW9kdWxlIHR5cGUgRk9PID0gc2lnCiAg...

The most consistent solution with the least ceremony. Now it is a module, not a type though.

You can create first-class values of this module type, and since values have types, "it" is a type. Specifically, my_foobar has type (module FOOBAR).

Actually getting values out of such a module-typed structure does involve some ceremony, however:

    let f =
      let module M = (val my_foobar) in
      M.foo
Post reply on HN