20:38 <strmpnk> Are there good examples for the AmbientAuth being used with a more specific capability?

20:38 <strmpnk> I see it in places like HTTPClient but I'm not sure I see the intention there.

20:42 <strmpnk> It seems like it could have interesting limits on the runtime expression of an API but I wonder why it was applied here is all.

20:45 <strmpnk> I guess I could ask a more pointed question: are object capabilities intended to be used here to create certain guarantees around API expression, including security?

20:46 <strmpnk> Theoretically meaning I could have a pony library that can't to random IO without explicit passing of one kind of authority or another which can build the required authority.

20:47 <jemc> yes, I think that's a reasonable understanding of the intention

20:48 <jemc> Pony has roots in capabilities-based security: https://en.wikipedia.org/wiki/Capability-based_security

20:49 <jemc> there's a basic example of this in `net/auth.pony`: https://github.com/ponylang/ponyc/blob/master/packages/net/auth.pony

20:50 <jemc> basically, creating a tree of primitives that can only be accessed if you have one of the permissions higher up the tree

20:50 <jemc> so that capabilities can only decay, and never escalate, as enforced by the type system

20:51 <strmpnk> Cool. I've read about E and I've built capability based APIs but the static guarantees are interesting so I wasn't sure if there were more reasons for this feature.

20:52 <jemc> there's also a more complex example in `FileAuth`, where holding an object grants you authority to do some file-based operations on a specific path, and subpaths of it: https://github.com/ponylang/ponyc/blob/master/packages/files/file_path.pony

20:54 <strmpnk> Random second question, since classes allocate space for a descriptor, I assume there is no way to allocate a collection of classes without the descriptor. With that assumption, is it frowned upon to use structs outside of the FFI when I might want more specific memory layout?

20:55 <strmpnk> Ah. I like the FilePath example.

20:55 <jemc> I'm curious - what context outside of FFI do you want a specific memory layout?

20:57 <strmpnk> Well, not entirely free of the FFI but it'd be useful to have contiguous memory for structs for things which are lazily serialized.

20:58 <strmpnk> The lack of tags unfortunately monomorphize the structs but an example where this is handy is an mmaped file with relative offsets for data (lets say, a big graph).

20:58 <jemc> hm, I may be misremembering, but I *think* that an Array of structs will give you a contiguous memory of struct *pointers*, but the struct members themselves won't be in contiguous memory

20:59 <strmpnk> Yeah. I've been told they work like "in C".

21:01 <strmpnk> sidenote: Though I do see some problems with the FFI on windows (set aside for now since I have other things to look into). I'll work on getting something here but I think LLVM is generating invalid calls even though the 64bit calling convention should be compatible.

21:01 <strmpnk> (lldb is unfortunately not very capable on windows, so I need to find another way to debug that issue)

21:02 <strmpnk> On linux though, it works like I've been told.

21:04 <jemc> ah, interesting

21:05 <jemc> if you can file a ticket with more info, we can ask somebody from the windows side of our community to help you take a look

21:06 <jemc> meanwhile, if your goal is to have a specific memory layout, I don't think it's an anti-pattern to use structs

21:06 <jemc> it's usually an anti-pattern when someone wants to do so for a different reason

21:06 <jemc> but just remember that with structs you miss out on a few type system features

21:07 <strmpnk> Yeah. Lots of polymorphism goes out the window since safety is required.

21:08 <strmpnk> Tweeting about Pony I get followers like: https://mobile.twitter.com/carolinetowning Lots of pretty horse art.