Groups | Search | Server Info | Login | Register

Groups > comp.os.vms > #378192

Re: Unsafe code blocks

From cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups comp.os.vms
Subject Re: Unsafe code blocks
Date 2025-11-19 19:00 +0000
Organization PANIX Public Access Internet and UNIX, NYC
Message-ID <10fl450$q2$1@reader2.panix.com> (permalink)
References <10f4oi1$25lkk$2@dont-email.me> <10fig54$1n41a$3@dont-email.me> <10fkq9g$8f$1@reader2.panix.com> <20251119192953.00005981@yahoo.com>

Show all headers | View raw

In article <20251119192953.00005981@yahoo.com>,
Michael S  <already5chosen@yahoo.com> wrote:
>On Wed, 19 Nov 2025 16:12:32 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> In article <10fig54$1n41a$3@dont-email.me>,
>> Arne Vajh_¸j  <arne@vajhoej.dk> wrote:
>> >On 11/18/2025 2:04 PM, Arne Vajh_¸j wrote:  
>> >> On 11/15/2025 9:16 PM, Dan Cross wrote:  
>> >>>> Also note the availability of the 'Valid attribute to make sure
>> >>>> that what
>> >>>> is in the variable after the unsafe conversion is actually a
>> >>>> valid value.  
>> >>>
>> >>> Sum types make this trivial:
>> >>>
>> >>> _ _ _ _  impl SomeType {
>> >>> _ _ _ _ _ _ _ _  fn try_from(i: i32) -> Option<Self> {
>> >>> _ _ _ _ _ _ _ _ _ _ _ _  // if valid, return `Some(whatever`),
>> >>> _ _ _ _ _ _ _ _ _ _ _ _  // else return `None`.
>> >>> _ _ _ _ _ _ _ _  }
>> >>> _ _ _ _  }  
>> >> (assuming Option in Rust is what it is in other languages)
>> >> 
>> >> Option and Ada Valid are somewhat different.
>> >> 
>> >> Option is a way for a function/method to either return
>> >> a value or return the fact that there is no value.
>> >> 
>> >> A much better way to do that than traditional
>> >> return null or -1 or whatever to indicate there
>> >> is no value.
>> >> 
>> >> Ada valid attribute is a runtime check on the result from
>> >> an unsafe conversion to see if it meets the constraints
>> >> of the data type.  
>> >
>> >Option is in fashion in recent years.  
>> 
>> Algebraic data types have been used in functional languages
>> since the 1970s, starting with the "Hope" language from
>> Edinburgh.  ML took them from Hope and popularized them, and
>> they leaked into Miranda, Haskell, and OCaml from there.  Now
>> many languages support them; even C++ (`std::optional`).
>> 
>> Hope was first described in a paper in 1980, but the work of
>> course predated that.
>> 
>> That makes them about as old as VMS, and older than Ada.  In
>> other words, they've been "In Fashion" since the 70s,
>
>That does not follow.
>Something existing for a long time is not the same as being fashionable
>for a long time.

That's a fair point, but it's also context dependent.  ADTs have
been fashionable for a while in some communities, though perhaps
not in others.  It depends on what kind of work you're doing and
what specific technologies you work with.

>Options became fashionable relatively recently, as result of growing
>dissatisfaction with previous fashionable item - exceptions.

Eh, now _this_ does not follow.  Options and exceptions are
orthogonal, and many languages that support one also support the
other.

>Parts of programming community that are less concerned with fashion of
>the day ignored both of this things. They use error codes, either in
>crude form (like C) or more refined (like Go).

C predates ADTs, of course, and likely wouldn't have adopted
them even if it didn't because of the constraints of its early
environment.

The situation with Go is a bit more complex, and in part comes
from not designing the language with support for generics from
the start (to really make effective use of ADTs, you pretty much
need parametric polymorphism over data types), and generics were
omitted because they weren't initially sure how to make them
work well with interfaces, which they were pretty bullish on.

But I would argue that the Go convention of returning a tuple
with an explicit `error` element and allowing a simple statement
to be nested beween the `if` and boolean expression, is closer
to a Maybe monad than C's overloading an `int`, or using one a
return value in combination with an out parameter or something
similar.

	- Dna C.

Back to comp.os.vms | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-13 14:04 +0000
  Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-13 15:44 -0500
  Re: Unsafe code blocks Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> - 2025-11-14 12:14 +0100
    Re: Unsafe code blocks John Reagan <johnrreagan@earthlink.net> - 2025-11-14 11:47 -0500
      Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 14:02 -0500
        Re: Unsafe code blocks Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> - 2025-11-17 09:25 +0100
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:58 -0500
            Re: Unsafe code blocks Chris Townley <news@cct-net.co.uk> - 2025-11-17 20:11 +0000
              Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 15:47 -0500
            Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-18 13:10 +0000
      Re: Unsafe code blocks Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-14 19:32 +0000
    Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 13:55 -0500
      Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 20:00 -0500
        Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 18:56 +0000
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:22 -0500
  Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-16 02:16 +0000
    Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 19:22 +0000
      Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:55 -0500
        Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 20:33 +0000
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 15:55 -0500
      Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-18 12:54 +0000
    Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-18 14:04 -0500
      Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-18 14:07 -0500
        Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 16:12 +0000
          Re: Unsafe code blocks Michael S <already5chosen@yahoo.com> - 2025-11-19 19:29 +0200
            Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 19:00 +0000
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 12:41 -0500
            Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 18:19 +0000
              Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 14:21 -0500
                Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 19:49 +0000
      Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 16:02 +0000
        Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 20:26 -0500
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 20:31 -0500
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 21:32 -0500
          Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-20 11:54 +0000
            Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-20 19:18 -0500
              Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-21 03:03 +0000

csiph-web