Totally agree about the guarding problem. Software complain if pieces does not fit together is something good.
Even stronger typing do in many cases make sense. Creating voltage, current, temperature, angle and linear length types is some examples. Put a temperature value where an angle value is expected will rarely if ever make sense. Some programming languages even have types with limited range. Nicklas Karlsson sön 2026-06-07 klockan 14:57 +0200 skrev Bertho Stultiens: > If I may add,... It was mentioned that HAL was an abstraction layer. > > Indeed it is a /hardware/ abstraction layer. It is not a /type/ > abstraction layer. HAL in LCNC is meant to provide a homogeneous > interface to the processes and the users. It is not designed to make > everything look like porridge. > > There is nothing in hardware abstraction that demands abstracting the > types as well. On the contrary, you want a strongly typed system to > prevent conversions you do not _explicitly_ want. > > It also doesn't matter that a large part of LCNC uses floating point > calculation. It is that part that uses floating point in the > communication too. And, yes, there will be type conversions, but they > are explicit and not implicit. > > Another issue is guarding. > Control and indicator pins are usually integer or boolean and you should > not be able to connect those to non-control or non-indicator pins. > Removing the HAL type system, by making everything floating point, will > open the floodgates for a complete new set of (risky) failure modes > where pins can be connected wrongly that is not possible today. Sure, > you can do it wrong today, but lowering the bar for creating errors is > conceptually wrong. Actually, you may want to go the other way and > create an even stronger typing than today. > _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
