home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 263,049 of 264,096   
   =?UTF-8?Q?Arne_Vajh=C3=B8j?= to Dan Cross   
   Re: extending MySQL on VMS   
   19 Aug 25 11:10:37   
   
   From: arne@vajhoej.dk   
      
   On 8/19/2025 10:09 AM, Dan Cross wrote:   
   > In article <1081sk3$3njqo$7@dont-email.me>,   
   > Simon Clubley   wrote:   
   >> On 2025-08-18, Dan Cross  wrote:   
   >>>   
   >>> I happen to disagree with Simon's notion of what makes for   
   >>> robust programming, but to go to such an extreme as to suggest   
   >>> that writing code as if logical operators don't short-circuit   
   >>> is the same as not knowing the semantics of division is   
   >>> specious.   
   >>   
   >> That last one is an interesting example. I may not care about   
   >> short circuiting, but I am _very_ _very_ aware of the combined   
   >> unsigned integers and signed integers issues in C expressions. :-(   
   >>   
   >> It also affects how I look at the same issues in other languages.   
   >>   
   >> I've mentioned this before, but I think languages should give you   
   >> unsigned integers by default, and you should have to ask for   
   >> a signed integer if you really want one.   
   >   
   > Whether integers are signed or unsigned by default is not   
   > terribly interesting to me, but I do believe, strongly, that   
   > implicit type conversions as in C are a Bad Idea(TM), and I   
   > think that history has shown that view to be more or less   
   > correct; the only language that seems to get this approximately   
   > right is Haskell, using typeclasses, but that's not implicit   
   > coercion; it takes well-defined, strongly-typed functions that   
   > do explicit conversions internally, from the prelude.   
   >   
   > But that's Haskell.  For most programming, if one wants to do   
   > arithmetic on operands of differing type, then one should be   
   > required to explicitly convert everything to a single, uniform   
   > type and live with whatever the semantics of that type are.   
   >   
   > This needn't be as tedious or verbose as it sounds; with a   
   > little bit of type inference, it can be quite succinct while   
   > still being safe and correct.   
      
   Kotlin is rather picky about mixing signed and unsigned.   
      
   var v: UInt = 16u   
      
   v = v / 2   
      
   gives an error.   
      
   v = v / 2u   
   v = v / 2.toUInt()   
      
   works.   
      
   I consider that rather picky.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca