Conversation

Oct 9, 2021

Yeah I want to see more languages that let you run and experiment with broken code!

stephenjohnlimb

@stephenjohnlimb

Use REPL for snips of stuff. But I can’t see the point of trying to run code that is known to be broken. But yes use REPL for the bit you think is right. Or are you saying you need to put a break point in just before the broken bit so you can work out something?

Yeah, the elaborator would generate something like a 'ReportedIssue' node when a problem is encountered. This crashes the program if it is run, which would allow you to still experiment with the program while it's in a partially correct state.

GHC has something similar with `-fdefer-type-error`, for example.

stephenjohnlimb

@stephenjohnlimb

So for Haskell you’ve got the mechanism, if I understand correctly. For dynamic languages like JavaScript or Python you can just try it out, much like a BASH script. So which languages would you suggest should have this capability?

7:40 AM · Oct 10, 2021Twitter Web App

I'm suggesting for statically typed languages like Rust, OCaml, SML, Scala, Java, Idris, Lean, etc. Languages where types are required as a part of understanding the meaning of a program. Put another way, languages that are intrinsically typed (as opposed to extrinsically typed).

Hmm I can see why

said this added complexity. It would probably trigger a chain of unresolved types/calls results. This might mean that in many circumstances it still would not be possible to execute. You might have to introduce an ‘unresolved type’ as a holder.

Replying to

and

What do you mean by ‘a holder’? I'm also not sure what you mean be a chain of unresolved types? Do you mean during type checking?

Replying to

and

Well let’s say that we had an error where a call you made did not return the type you stated it would. Ie a compiler error. But we put this to one side. The type you declared clearly does not exist. We’d have to put a place holder in there to ‘shore up’ the code.

stephenjohnlimb

@stephenjohnlimb