enilsen16 has quit [Quit: Connection closed for inactivity]
khan has quit [Quit: khan]
khan has joined #ponylang
khan has quit [Client Quit]
khan has joined #ponylang
jemc has quit [Ping timeout: 240 seconds]
jemc has joined #ponylang
jemc has quit [Ping timeout: 248 seconds]
khan has quit [Quit: khan]
khan has joined #ponylang
khan has quit [Client Quit]
khan has joined #ponylang
khan has quit [Quit: khan]
khan has joined #ponylang
sternmull has joined #ponylang
khan has quit [Client Quit]
khan has joined #ponylang
khan has quit [Quit: khan]
khan has joined #ponylang
SenasOzys has quit [Read error: Connection reset by peer]
khan has quit [Client Quit]
khan has joined #ponylang
sternmull has quit [Ping timeout: 240 seconds]
vaninwagen has joined #ponylang
vaninwagen has quit [Ping timeout: 276 seconds]
nisanharamati has quit [Quit: Connection closed for inactivity]
khan has quit [Quit: khan]
khan has joined #ponylang
gokr has joined #ponylang
khan has quit [Client Quit]
khan has joined #ponylang
_whitelogger has joined #ponylang
khan has quit [Quit: khan]
khan has joined #ponylang
khan has quit [Client Quit]
khan has joined #ponylang
vaninwagen has joined #ponylang
ShalokShalom has joined #ponylang
<ShalokShalom>
hi these
<ShalokShalom>
*there
gokr has left #ponylang [#ponylang]
<ShalokShalom>
I see that you put a lot of attention onto runtime safety
<ShalokShalom>
why is the scheduler not preemptive then?
khan has quit [Ping timeout: 265 seconds]
khan has joined #ponylang
khan has quit [Quit: khan]
khan has joined #ponylang
khan has quit [Client Quit]
khan has joined #ponylang
khan has quit [Remote host closed the connection]
codec1 has joined #ponylang
codec1 has quit [Client Quit]
SenasOzys has joined #ponylang
sternmull has joined #ponylang
sternmull has quit [Max SendQ exceeded]
sternmull has joined #ponylang
sternmull has quit [Max SendQ exceeded]
sternmull has joined #ponylang
sternmull has quit [Max SendQ exceeded]
sternmull has joined #ponylang
sternmull has quit [Max SendQ exceeded]
vaninwagen has quit [Ping timeout: 264 seconds]
sternmull has joined #ponylang
vaninwagen has joined #ponylang
sternmull has quit [Ping timeout: 276 seconds]
khan has joined #ponylang
khan has quit [Client Quit]
khan has joined #ponylang
alxs has joined #ponylang
khan has quit [Quit: khan]
khan has joined #ponylang
khan has quit [Client Quit]
khan has joined #ponylang
ein_ has joined #ponylang
ein_ is now known as einStrauch
<einStrauch>
hello~
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
alxs has joined #ponylang
_andre has joined #ponylang
<vaninwagen>
einStrauch: hi
<einStrauch>
hmm going through the pony stdlib docs, it seems to me that the idiomatic(?) way of extending a class or a set of classes is to write a wrapper class ye?
<einStrauch>
is there no other way to externally add methods to a class or primitive?
<vaninwagen>
well, there are interfaces
<einStrauch>
sure but those only work off of the methods that are already there no?
<vaninwagen>
but other than that, there is no way. this is a deliberate decision. you would design your objects to use composition
<einStrauch>
lets say i'd want to write an interface to emulate the Functor typeclass of Haskell, which needs a type-specific implementation of map
<vaninwagen>
einStrauch: yes, exactly, this approach is limited to ading functionality in terms of existing methods
<einStrauch>
not the iterator kind of map, but the CT kind of map
<einStrauch>
hmm
<einStrauch>
that does seem quite limiting
<einStrauch>
why not allow for traits to be implemented post-creation á la rust or what have?
<einStrauch>
why not allow for traits to be implemented post-creation á la rust or what have you?
<vaninwagen>
hmmm... wait a moment
khan has quit [Ping timeout: 256 seconds]
aturley has joined #ponylang
<vaninwagen>
einStrauch: what about something like this? https://is.gd/bi2dSx treating List as a Functor, as it already implements map
<einStrauch>
ye but that's not extendable to builtins no
<einStrauch>
i mean, for this specific instance you could probably piggyback on itertools but i was more interested in a general solution
<vaninwagen>
you could write specific interfaces for specific types that implement the map in terms of what is already there.
<einStrauch>
yee but that's a teeny tiny bit ugly xp
<vaninwagen>
but yes, this approach is a little limiting
<einStrauch>
ye
<einStrauch>
i mean it was more a theoretic concern either way
<vaninwagen>
the ideal case would be if the builtin classes would support the basic CT traits properly
<einStrauch>
well the ideal case would be if classes were easily extendable in a safe manner
<vaninwagen>
einStrauch: in case you want to bring some category theory to pony, consider me as very interested
<einStrauch>
i'm a big fan of open types in general
<einStrauch>
it'd deffo be an interesting endevor i think
<einStrauch>
i wonder if you'd get away with simply a Category wrapper tho
<vaninwagen>
i would bet :)
<vaninwagen>
have to run now, but will check back later
<einStrauch>
p much answered my questions so thanks xp
<einStrauch>
and have fun~
vaninwagen has quit [Ping timeout: 264 seconds]
<SeanTAllen>
einStrauch: you can define any interface after the fact
<SeanTAllen>
not really sure exactly what you mean by: "08:56 <einStrauch> why not allow for traits to be implemented post-creation á la rust or what have you?"
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
<SeanTAllen>
traits are nominal typing therefore you cant create a new trait and then say "this applies to existing classes" because its nominal
<SeanTAllen>
interfaces are structural so you can do that. you can define an interface and use any existing class that matches that interface to satisfy code that requires said interface.
<einStrauch>
well the "issue" (if you want to call it that) with interfaces is that you have to work off the methods that a given type already implements
<einStrauch>
and with "implement traits after the fact" i meant something along the lines of
<einStrauch>
the benefit of this would be that traits can be implemented ad-hoc without needing to write a wrapper class
<einStrauch>
so the implementation feels more "native", if that makes sense
<einStrauch>
as said, it's not a strict requirement, it's just an ergonomics thing i think
jemc has joined #ponylang
<SeanTAllen>
how is that different than subtyping?
<SeanTAllen>
what happens if my trait has a method name that already exists on the class i've extended with it?
<SeanTAllen>
there's a ton of possible complexity hiding in that simple example
Praetonus has joined #ponylang
<SeanTAllen>
i think it could make for an interesting RFC but would require a lot of thought for "edge cases"
<einStrauch>
the difference is that, if you have a class and a trait in the same namespace, the methods of the trait could be invoked on the class without the class requiring prior knowledge of the trait
<einStrauch>
you can kind-of-sort-of do that with an interface, but again an interface has the issue of not being able to use private methods or fields
<einStrauch>
and if a trait-method and a class method conflict, i think it should produce a compiler error
<einStrauch>
same for if two traits define the same method and both get is-ed by a class i suppose
<einStrauch>
and ye it was just a fleeting thought
<einStrauch>
or like, open question
<einStrauch>
i come with primarily a common-lisp background where extending classes is v v easy
<SeanTAllen>
an RFC for the issue that attempts to address the more complicated issues would be interesting
<einStrauch>
ye i agree
<einStrauch>
i'll think about it more and try to get my thoughts on this more structured
<SeanTAllen>
i would worry that it now means for nominal subtyping, i can no longer look at a class definition and know the nominal types
<SeanTAllen>
because it happens somewhere else
<Praetonus>
einStrauch: There is an issue with being able to use private methods/fields from an external extension, which is that there is no way to guarantee that invariants won't be broken
<einStrauch>
hmm
<SeanTAllen>
that's a classic subtyping problem
<einStrauch>
i mean from the compilers view, where is the difference to that and just copy-pasting the trait-implementation into the class itself?
<einStrauch>
i can understand issues with fragmantation of definitions tho
<einStrauch>
that would require a lot of careful documentation if used
<Praetonus>
Methods implemented in traits can't access any field
<einStrauch>
o, ye, this is not what i'm aiming at
<einStrauch>
the idea is to be able to ad-hoc implement methods required for a trait without needing to actually edit the class itself
<einStrauch>
like to get back to the previous example, you need to associate specific implementations of map to specific types to construct a functor out of the whole shebang
<einStrauch>
the implementation of map is not an implementation of a trait-method, but of a class-method that the trait needs to work
<einStrauch>
conceptually it is exactly like copy-pasting the code out of the extent-block and into the class
<SeanTAllen>
So we are talking about the expression problem, yes einStrauch ?
<einStrauch>
p much
<einStrauch>
again i'm spoiled by multimethods that don't run into this issue :/
<SeanTAllen>
Yeah if you dont have multimethods, the way to solve it would be "Object Algebra" which I'm not sure how to incorporate directly into the language.
<SeanTAllen>
I have a write up of a pattern to do it in Pony but haven't finished it so it hasnt ever been merged to Pony Patterns:
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
<einStrauch>
ye this seems decent enough as a solution
<einStrauch>
i think
alxs has joined #ponylang
enilsen16 has joined #ponylang
khan has joined #ponylang
alxs_ has joined #ponylang
alxs has quit [Ping timeout: 264 seconds]
alxs has joined #ponylang
alxs_ has quit [Ping timeout: 276 seconds]
einStrauch has quit [Quit: Page closed]
alxs_ has joined #ponylang
alxs has quit [Ping timeout: 256 seconds]
SenasOzys has quit [Read error: Connection reset by peer]
alxs_ has quit [Ping timeout: 240 seconds]
alxs has joined #ponylang
Praetonus has quit [Ping timeout: 256 seconds]
alxs_ has joined #ponylang
alxs has quit [Ping timeout: 264 seconds]
Praetonus has joined #ponylang
alxs_ has quit [Client Quit]
sternmull has joined #ponylang
Praetonus has quit [Ping timeout: 276 seconds]
jemc has quit [Ping timeout: 246 seconds]
nisanharamati has joined #ponylang
Praetonus has joined #ponylang
jemc has joined #ponylang
ShalokShalom has quit [Ping timeout: 240 seconds]
alxs has joined #ponylang
user10032 has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
<jemc>
@Praetonus - how feasible do you think it would be to extend `iftype` to let me change what fields are defined for a type, based on the reification of type parameters?
<jemc>
(that is, to be able to use `iftype` in a class definition context, outside of a function definition context)
<jemc>
what kinds of trouble do you think I'd get into trying to implement that?
sternmull has left #ponylang [#ponylang]
alxs has joined #ponylang
endformationage has joined #ponylang
<Praetonus>
jemc: Shouldn't be too hard. You'd just have to be careful to disallow accessing an iftype'd field in an unconstrained context
<jemc>
cool, I may give it a try this weekend
vaninwagen has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
alxs has joined #ponylang
xllndr has joined #ponylang
alxs has quit [Ping timeout: 248 seconds]
alxs has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
alxs has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
_andre has quit [Quit: Lost terminal]
jemc has quit [Read error: Connection reset by peer]