by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Karthik Viswanathan
    @karthikv
    Let me know if you run into any other troubles!
    Conrad Steenberg
    @hengestone
    Sure, thanks!
    Conrad Steenberg
    @hengestone
    Hi Karthik - I finally had a chance to compile a few programs, and really like the style you came up with :+1:
    Karthik Viswanathan
    @karthikv
    Awesome Conrad, really glad to hear!
    Conrad Steenberg
    @hengestone
    I have a different question: would it be possible to adapt the tooling to become closer to stock Erlang than a separate language? I.e. do type inference etc without having to run Dialyzer etc ;-)
    The way that Coconut is more of an add-on to Python and can be incrementally adopted without throwing away all the standard Erlang goodness really appeals to me!
    Karthik Viswanathan
    @karthikv
    The main problem there is that it's very difficult to typecheck arbitrary Erlang constructs. That's why Dialyzer only checks what it can and doesn't do anything further
    Conrad Steenberg
    @hengestone
    ah, got it
    Karthik Viswanathan
    @karthikv
    Just curious, what things do you really like about Erlang that you miss in Par?
    Conrad Steenberg
    @hengestone
    I think the best answer is being part of the standard Erlang ecosystem that I'm used to, without resorting to FFI
    E.g. creating gen_servers
    Karthik Viswanathan
    @karthikv
    For sure, creating servers (and implementing behaviors in general) is something I have yet to implement in Par
    that's one of the big things on my list next
    FFI should basically act just like standard Erlang calls, though, so you should be able to use the ecosystem without much trouble
    Conrad Steenberg
    @hengestone
    Let me ask an orthogonal question: what are the arbitrary constructs in Erlang that are hard to typecheck?
    How about just having a strict parser that refuses to allow those?
    Karthik Viswanathan
    @karthikv
    I guess one issue there is the tooling, though. Par doesn't have a package manager that helps you fetch dependencies
    For instance, the receive construct. How do you know what format the messages will be in? There's no specification of what other processes can send you
    Everything in Erlang is designed to be dynamic
    Even something as simple as using apply to call a function whose module or name is computed can't be supported, since you don't know the type and arguments that said function requires until runtime
    Conrad Steenberg
    @hengestone
    Have you looked at Slogan?
    Karthik Viswanathan
    @karthikv
    The main point here is that Par restricts what you can do so that it can infer and typecheck (almost) everything
    Conrad Steenberg
    @hengestone
    Karthik Viswanathan
    @karthikv
    No, I haven't seen Slogan before
    Conrad Steenberg
    @hengestone
    So the reason I'm asking is that 1) I would really love to have type Inference and I think you did it in a really great way, and 2) Bootstrapping a new language is hard, and the technical part of it is only 20% of the problem
    Karthik Viswanathan
    @karthikv
    For sure, but languages are usually designed in a way that supports type inference, not the other way around
    Conrad Steenberg
    @hengestone
    For example, I'm doing a little learning project using gpb (protocol buffers) to generate structs and do typechecking/pattern matching that way
    Karthik Viswanathan
    @karthikv
    If you're trying to add type inference to an existing dynamic language, you can definitely achieve some success, but you need to resort to type annotations or restricting constructs to be very effective
    Great examples of that are Typescript and Flow
    Conrad Steenberg
    @hengestone
    Strict typing with type inference is very close to dynamic typing in most cases though, and having the option to use both is useful
    Karthik Viswanathan
    @karthikv
    It's ultimately a trade-off. Dynamic languages are amazing for just getting things done sometime, especially when the format of your data is complex and hard to model. Static languages can prevent a whole class of errors, but are often less expressive or more restrictive. Gradual typing like Dialyzer, Typescript, Flow, etc. try to achieve a middleground between the two, but a middleground also has the drawback of not being able to catch some errors
    Totally agree about your point (2) though, getting a new language off the ground is extremely difficult
    Would be great if Erlang could just have built-in type inference and checking, but alas, that would require fundamental changes to the language to make it work
    Conrad Steenberg
    @hengestone
    OK, how about this: Would you be interested in doing a project using your type inferencer to come up with an Erlang parse transform and syntax to as part of the standard toolchain? (only adding/preventing what is needed to make it work)
    Karthik Viswanathan
    @karthikv
    Unfortunately that's not something I can take on right now. Writing a type system with Hindley-Milner inference is quite complex, and adapting what I have to Erlang is both extremely difficult and likely to not work in many cases.
    Conrad Steenberg
    @hengestone
    Gotcha :)
    Karthik Viswanathan
    @karthikv
    Sorry about that Conrad, I am looking to make the experience of using Par as pleasant as possible though, and things like gen_servers, more stdlibs, and tooling are all planned
    Let me know if you have any further questions or if there's any way I can help out
    Conrad Steenberg
    @hengestone
    No worries! Wish you all the best
    Thanks!
    Doug Safreno
    @dsafreno
    ayo karthik - i think you
    *your website DNS is broken
    Screen Shot 2018-04-20 at 3.43.47 PM.png
    Karthik Viswanathan
    @karthikv
    @dsafreno thanks for the heads up! looking into it
    Doug Safreno
    @dsafreno
    :thumbsup: no pressure just figured i'd let you know
    Screen Shot 2018-04-20 at 3.47.07 PM.png
    seems to be changing
    Karthik Viswanathan
    @karthikv
    @dsafreno thanks a lot for catching this!! could you try again now?
    Doug Safreno
    @dsafreno
    looks good now!
    Karthik Viswanathan
    @karthikv
    great, thanks!! really appreciate you finding the problem :+1: