Coverage of intrinsics and builtins

[shashi]

Currently the Defaults (both Basic and Numeric put together) don't cover all the built-ins. We should try and support all of these, so other rules can build on top of a solid default tracer (basically the whole language).

It seems like the @abstract definitions are currently provided at a higher level than builtins and intrinsics, so we can check off those that the higher level defs cover in a reasonable way.

Builtins

• Core.IntrinsicFunction
• Core.var"##invoke" #unsure what this is
• <:
• ===
• Core._apply
• Core._apply_iterate
• Core._apply_latest
• Core._apply_pure
• Core._expr
• Core._typevar
• Core.apply_type
• Core.arrayref
• Core.arrayset
• Core.arraysize
• Core.const_arrayref
• Core.sizeof
• Core.svec
• applicable
• fieldtype
• getfield
• ifelse
• invoke
• isa
• isdefined
• nfields
• setfield!
• throw
• tuple
• typeassert
• typeof

Intrinsics

• abs_float
• add_float
• add_float_fast
• add_int
• add_ptr
• and_int
• arraylen
• ashr_int
• bitcast
• bswap_int
• ceil_llvm
• cglobal
• checked_sadd_int
• checked_sdiv_int
• checked_smul_int
• checked_srem_int
• checked_ssub_int
• checked_uadd_int
• checked_udiv_int
• checked_umul_int
• checked_urem_int
• checked_usub_int
• copysign_float
• ctlz_int
• ctpop_int
• cttz_int
• div_float
• div_float_fast
• eq_float
• eq_float_fast
• eq_int
• flipsign_int
• floor_llvm
• fma_float
• fpext
• fpiseq
• fpislt
• fptosi
• fptoui
• fptrunc
• le_float
• le_float_fast
• llvmcall
• lshr_int
• lt_float
• lt_float_fast
• mul_float
• mul_float_fast
• mul_int
• muladd_float
• ne_float
• ne_float_fast
• ne_int
• neg_float
• neg_float_fast
• neg_int
• not_int
• or_int
• pointerref
• pointerset
• rem_float
• rem_float_fast
• rint_llvm
• sdiv_int
• sext_int
• shl_int
• sitofp
• sle_int
• slt_int
• sqrt_llvm
• sqrt_llvm_fast
• srem_int
• sub_float
• sub_float_fast
• sub_int
• sub_ptr
• trunc_int
• trunc_llvm
• udiv_int
• uitofp
• ule_int
• ult_int
• urem_int
• xor_int
• zext_int

Misc

• print
• println

[femtomc]

As far as simple contributions go, would you be open to have exterior users implement some of these in lib?

[MikeInnes]

Yes, adding coverage would be great. I think it would be good to continue the pattern we've followed so far of making the higher-level signatures (e.g. Number * Number) primitives rather than the intrinsics directly.