04:21 <jemc> hm.. maybe the docstring for Promise.join should mention Promises.join?

04:22 <jemc> I remember in the RFC process I had a similar thought that Promise.join was not super convenient if you were starting with a flat array of promises, and that's why Promises.join was added - so it seems that adding a reference in the docstring could help make Promises.join more discoverable

04:26 <jemc> autodidaddict: nice blog post! after reading through it, I wanted to mention a small refactor that you might find makes your code more convenient

04:28 <jemc> I notice that your `Player.gathername` accepts the promise as a parameter, so the caller has to build the promise and pass it in - you probably did this because actor behaviours can't have return values

04:28 <jemc> however, there's a pattern I sometimes use which makes things a bit more convenient for the caller

04:28 <jemc> instead of using a behaviour, as you do now - https://github.com/autodidaddict/ponymud/blob/9a501aa403208e1c263810bfc5e09d4fce97157d/std/player.pony#L40-L41

04:30 <jemc> use a `fun tag`, which builds the promise object, passes it to a *private behaviour*, and returns the promise

04:30 <jemc> ironically, a good example of this pattern is `Promise.join` itself - https://github.com/ponylang/ponyc/blob/ec8342476faae3f5c6d6dfa31824c8e1a25c4c16/packages/promises/promise.pony#L201-L210

04:31 <jemc> offhand, we might say that you can only call asynchronous behaviours on an actor, and never synchronous methods, but this isn't strictly true - because the actor reference you hold is a `tag`, you actually can call synchronous `fun tag` methods

04:32 <jemc> however, the catch is that a `fun tag` method still has to treat the actor as opaque - no access to the actor's internal state

04:33 <jemc> so it's only really useful as a convenience wrapper in situations like these, where you want to wrap a call to one or more behaviours, and return something to the caller (a promise is common here)

04:33 <jemc> anyway, just mentioning it because I thought you mind find it useful to employ - have fun!

05:13 <doublec> jemc, autodidact: I had the same thought re "fun tag" https://pastebin.com/HNi3YZbz

05:14 <doublec> it's such a useful pattern some syntax for it would be nice

05:15 <doublec> If a behaviour takes a promise you can somehow call it such that it does the "create promise, call, return" for you.

16:23 <ada[m]> Hm. Is there anything in the stdlib for checking structural equality of arrays and maps?

16:23 <ada[m]> or even just arrays

16:26 <SeanTAllen> Not that I am aware of

16:35 <jemc> ada[m]: I don't think it was possible in pony to provide such a facility builtin to generics until relatively recently (the introduction of `iftype`)

16:35 <jemc> or at least, to provide a meaningful and useful angle on such a facility

16:35 <jemc> because the type argument of an `Array` is not necessarily `Equatable` with itself

16:37 <endformationage> jemc: Great convenience trick re the building of the promise on the actor that fulfills them.

16:37 <jemc> endformationage: thanks! :)

16:39 <ada[m]> That's what I figured. Just seems like a likely "pain-point" for many people using pony, so I wondered if I was missing something.

16:39 <jemc> ada[m]: so now that we have `iftype`, it would be possible to build a generic `Array.eq` that uses structural equality of the elements, if the element type was `Equatable`, and fall back to using `is` (identity equality) for the elements if they are not `Equatable`

16:39 <jemc> same with `string` and `Stringable`

16:40 <ada[m]> jemc: Hm. I might take a stab at that. Would such an addition need to go through RFC?

16:40 <endformationage> jemc: BTW, your mentioning code generation a few times has made me curious. Is the generation from within Pony? Are there some examples you can point me to look at?

16:40 <jemc> ada[m]: yes, it's an RFC I've been meaning to write for some time now, but haven't had the time to allocate to it yet - if you wanted to take up the cause that would be excellent

16:41 <jemc> endformationage: not sure exactly what you mean by "within Pony", but I can explain what I've done so far, and what I want to be able to do in the future

16:42 <jemc> currently, what I'm doing is creating a Pony program that upon execution will write Pony source code to its stdout, which I direct to be written to a file using a `Makefile` task

16:42 <endformationage> Sure, I'm simply not familiar with it, though I have some understanding of macros from haxe.

16:43 <jemc> that is, the code generation program just outputs the source code that gets included in the program that I'm actually trying to make

16:43 <endformationage> I see.

16:43 <jemc> this is an (admittedly, somewhat ugly) example of such a program: https://github.com/jemc/ponycc/tree/master/ponycc/ast/gen

16:44 <ada[m]> https://github.com/ponylang/pony-tutorial/issues/213 given that the implementation of iftype isn't yet, complete, does it make sense to build things in the stdlib on top of it yet?

16:45 <endformationage> jemc: thanks, I'll check it out!

16:45 <jemc> endformationage: the example I gave is used to generate the complex classes that represent a Pony AST in the pony-in-pony compiler I'm working on

16:45 <jemc> the definitions of the AST types is in this file: https://github.com/jemc/ponycc/blob/master/ponycc/ast/gen/ast_defs.pony

16:46 <jemc> which uses the `ASTGen` class to declare a bunch of AST types, and the `ASTGen` class handles converting those to the pony source code

16:47 <jemc> however, this isn't where I want to end, as the code generation process is still error-prone, and all the string concatenation and formatting is a pain to deal with

16:48 <jemc> so the next step in the evolution, ironically, is to actually use the AST classes from the ponycc project to build up the AST for your source code programmatically, and dump that AST to a string, instead of building up the string

16:49 <jemc> basically, taking away the concern of the code generator for generating the human-readable pony source, and just have it create the AST, and let the AST be printed as human-readable source

16:50 <jemc> that should actually be possible to do today, if someone wanted to try it, give or take a few missing pieces from AST printing, and some pain points around building AST that come from a lack of array inference (which is what I'm actively working on fixing in ponyc at the moment)

16:51 <jemc> (see https://github.com/ponylang/ponyc/issues/2094 for progress tracking)

16:51 <jemc> so, that's the near future of code generation

16:52 <jemc> the distant future is actually having some kind of hygienic macro system built in to the compiler (Elixir-style), which is something I want to build into ponycc after I've finished duplicating the features of ponyc (which is somewhat of a long way off as well)

16:53 <jemc> ada[m]: the current extent of iftype should be suitable enough to continue with the RFC, I think

16:53 <jemc> there are some things missing and usability pain points around iftype, but this particular feature should be able to steer clear of those

17:10 <endformationage> jemc: Inspiring stuff!

17:19 <etc> Hi! I'm trying to compile a C file and then call it from pony - this is the c compilation (https://gist.github.com/charlesetc/09692b620c3084ec7de5dd70a3a8ce53) - and in pony I have `use "lib:stars_extension"` but get the error `/usr/bin/ld.gold: error: cannot find -lstars_extension` when running ponyc. I'm definitely unsure of how to use the linker properly - does anyone know what I'm doing wrong?

17:21 <Praetonus> etc: You have to use the `--path` flag when invoking ponyc to specify where to look for the library file

17:23 <etc> Praetonus: thanks! just tried `--path .` and `--path `pwd`` but still got the linking error

17:24 <Praetonus> I think it's `path=directory`

17:24 <Praetonus> Er, `--path=directory` rather

17:25 <etc> Hmm same thing :/

21:04 <doublec> Is the value dependant type work still ongoing?

21:07 <Praetonus> doublec: Luke Cheeseman is still working on it on his spare time. Sylvan might have some additional details

21:14 <jemc> the repo is here: https://github.com/lukecheeseman/ponyta

21:15 <jemc> speaking objectively, the most recent commit was almost one year ago, but I don't have the context to know if work is still ongoing more recently (and just not being pushed to github at the moment)

21:23 <doublec> Praetonus: thanks

21:24 <doublec> jemc: I would imagine that merging a year old code base is a lot of work

21:54 <jemc> speaking in the abstract, yes - however, I'm not in the loop on the full context here, and there may be other factors I'm not aware of (like a pile of commits that hasn't been pushed to github, or a pile of changes that haven't been committed yet)

21:54 <jemc> if anyone is especially interested, you might try emailing luke directly