by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Veit Heller
    @hellerve
    just fyi for y’all: i’ll be unavailable for a week starting tomorrow, and i’ll be back next sunday (in 9 days)
    Scott Olsen
    @scolsen
    Hopefully because you're doing something fun :D ?
    Veit Heller
    @hellerve
    i’ll spend a week on an island vacationing and celebrating a friend’s wedding, so yes, very much!
    Scott Olsen
    @scolsen
    Nice!
    Erik Svedäng
    @eriksvedang
    Very nice, have fun!
    Tim Dévé
    @TimDeve
    Enjoy Veit, I'm flying back to my parents for the week. Looking forward to spend some times somewhere else than my flat.
    Basile Pesin
    @Vertmo
    I'm having a bit of trouble with the load / Project.config system. In order to work on separate compilation, I have given a project name to core (via (project-config "name" "core") in the file Core.carp. The issue is, this file is actually loaded when compiling any code, which means that a code sample that does not provide a name gets the core name (this is the case for any of the tests, which actually makes the test suite fail). Is this a desired behavior ? I dont know if Project.config should be restricted to only have effect in the "main" file of a project ? Otherwise I dont see a solution
    Scott Olsen
    @scolsen
    Ah yeah--it's a bit confusing, I've run into this before myself. Unfortunately, loading in a file with Project.config declarations will force them upon the user
    why do you need to give it a project name? I think loading and all that works just fine without setting Project.config
    Basile Pesin
    @Vertmo
    Well, in my tinkering for separate compilation, I use the project name to name intermediate c files that are generated (.o and .h). I could of course also not name it, generate an Untilted.h and Untitled.o, and mv them through the Makefile. I think that will be my workaround ^^
    Hum, although I also use the title for some other stuff, so that's not ideal :/
    Scott Olsen
    @scolsen
    Ah, gotcha! Hm, yeah, maybe we should invest in changing the behavior of Project.config calls somehow? Seems like it'd be generally useful to be able to use it for libraries in other cases without having to worry about overwriting a user's settings
    Erik Svedäng
    @eriksvedang
    Yeah, sounds like something we should solve.
    Basile Pesin
    @Vertmo
    Should I open an issue about it ?
    Erik Svedäng
    @eriksvedang
    Yes please!
    Tim Dévé
    @TimDeve
    I feel like someone did this before but I couldn't find it so I did this:
    https://github.com/TimDeve/enum/blob/master/test/enum.carp
    Adds defenum for when you don't need to full power of sumtypes. Implements =, str & parse.
    We should probably document that better :)
    Tim Dévé
    @TimDeve
    But it doesn't implement =, str & parse
    I mean str is implemented but it's wrapped in parentheses
    Erik Svedäng
    @eriksvedang
    Aha ok
    Scott Olsen
    @scolsen
    Neat!
    Veit Heller
    @hellerve
    Huh, that‘s nice, @TimDeve. Maybe we could have a parse interface generally? Like read in Haskell?
    Tim Dévé
    @TimDeve
    I was surprised it didn't exist actually.
    Veit Heller
    @hellerve
    It should probably emit a maybe, though
    Carp doesn‘t really have that much string parsing code in core
    Erik Svedäng
    @eriksvedang
    would be a great feature
    there's one issue that's kinda related here: carp-lang/Carp#753
    Tim Dévé
    @TimDeve
    Went with a result as that seemed more semantically correct to me.
    Veit Heller
    @hellerve
    if we need to emit error messages that’s better anyway. otherwise maybe Maybe isn’t the best name for something that either succeeds and produces a result, or fails and produces none, but i think that’s fairly common for optional-style types
    i have a distaste for using them for errors (i.e. produces Nothing when it fails or (Just error) when it works), but that seems to happen occasionally also
    if we find a better names for those cases maybe we can add type aliases once we have them
    Tim Dévé
    @TimDeve
    @eriksvedang Rereading this issue I'm not sure what I had in mind. Probably allowing tuples rather replacing structs with named fields.
    Scott Olsen
    @scolsen
    How's everyone doing?! I took a brief summer break but I'm excited to start working a bit on Carp again. Anyone have opinions as to what the biggest feature requests or bugs we need to address are? Maybe we should just start churning through issues?
    Tim Dévé
    @TimDeve
    For me nested types and custom destructor are the features I miss the most. I've had trouble coding after work lately I hope I'll find the energy soon...
    Erik Svedäng
    @eriksvedang
    Hi! I’m on vacation, trying to stay off the computer best as I can :smile: But I’ll review / merge PRs of course.
    I think solving stability issues should be top priority, but whatever tickles your fancy..!
    Veit Heller
    @hellerve
    nested types as in recursive?
    Tim Dévé
    @TimDeve
    Yeah that's what I meant, I know it's labeled as "Hard" but it would make json parsing much easier.
    I mentioned custom destructor because I feel it creates an escape hatch when there is a language limitation (implement in C and add a custom destructor to do the cleanup.)
    This was more of a "wishlist" thing btw. Not saying these two things should be the priority.
    Veit Heller
    @hellerve
    yeah, i think both of those are good for language usability
    Scott Olsen
    @scolsen
    sounds good! I would like recursive data types as well, so I’ll try to tackle that
    Scott Olsen
    @scolsen
    making some progress on recursive data types...I’ve tried to make changes that will make the type system more extensible in general too so that itll hopefully be easier to add things like dependent types etc. in the future should we want them
    Veit Heller
    @hellerve
    nice! that sounds awesome
    Erik Svedäng
    @eriksvedang
    Exciting!!!
    Veit Heller
    @hellerve
    that looks super comprehensive
    Scott Olsen
    @scolsen
    Really interesting! Subtyping lattices were used in one of the early papers on refinement types--this approach looks pretty promising!