Re: on named blocks concept

Liste des GroupesRevenir à cl c  
Sujet : Re: on named blocks concept
De : fir (at) *nospam* grunge.pl (fir)
Groupes : comp.lang.c
Date : 06. Nov 2024, 23:43:05
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <672BF0F9.1010702@grunge.pl>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
Bart wrote:
On 06/11/2024 20:45, fir wrote:
Thiago Adams wrote:
On 06/11/2024 16:46, fir wrote:
Thiago Adams wrote:
On 06/11/2024 15:46, Thiago Adams wrote:
On 06/11/2024 13:04, fir wrote:
if c would have something that i name as named block
much more interesting options in coding in c would be
imo avaliable..
by named block i understood something like
>
foo {
   //code here
}
>
whiuch resembles function , as can be placed in 'global'
(module level) space but also could be placed locally in
functions
>
int foo() {
   a { }
   b { }
}
>
then it could be called internally
>
int foo() {
   a { }
   b { }
>
   int x = a()*a()*b(); //though imo () probab;ly should be
optionall
}
>
or externally
>
foo.a()
>
those blocks probably should have acces to local variables of
parent functions or parant block so it yelds imo to conclusion
that local variables and arguments should be by default static
(those stack variables by default are bad idea imo.. its kinda
optimisation
needed whan you got 4kb RAM but on bigger machines this optimisation
is bad imo)
>
if so mant things can be done with this blocks probably, im not
exactly
sure what exactly
>
ona assembly label blocks by defauld probably be done by
>
name:
   //...
   ret
>
  so then can be reused though some version to call it in place
  of definitions could be also avaliable imo (something like
  a{}() in a sense but better looking (this looks to bad)
>
  overally those named block should be also united with function
  so they become the same if use on them the functionality of
  passing arguments and returning variables
>
  foo {
    a {}
>
    int x, y = a(1,2)
  }
>
  though i maybe not sure how to add this mechanism
  possibly som,ething liek this (until something better could be
found)
>
  a
  {
   in int c;
   in int d;
   out int x = c+d;
   out int y = c-d;
  }
>
  or
  a( int c, int d)
  {
   out int x = c+d;
   out int y = c-d;
  }
>
as all c d x y are static you may call a() without any or
with any set int x, y = a(1) int x = a(1,2) and compiler
would generate the assigments (how to call it on assembly level us
wuite clear, not fully clear is what syntax in language to use
>
this concept is yet not fully build yet but what i descrbed her i
guess is okay
>
>
Names loops (only loops) were proposed to C2Y.
>
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
>
>
>
Sorry I thought your motivation was exit blocks.
I am not sure what is your motivation now, maybe lambdas? local
functions? long jump?
local jumps?
>
>
as to lambdas /closures im not sure as i never learned that concepts
(seem wierd and uglt) but maybe
as if you have blocks you could eventually pass blocks to functions
>
a {printf("\n %d", i)}
>
void foo(int n, block p)
{
   for(int i=0; i<n; i++) p();
}
>
foo(10,a);
>
>
its different than pointers as possibly block could have acces to
parent variables..but that would need to be rethinked as it generate
problems (like you eventually cant compile block a above as i is just
a name so this is more liek piece of text not a real code here
>
eventualy some coud do
>
a(int i) {printf("\n %d", i)}
>
void foo(int n, block p)
{
   for(int i=0; i<n; i++) p(i);
}
>
foo(10,a);
>
>
This is one of the lambda motivations.
>
>
>
maybe , but thsi is just a kinda detail here, as it is not so much
difference than passing pointer though it is a difference
>
(liek when you pass pointer code takes pointer and here if you pass blck
it acan be simpli compiled in in compile time (and thus it is possible
it can have acces to its all parent fuunction variables).. or may be
called in this "lambda " way as far as i remember that
>
repeat(10, {printf("zzz")} ); //when reepat is a functin that takes block
>
but as i said probbaly those blocks could be used for some more things
>
Some of this stuff, like local functions, is in gnu C.
>
Most other complex stuff, passing lamda functions, you will find in C++.
>
But unless it is already in gnu, or has been added to C23 (which may
take a decade to become common), C is not going to acquire any random
proposals that you make in threads like this.
>
At best you might modify one implementation to try out an idea.
>
I'm not really into either, but I have tried anonymous functions
(without closures) in my scripting language. Your example looks like
this (using near-identical syntax):
>
   proc myrepeat(n, body) =
       to n do
           body()
       end
   end
>
   proc main =
       myrepeat(10, {printf("zzz")})
   end
>
The lack of closures means the anonymous function inside {...} can't
access any stack-based names outside which are part of the enclosing
function.
>
>
normally this {printf("zzz")} cant acces not opnly stack based but any local variables imo... (by 'normally' i mean without breaking some
present default rules.. i mean it in fact aces any like
foo({printf("zzz%d%d%d",a,b,c)}); but it just mean it more work like c++
template which "lives" only before compilation - as here a,b,c are just texts which can be resolved at compile time to different things
- and this is not neccesart the thing im thinking about here (generally i prefer the constructs that live after compilation, but those eventually also could be considered
thoce stack based variables and arguments are bad for other reasons..
generally the amount of "tricks" compiler and programmer van do when
arguments and locals are by default static is much greater and
quite usable and imo programs coild eventually be probably faster
(i already wrote on this back then
for example i thing if you giot such wunstion
DrawText(10,10,"some");
wchich draw text beginnmh in 10 row 10th column of text console
then you eventually can call yhis function also like
DrawText(10,10,"some");
DrawText(" more");
which just skips the passing row and column and reuses its states
whch say last call set to end of previous writting
you also could have acces to them like DrawText.row
if they are stack based it seem it couldnt be probably done
its also more efective becouse you dont need that memory bandwidth to set thiose variables if you dont need to set them or bass them back
when you need or dont need to acces them
on definition side it needs hovever some syntax to allow that
its something like
DrawText(static int row , static int column , static char* text)
{
DrawText(  char* text)
{
  //code here
}
}
its liek two entry points when second just omits two assigments,
some things like that can be also done in earlier or later return at the
end when separate call to the same function can calculate more return
wariabl;es or less and as return values are static you may use not all

Date Sujet#  Auteur
6 Nov 24 * on named blocks concept31fir
6 Nov 24 `* Re: on named blocks concept30Thiago Adams
6 Nov 24  `* Re: on named blocks concept29Thiago Adams
6 Nov 24   +- Re: on named blocks concept1fir
6 Nov 24   `* Re: on named blocks concept27fir
6 Nov 24    +* Re: on named blocks concept5Thiago Adams
6 Nov 24    i`* Re: on named blocks concept4fir
6 Nov 24    i `* Re: on named blocks concept3Bart
7 Nov 24    i  `* Re: on named blocks concept2fir
7 Nov 24    i   `- Re: on named blocks concept1fir
7 Nov 24    `* Re: on named blocks concept21Bonita Montero
7 Nov 24     `* Re: on named blocks concept20fir
7 Nov 24      +* Re: on named blocks concept18Bonita Montero
7 Nov 24      i`* Re: on named blocks concept17fir
7 Nov 24      i `* Re: on named blocks concept16Bonita Montero
7 Nov 24      i  `* Re: on named blocks concept15fir
7 Nov 24      i   +- Re: on named blocks concept1fir
7 Nov 24      i   `* Re: on named blocks concept13Bonita Montero
7 Nov 24      i    +* Re: on named blocks concept10fir
7 Nov 24      i    i`* Re: on named blocks concept9Bonita Montero
7 Nov 24      i    i `* Re: on named blocks concept8fir
8 Nov 24      i    i  `* Re: on named blocks concept7Bonita Montero
8 Nov 24      i    i   `* Re: on named blocks concept6fir
8 Nov 24      i    i    `* Re: on named blocks concept5Bonita Montero
8 Nov 24      i    i     `* Re: on named blocks concept4fir
8 Nov 24      i    i      `* Re: on named blocks concept3Bonita Montero
9 Nov 24      i    i       `* Re: on named blocks concept2fir
9 Nov 24      i    i        `- Re: on named blocks concept1Bonita Montero
10 Nov 24      i    `* Re: on named blocks concept2Janis Papanagnou
13 Nov 24      i     `- Re: on named blocks concept1fir
7 Nov 24      `- Re: on named blocks concept1fir

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal