stdlib collection improvements

[alex-s168]

• tons of generic collection ops
• fix vector
• add test for vector (which currently fails because of some unrelated issue)
• vector remove-back, remove-front, and functions to convert U8 vectors to strings
• HashtableEq iterator
• CString iterator
• "zip", "enumerate", "skip" iterator
• to-smart-string for F64
• generic serialization (currently only JSON backend)
• Closes Remove buffer.lm and replace with Vector #1057
• list available frontends if none found
• other features

blockers

• some compiler bugs

TODO

• BLOB (de)serialization (as base64 in json)

[andrew-johnson-4]

For standard library, I am trying to avoid fully templated type signatures like: let .contains(self: t, value: e): U64 = (

Instead there should be at least a parameterized type, and hopefully a generic if possible: i.e. List<t>.

There are a couple reasons for this:

• these methods pollute the global namespace (any time somebody uses ".contains" this will pop up)
• these templates make incremental compilation harder, they probably need to be compiled from scratch each time
• error messages for these types of functions are currently abysmal and probably won't be ever be great
  • can be improved with stack traces for errors, but I don't want to depend on that entirely

For example, there is currently a print : x function in libraries that needs to be fixed. That method can specialize on itself and cause the compiler to crash with no relevant error message.

[andrew-johnson-4]

• make collection ops more generic

I understand where this is coming from. In your .contains method it is very generic, which is good, but it is too generic.

"Make everything as simple as possible, but not simpler"

In this case the .contains method depends on

• a .length method or field
• a [] array-style indexing operator

However there is nothing in the type signature of the .contains method that indicates that.

If we wanted to go forward with this design, I would suggest creating an interface type Container or similar. That Container would assert that there is a .length method and also that there is an [] array-style indexing operator.

Interfaces don't exist at the type system level, but they would need to exist before I move this into the standard library. Otherwise, having implicit duck-typing in the standard library feels weird.

[andrew-johnson-4]

Function Application Yielded An Irreducible Plurality Of Matches
==
With Arguments Cons<U8+LMStruct+I64+I32+I16+U64+U32+U16+LocalVariable+Sized,Constant+Literal+U8+LMStruct+I64+I32+I16+U64+U32+U16+Sized>

This error message can be improved, because it only needs to show the ambiguous matches, not the whole list. However, this problem is a bit sticky.

== : (U8,U8) -> Bool

matches a lot of comparisons because of the numerical pyramid
U8 => U8+I64+I32+I16+U64+U32+U16

The correct case to pick is (U8,U8) -> Bool, however it is getting confused because of contravariance I think.

[andrew-johnson-4]

Hmm, not the culprit. I have to look into this.

[andrew-johnson-4]

Ok, this is a library problem. The generic == : (x, x) -> Bool function is garbage and causing all sorts of problems.

[andrew-johnson-4]

I improved the error message for ambiguous method resolution.

However when I try to compile your changes with the main compiler, I get "interfaces are currently not supported". It looks like you were implementing features on your branch and then got stuck. For me, without those features, I can't reproduce the error without path dependence.

Suspicions:

• does the tests/regress/numerical-pyramid.lsts test pass on your branch idk
• maybe you are building off of an outdated branch before that test started working?
• this is a sensitive, somewhat recent feature, so it definitely could be a bug in core, I just can't reproduce

Recommendations:

• break your PR into smaller pieces
• I do see some things that could be merged into my branch before going "all in one go"

[alex-s168]

interfaces are currently not supported

regarding the "interfaces are currently not supported": I just removed that fail from the parser and made it ignore interfaces for now