[9fans] Typestr usage (inspired by libgeometry)

[9fans] Typestr usage (inspired by libgeometry)

[sirjofri via 9fans]

Hi,

I just had a quick thought about using typestr in libgeometry. However, I noticed that typestr is nowhere used in 9front at all (besides the compiler that implements it as a feature).

Thinking about how typestr provides pretty cool syntactic sugar, I was wondering why that's the case? Is there a goal to maintain the C standard as far as it makes sense, or is it compatibility between plan 9 systems?

Before thinking about it too much, I just ask here.

I personally only use it in some cases where it makes sense, in cases similar to the complex number example I was able to find online[1]. I don't think it should be used to hide things, just to provide the ability to write code that's easier to read and understand. For example, instead of combining matrices using functions, I could just type S * R * S, or to add vectors, I can just V + W. For plan 9, adding Points would be trivial.

Note that I'm _not_ proposing to update all of the routines to use this feature. I'd just like to know your thoughts about using it (or not using it).

sirjofri

[1] https://github.com/henesy/plan9-typestr/blob/master/typestr.md

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T7ee24291af957db7-Mef119b70a4fc76a5d0ac4486
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Typestr usage (inspired by libgeometry)

[ori]

Quoth sirjofri via 9fans <9fans@9fans.net>:
> Hi,
> 
> I just had a quick thought about using typestr in libgeometry. However, I noticed that typestr is nowhere used in 9front at all (besides the compiler that implements it as a feature).
> 
> Thinking about how typestr provides pretty cool syntactic sugar, I was wondering why that's the case? Is there a goal to maintain the C standard as far as it makes sense, or is it compatibility between plan 9 systems?
> 
> Before thinking about it too much, I just ask here.
> 
> I personally only use it in some cases where it makes sense, in cases similar to the complex number example I was able to find online[1]. I don't think it should be used to hide things, just to provide the ability to write code that's easier to read and understand. For example, instead of combining matrices using functions, I could just type S * R * S, or to add vectors, I can just V + W. For plan 9, adding Points would be trivial.
> 
> Note that I'm _not_ proposing to update all of the routines to use this feature. I'd just like to know your thoughts about using it (or not using it).
> 
> sirjofri
> 
> [1] https://github.com/henesy/plan9-typestr/blob/master/typestr.md
>

It's a subtly wrong feature -- it looks cute, but doesn't
generalize well in C. Finishing it would imply garbage
collection (or at least destructors), which have their
own disadvantages.

It may work for some things. This, for example, is fine:

        typestr mpint ...;

        mpint *x = mpnew(42);
        mpint *y = mpnew(123);
        mpint *z = x * y; //ok, fine
        mpfree(x);
        mpfree(y);

but what about:

        mpint *x = mpnew(42);
        mpint *y = mpnew(123);
        mpint *z = x * (y - x) * (y - x);
        mpfree(x);
        mpfree(y);

There are intermediate expressions along the way
which would need to be allocated; who frees them?


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T7ee24291af957db7-Med8867431e94207a85d17a06
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Typestr usage (inspired by libgeometry)

[sirjofri via 9fans]

16.12.2025 17:19:26 ori@eigenstate.org:
> Quoth sirjofri via 9fans <9fans@9fans.net>:
> It's a subtly wrong feature -- it looks cute, but doesn't
> generalize well in C. Finishing it would imply garbage
> collection (or at least destructors), which have their
> own disadvantages.
>
> It may work for some things. This, for example, is fine:
>
>         typestr mpint ...;
>
>         mpint *x = mpnew(42);
>         mpint *y = mpnew(123);
>         mpint *z = x * y; //ok, fine
>         mpfree(x);
>         mpfree(y);
>
> but what about:
>
>         mpint *x = mpnew(42);
>         mpint *y = mpnew(123);
>         mpint *z = x * (y - x) * (y - x);
>         mpfree(x);
>         mpfree(y);
>
> There are intermediate expressions along the way
> which would need to be allocated; who frees them?

Well, that makes a lot of sense. I guess I never encountered these issues because I only used it with smaller structures that I can easily copy (by value). A feature like that should accommodate for the whole language though, which it can't. Thanks for clarifying that.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T7ee24291af957db7-M28284f002852fd0b205cd5ec
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Typestr usage (inspired by libgeometry)

[Skip Tavakkolian]

if you restricted the typestr to integral types (or composition of
integral types), would there be any garbage collection issues?

On Tue, Dec 16, 2025 at 8:19 AM <ori@eigenstate.org> wrote:
>
> Quoth sirjofri via 9fans <9fans@9fans.net>:
> > Hi,
> >
> > I just had a quick thought about using typestr in libgeometry. However, I noticed that typestr is nowhere used in 9front at all (besides the compiler that implements it as a feature).
> >
> > Thinking about how typestr provides pretty cool syntactic sugar, I was wondering why that's the case? Is there a goal to maintain the C standard as far as it makes sense, or is it compatibility between plan 9 systems?
> >
> > Before thinking about it too much, I just ask here.
> >
> > I personally only use it in some cases where it makes sense, in cases similar to the complex number example I was able to find online[1]. I don't think it should be used to hide things, just to provide the ability to write code that's easier to read and understand. For example, instead of combining matrices using functions, I could just type S * R * S, or to add vectors, I can just V + W. For plan 9, adding Points would be trivial.
> >
> > Note that I'm _not_ proposing to update all of the routines to use this feature. I'd just like to know your thoughts about using it (or not using it).
> >
> > sirjofri
> >
> > [1] https://github.com/henesy/plan9-typestr/blob/master/typestr.md
> >
> 
> It's a subtly wrong feature -- it looks cute, but doesn't
> generalize well in C. Finishing it would imply garbage
> collection (or at least destructors), which have their
> own disadvantages.
> 
> It may work for some things. This, for example, is fine:
> 
> typestr mpint ...;
> 
> mpint *x = mpnew(42);
> mpint *y = mpnew(123);
> mpint *z = x * y; //ok, fine
> mpfree(x);
> mpfree(y);
> 
> but what about:
> 
> mpint *x = mpnew(42);
> mpint *y = mpnew(123);
> mpint *z = x * (y - x) * (y - x);
> mpfree(x);
> mpfree(y);
> 
> There are intermediate expressions along the way
> which would need to be allocated; who frees them?
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T7ee24291af957db7-M69777688ed15e9c6bf1d4793
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Typestr usage (inspired by libgeometry)

[Matthew Veety]

On 16/12/2025 10:35 am, sirjofri via 9fans wrote:
> Thinking about how typestr provides pretty cool syntactic sugar, I was wondering why that's the case? Is there a goal to maintain the C standard as far as it makes sense, or is it compatibility between plan 9 systems?

I thinks it's a mix of lack of awareness and the hidden function calls, 
I've used this quite a bit and there are some problems with 
maintainability because it hides what you're doing, though it can make 
code easier to write, especially things like typecasts.

On 16/12/2025 11:17 am, ori@eigenstate.org wrote:
> It's a subtly wrong feature -- it looks cute, but doesn't
> generalize well in C. Finishing it would imply garbage
> collection (or at least destructors), which have their
> own disadvantages.

This was years ago so I'm likely misremembering, but there was someone 
(I think qrstuv?) that added destructors and something like Go's defer 
to the compiler. The destructor didn't add any syntax to the compiler as 
is just would call a function defined similarly to the rest of the 
typestr methods. It worked pretty well for what is was. I don't remember 
how (or if) it handled the hidden allocations needed for intermediate 
values in expressions though.

-- 
Veety

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T7ee24291af957db7-Mdd9e0d5ebbed465269a7b017
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Typestr usage (inspired by libgeometry)

[arnold]

Down this path lies C++ constructors and destructors, and likely
additional mess.  For example, stack allocation of a point - who
initializes the members? Etc, etc.

It's probably best not to mess with it, as it's a non-standard
extension.

My two cents.

Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:

> if you restricted the typestr to integral types (or composition of
> integral types), would there be any garbage collection issues?
>
> On Tue, Dec 16, 2025 at 8:19 AM <ori@eigenstate.org> wrote:
> >
> > Quoth sirjofri via 9fans <9fans@9fans.net>:
> > > Hi,
> > >
> > > I just had a quick thought about using typestr in libgeometry. However, I noticed that typestr is nowhere used in 9front at all (besides the compiler that implements it as a feature).
> > >
> > > Thinking about how typestr provides pretty cool syntactic sugar, I was wondering why that's the case? Is there a goal to maintain the C standard as far as it makes sense, or is it compatibility between plan 9 systems?
> > >
> > > Before thinking about it too much, I just ask here.
> > >
> > > I personally only use it in some cases where it makes sense, in cases similar to the complex number example I was able to find online[1]. I don't think it should be used to hide things, just to provide the ability to write code that's easier to read and understand. For example, instead of combining matrices using functions, I could just type S * R * S, or to add vectors, I can just V + W. For plan 9, adding Points would be trivial.
> > >
> > > Note that I'm _not_ proposing to update all of the routines to use this feature. I'd just like to know your thoughts about using it (or not using it).
> > >
> > > sirjofri
> > >
> > > [1] https://github.com/henesy/plan9-typestr/blob/master/typestr.md
> > >
> > 
> > It's a subtly wrong feature -- it looks cute, but doesn't
> > generalize well in C. Finishing it would imply garbage
> > collection (or at least destructors), which have their
> > own disadvantages.
> > 
> > It may work for some things. This, for example, is fine:
> > 
> > typestr mpint ...;
> > 
> > mpint *x = mpnew(42);
> > mpint *y = mpnew(123);
> > mpint *z = x * y; //ok, fine
> > mpfree(x);
> > mpfree(y);
> > 
> > but what about:
> > 
> > mpint *x = mpnew(42);
> > mpint *y = mpnew(123);
> > mpint *z = x * (y - x) * (y - x);
> > mpfree(x);
> > mpfree(y);
> > 
> > There are intermediate expressions along the way
> > which would need to be allocated; who frees them?
> > 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T7ee24291af957db7-M475a63249e2f414db20473bd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription