search

Spicery / Nutmeg

A language that kicks the ball between the legs of functional and imperative programming
GNU General Public License v3.0
3 stars 0 forks source link

Add, Sub, Multiply and Less-Than-Or-Equal-To #42

Open sfkleach opened 3 years ago

sfkleach commented 3 years ago

As a coder, I can use the +, *, - and <= operators in my programs.

philallen117 commented 3 years ago

You have probably thought of this because of Ginger ...

Will Nutmeg support overloading? Will that be purely static resolution? (I suppose not, if you want static analysis to be optional.) If dynamic, will it be part of some CLOS-like ad hoc polymorphism? (Or made to look that way for built-in types?)

Will Nutmeg support implicit conversion among built-in numeric types?

I can see the value of implicit conversion in scripting languages for casual use, but not for 'investment' software and not for teaching. And for teaching purposes, supporting overloading for a few built-ins but no more generally (e.g. Pascal) always struck me as a bit messy. I actually don't mind the .something operators in ML.

sfkleach commented 3 years ago

Will Nutmeg support overloading? Will that be purely static resolution? (I suppose not, if you want static analysis to be optional.)

My personal view is that static overloading is pure evil, disrupting the basic purpose of naming and leads to a dramatic decline in productivity. The only use case for static overloading is to reuse the same set of symbols that have well-established meanings attached - especially +, * and /. As you rightly point out, it conflates type checking with resolution, which is means that parsing files independently is impossible. It's horrible. My attitude is that the benefits are perhaps worth one or two points and the disadvantages come in at about 50 to 100 points (or an order of magnitude higher).

Although I try to keep an open mind, I think that door would need some impressive arguments to open. And if we're keen on reusing symbols I am inclined to want to do the whole thing properly and start looking at category theory.

If dynamic, will it be part of some CLOS-like ad hoc polymorphism? (Or made to look that way for built-in types?)

I tend to see it as being part and parcel of methods, which are fundamentally a way of writing condition tables - obviously where the conditions typically relate to input types. If you have another suggestion I am pretty interested. But I think the answer is, at the moment, yes.

Will Nutmeg support implicit conversion among built-in numeric types?

My preference is that rationals and floats are kept distinct, so there is no implicit conversion between them. There would be implicit conversion between the different rational types but I definitely could be persuaded to keep them separate too. I see the / operator as converting arguments to floating point before doing fp division - and reserving // for rational division. Integer division would be accessible via the divmod operator that returns quotient and remainder. But keeping them distinct leads to some quite unhappy consequences that would need ironing out.

For practical purposes I would be inclined to have types such as: Num for exact arithmetic and Float for floating point, inexact arithmetic. Maybe??? Not sure how complex numbers would fit in but following this general style I would probably integrate them into Float as the whole point is that the complex field extends the real field.

I can see the value of implicit conversion in scripting languages for casual use, but not for 'investment' software and not for teaching. And for teaching purposes, supporting overloading for a few built-ins but no more generally (e.g. Pascal) always struck me as a bit messy. I actually don't mind the .something operators in ML.

Not sure what the .something operators are :(

One thing we would need to discuss, I suspect, is the value of a fixed-bit width arithmetic. I personally don't see that types such as int32 and int64 actually have any role in typical application software. What the heck do you use them for - apart from crypto??

But I am equally convinced that fixed-bit width arithmetic needs to be supported - but it has to be supported properly, so that we can properly work with the values as bit arrays. However, it's critically important that we do that level of detail properly, so we distinguish signed and unsigned arithmetic and also support non-standard widths (because only doing a handful of bit-widths is very annoying.) I have been working with fixed-bit width arithmetic very heavily for the past few years and I seriously miss a decent library.