CoCoA » CoCoA-5

This is how some lines in BuiltinOneLiners would look

DECLARE_COCOALIB_FUNCTION1(factorial, INT)
DECLARE_COCOALIB_FUNCTION2(NewQuotientRing, RING, IDEAL)
DECLARE_COCOALIBFORC5_FUNCTION2(GetCol, MAT, INT)

DECLARE_STD_BUILTIN_FUNCTION(LT, 1) { // AMB
    int which;
    intrusive_ptr<RightValue> v = runtimeEnv->evalArgAsT1orT2orT3orT4<RINGELEM, MODULEELEM, IDEAL, MODULE>(ARG(0), which);
  switch (which) {
  case 1: return Value::from(LT_forC5(PtrCastRINGELEM(v)));
  case 2: return Value::from(LT_forC5(PtrCastMODULEELEM(v)));
  case 3: return Value::from(LT(PtrCastIDEAL(v)));
  default:return Value::from(LT(PtrCastMODULE(v)));
  }
}
END_STD_BUILTIN_FUNCTION

John Abbott wrote:

I'm not entirely convinced by the names PtrCastIDEAL etc.
It is true that the arg is a "pointer" (boost::intrusive_ptr), but the result is a reference (yet the name suggests to me that the result should be a pointer). Also the result is (a ref to) a CoCoALib type, but the capitalized names suggest CoCoA-5 types (it is true that the arg is effectively an object of the named CoCoA-5 type).

true: it is clearer with the return type.

Here are some other possible names:
RefToBigInt

I like that! even shorter than PtrCastBigInt

First pass is mostly done (BigIntValue --> INT, and similar).

I'm a bit undecided about a few other types like OSTREAM (because it's used also in Lexer)
There is a CppOstreamValue I can't understand right now...

Another possible name is UnwrapBigInt. I think it conveys the idea that the BigInt is hidden inside the objects passed as argument, and that the result is a reference to that same object (rather than a copy).

I'm tempted to suggest use of templates: i.e. the function would actually be called unwrap<BigInt>. It is almost an abuse of templates because each specific function has to be defined separately (at least with the current design a generic template definition is not possible). But it somehow "feels right" that the name of the type be given as a template parameter... It is probably also a bit easier to read.

What do you think?

Now all switch following EvalArgAsT1or... have a default case giving and error.
This is good for maintenance: if we add some extra type and forget to write the appropriate case, it will give a meaningful error.

added templates for RefTo<..>.