9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: ori@eigenstate.org
To: 9fans@9fans.net
Subject: Re: [9fans] Typestr usage (inspired by libgeometry)
Date: Tue, 16 Dec 2025 11:17:49 -0500	[thread overview]
Message-ID: <9B381DFBBE425AD6AD846363E0251600@eigenstate.org> (raw)
In-Reply-To: <624d190a-c592-49db-8223-67802389697e@sirjofri.de>

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

  reply	other threads:[~2025-12-16 16:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16 15:35 [9fans] Typestr usage (inspired by libgeometry) sirjofri via 9fans
2025-12-16 16:17 ` ori [this message]
2025-12-16 18:25   ` sirjofri via 9fans
2025-12-16 19:32   ` Skip Tavakkolian
2025-12-17 12:03     ` arnold
2025-12-17  0:29   ` Matthew Veety

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9B381DFBBE425AD6AD846363E0251600@eigenstate.org \
    --to=ori@eigenstate.org \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).