Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #391294 > unrolled thread

Bart's Language

Started bybart <bc@freeuk.com>
First post2025-03-17 23:51 +0000
Last post2025-03-21 00:33 +0000
Articles 2 on this page of 62 — 13 participants

Back to article view | Back to comp.lang.c


Contents

  Bart's Language bart <bc@freeuk.com> - 2025-03-17 23:51 +0000
    Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 12:17 +0000
      Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 13:54 +0000
        Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 15:10 +0000
          Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 15:45 +0000
            Re: Bart's Language David Brown <david.brown@hesbynett.no> - 2025-03-18 17:31 +0100
              int a = a (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-18 18:04 +0000
                Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 19:36 +0100
                  Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-18 19:11 +0000
                  Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 15:56 +0100
                    Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:38 +0000
                      Re: int a = a (Was: Bart's Language) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-19 14:29 -0700
                        Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 09:39 +0100
                          Re: int a = a (Was: Bart's Language) bart <bc@freeuk.com> - 2025-03-20 11:59 +0000
                            Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:46 +0100
                              Re: int a = a (Was: Bart's Language) wij <wyniijj5@gmail.com> - 2025-03-20 23:13 +0800
                      Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:02 -0700
                        Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:57 +0100
                    Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-19 17:07 +0000
                    Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 13:34 -0700
                      Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:54 -0700
                        Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 03:20 -0700
                          Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 16:22 +0100
                            Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:46 -0700
                              Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 10:44 +0100
                                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-21 12:23 -0700
                                  Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 21:46 +0100
                                  Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 13:59 -0700
                                    Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-22 15:37 -0700
                                      Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-28 09:39 -0700
                          Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-29 13:12 -0700
                            Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-29 13:34 -0700
                      Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 15:42 +0100
                Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 19:37 +0000
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-18 20:51 +0100
                  Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 23:27 +0100
                    Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:40 +0100
                Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-18 23:52 -0700
                  Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 01:55 -0700
                    Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 13:41 -0700
                  Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:43 +0100
                  Re: int a = a (Was: Bart's Language) Rosario19 <Ros@invalid.invalid> - 2025-03-19 13:23 +0100
                    Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 01:32 -0700
            Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:55 +0000
              Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 16:22 -0700
                Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 14:37 +0000
                  Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 11:41 -0400
                    Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 16:52 +0000
                      Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 20:12 -0400
                    By definition... (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-23 17:20 +0000
                Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 11:53 -0700
                  Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-27 14:29 -0700
                    Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 14:04 -0800
                      Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-06 17:12 -0800
                        Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 09:04 -0800
          Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 22:19 +0000
            Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:38 +0000
              Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 23:45 +0000
                Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:56 +0000
                  Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-21 17:47 +0000
                    Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 07:12 -0700
              Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:33 +0000

Page 4 of 4 — ← Prev page 1 2 3 [4]


#391504

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2025-03-22 07:12 -0700
Message-ID<86msddkvbp.fsf@linuxsc.com>
In reply to#391476
Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2025-03-21, bart <bc@freeuk.com> wrote:
>
>> On 20/03/2025 23:45, Kaz Kylheku wrote:
>>
>>> On 2025-03-20, Waldek Hebisch <antispam@fricas.org> wrote:
>>>
>>>> bart <bc@freeuk.com> wrote:
>>>>
>>>>> In this case, just write it like that, and only adjust it for the
>>>>> somewhat different syntax:
>>>>>
>>>>>    func foo:int =
>>>>>        let int c := c1(10)
>>>>>        let int b := c + c2(2)
>>>>>        let int a := b+c3(c)
>>>>>        bar()
>>>>>        baz()
>>>>>        return c
>>>>>    end
>>
>>    >> In your description you wrote that declarations can be written
>>
>>>> "out of order" and compiler will rearrange them in correct
>>>> order.  That looked like great opportunity to write obfuscated
>>>> code.
>>>
>>> I made a language feature like that:  mlet.
>>>
>>> https://www.nongnu.org/txr/txr-manpage.html#N-2B3072E9
>>>
>>> This allows for circular references in order to support
>>> the construction of lazy objects:
>>>
>>> 1> (mlet ((a (lcons 1 b))
>>>            (b (lcons 0 a)))
>>>      (take 20 a))
>>> (1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0)
>>
>> I don't understand what's going on above;  the example here is a
>> bit clearer, other than that z at the end:
>
> What's going on is that  [...]

Just a short reminder that this is comp.lang.c, and nothing about
any of the discussions above has anything to do with C.

[toc] | [prev] | [next] | [standalone]


#391456

Frombart <bc@freeuk.com>
Date2025-03-21 00:33 +0000
Message-ID<vric47$c9ev$1@dont-email.me>
In reply to#391446
On 20/03/2025 22:38, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 18/03/2025 15:10, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>> On 18/03/2025 12:17, Waldek Hebisch wrote:
>>>>> bart <bc@freeuk.com> wrote:
>>>>>>
>>>>>> This is the document I produced:
>>>>>>
>>>>>> https://github.com/sal55/langs/blob/master/MFeatures.md
>>>>>>
>>>>>> A couple of more substantial demo programs are here:
>>>>>> https://github.com/sal55/langs/tree/master/MExamples
>>>>>>
>>>>>> (The bignum.m file was ported - by hand - to the bignum.c version that I
>>>>>> posted recently.)
>>>>>
>>>>> Looking at features, can you say if the program below works?
>>>>> And if it works, what is retrun value of foo?  "Equvalent" can
>>>>> be written in C, but in C you have to keep sane order.
>>>>
>>>>
>>>> There were some tweaks needed; it indicates some basic info missing from
>>>> my write-up! (For example, that the function call needs to be bar() not
>>>> bar; 'const' is only for compile-time expressions; and that C's 'const'
>>>> doesn't exist - it only briefly mentions an attempt at 'let'.)
>>>>
>>>> The revised code is shown below, with what I assumed were your
>>>> intentions.
>>>
>>> Well, my intentions beter correspond to the C version below:
>>>
>>> int foo() {
>>>       const int c = c1(10);
>>>       const int b = c + c2(2);
>>>       const int a = b+c3(c);
>>>       bar();
>>>       baz();
>>>       return c;
>>> }
>>
>>
>> In this case, just write it like that, and only adjust it for the
>> somewhat different syntax:
>>
>>    func foo:int =
>>        let int c := c1(10)
>>        let int b := c + c2(2)
>>        let int a := b+c3(c)
>>        bar()
>>        baz()
>>        return c
>>    end
> 
> In your description you wrote that declarations can be written
> "out of order" and compiler will rearrange them in correct
> order.

I made a decision to allow out-of-order definitions for all names, and I 
followed through with that. That is useful for:

* Function definitions
* Types and records (usually mutually referential ones)
* Named compile-time-constants
* Enumerations
* Macros
* FFI Import declarations
* Module-level variables

So, you just don't need to worry about it. Inside the top-level scope of 
a module for example, such a mix of definitions all exist 
simultaneously; there is no ordering.

All the above are defined using '=', which is a compile-time concept 
(variables either are not initialised so are all-zeros, or use '=' too 
at module scope).

However, you've picked on local variables inside a function, where 
assignments/initialisations are done with ':=', a runtime operation. 
Hence there is a ordering to those assignments, even if the variable 
/names/ that are defined exist function-wide and are unordered with 
respect to other names in the scope.


> That looked like great opportunity to write obfuscated
> code.

Sorry, it's not quite up to the standard of C, where:

* There are unlimited numbers of block scopes within each function

* So the same name A can be reused in each one, with a different type

* Scopes can start part-way through a block, so two different A's can
co-exist within the block

* There are parallel struct/enum tag and label namespaces, so that A can 
also be a struct A or enum A or A: in the same scope:

     int A; {++A; struct A {int A;} A; A: A=A; goto A;}

* If that is not quite enough, you can define parallel instances of A 
but in lower case 'a'.

I haven't even had to call upon macros for extra obfuscation!

> As you explained, it works differently, but I think
> already the fixed version of code I gave shows potential.
> And the following seem to satisfy your restriction that
> 'const' is compile time constant and what happens is
> puzzling to the reader (better than goto-s used to confuse
> control flow):
> 
> func foo:int =
>      const a = b + c
>      let int cc := c1(a)
>      const b = c + 2
>      let int bb := c2(b) + cc
>      const c = 10
>      bb + c
> end

Here's an actual use-case from an older C compiler project. It's some 
lines from a table of type-enums with parallel arrays:

     (tschar,        "schar",    8,  1,  tsint),
     (tsshort,       "short",    16, 1,  tsint),
     (tsint,         "int",      32, 1,  0,   ),
     (tsllong,       "llong",    64, 1,  0,   ),

The left column is enums used to denote C types inside the project.

The last column starting 'tsint' specifies what narrow types expand to 
in an expression.

Notice that 'tsint' is an enum name which is itself not specified until 
a couple of lines later. This is out-of-order definitions in action.

What obfuscations are needed in C to achieve the same? Maybe X-macros, 
or defining discrete arrays which need to be kept in sync. Maybe all 
sorts of other workarounds.


[toc] | [prev] | [standalone]


Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c


csiph-web