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

Groups > comp.lang.forth > #25242 > unrolled thread

LOCALS| and {:

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

Contents

  LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-16 11:59 +0100
    Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 12:31 +0100
    Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-16 13:31 +0000
    Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-16 21:50 +0200
    Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-17 08:51 +0000
      Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-18 20:10 +0100
        Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-18 23:32 +0200
        Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-18 15:47 -0700
          Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-19 15:10 +0100
        Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 09:46 +0000
          Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-22 20:15 +0100
        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 07:17 -0500
          Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 14:18 +0000
            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 10:25 -0500
              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 15:39 +0000
                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 11:26 -0500
              Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-20 11:25 +0000
                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 10:05 -0500
                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-21 14:38 +0200
                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 11:48 -0500
                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-21 16:50 +0000
                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:18 -0500
                          Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-22 12:33 +0000
                            Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-22 15:26 +0200
                              Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:25 -0500
                                Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:24 +0200
                                  Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:12 -0500
                                    Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 01:22 +0200
                                      Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 02:56 -0500
                                  Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 01:49 -0700
                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:52 -0500
                                      Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 08:10 -0700
                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:00 -0500
                                          Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 13:46 -0700
                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 03:01 -0500
                                              Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-24 03:24 -0700
                                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 12:51 -0500
                                                  Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-25 11:44 -0700
                                                  Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                                    Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                                    Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:42 +0000
                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:24 -0500
                              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 11:50 +0000
                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 08:13 -0500
                                  Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 13:55 +0000
                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:05 -0500
                                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-24 10:36 +0000
                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 13:05 -0500
                                          Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 22:44 +0200
                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 04:29 -0500
                                              Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 20:15 +0200
                                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 15:51 -0500
                                                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 23:27 +0200
                                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-26 03:19 -0500
                                                      Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-26 20:38 +0200
                                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-27 11:52 -0500
                                                          Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-28 03:52 +0200
                                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-28 11:55 -0500
                                              Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-26 11:36 +0000
                                              Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                        Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-21 10:36 -0700
                    Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-21 17:22 +0000
                      Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:34 -0500
                        Re: LOCALS| and {: mhx@iae.nl - 2013-08-21 23:05 -0700
                          Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 03:15 -0500
                            Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-22 14:49 -0700
                              Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:07 +0200
                                Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-26 20:51 -0700
                                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-27 15:55 +0200
                                    Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 10:22 -0700
                                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-27 17:33 +0000
                                      Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-27 23:02 +0000
                                        Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 22:02 -0700
                                    Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-27 11:08 -0700
                                    Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-27 21:16 -0700
                              Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:56 +0000
                Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 20:10 +0000
            Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:49 +0000
              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-20 07:14 +0000
          Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-21 10:28 +0100
      Re: LOCALS| and {: "Elizabeth D. Rather" <erather@forth.com> - 2013-08-18 10:04 -1000
        Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-19 20:08 +0100
          Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:54 +0000
      Re: LOCALS| and {: Mark Wills <markrobertwills@yahoo.co.uk> - 2013-08-20 02:19 -0700
        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 04:37 -0500
    Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-17 13:58 +0200
    Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-17 18:49 -0700
    Re: LOCALS| and {: "Ed" <invalid@invalid.com> - 2013-08-23 17:37 +1000

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

#25350

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>But wouldn't it be much better to create a struct with most of this
>stuff preloaded, anyway?  Then you can just fill in the blanks.  I
>suppose in a way that's what this word is doing, but it is fugly.  The
>problem seems to be that the meaning of any argument is determined
>only by its position in a list, which is OK with 3 or 4 args, but
>after that it gets insane.
>
>It seems to me that this is screaming for a Forth - C interface that
>doesn't just push things onto the stack, but gives them names.  Locals
>aren't a solution to that problem, because you'd still have to say
>
>lpszFace fdwPitchAndFamily fdwQuality fdwClipPrecision fdwOutputPrecision fdwCharSet fdwStrikeOut fdwUnderline fdwItalic fnWeight nOrientation nEscapement nWidth nHeight CreateFont
>
>Argh...

For the general C interface, using the stacks is the best way IMO.

For the few perverse functions of the style above, you can produce a wrapper
that takes the struct you have in mind.

I am wondering, though, why the people who defined these functions did
define the function themselves in that way.  The problem for C with
these functions is the same as in Forth.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#25351

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>But wouldn't it be much better to create a struct with most of this
>>stuff preloaded, anyway?  Then you can just fill in the blanks.  I
>>suppose in a way that's what this word is doing, but it is fugly.  The
>>problem seems to be that the meaning of any argument is determined
>>only by its position in a list, which is OK with 3 or 4 args, but
>>after that it gets insane.
>>
>>It seems to me that this is screaming for a Forth - C interface that
>>doesn't just push things onto the stack, but gives them names.  Locals
>>aren't a solution to that problem, because you'd still have to say
>>
>>lpszFace fdwPitchAndFamily fdwQuality fdwClipPrecision fdwOutputPrecision fdwCharSet fdwStrikeOut fdwUnderline fdwItalic fnWeight nOrientation nEscapement nWidth nHeight CreateFont
>>
>>Argh...
> 
> For the general C interface, using the stacks is the best way IMO.

For something like READ ( fd buf count - count' ) I'm sure you're
right.  I'm not sure about anything more complex than that.

> For the few perverse functions of the style above, you can produce a wrapper
> that takes the struct you have in mind.
> 
> I am wondering, though, why the people who defined these functions did
> define the function themselves in that way.  The problem for C with
> these functions is the same as in Forth.

Yes, it is.  In Smalltalk, though, you wouldn't have such a problem.
You'd say:

CreateFont
   withnHeight: h
   withnWidth: w
   withnEscapement: 0
   withnOrientation: 0
   withfnWeight: 0
   withfdwItalic: flag0
   withfdwUnderline: flag1
   withfdwStrikeOut: flag2
   withfdwCharSet: DEFAULT_CHARSET
   withfdwOutputPrecision: OUT_TT_PRECIS
   withfdwClipPrecision: CLIP_DEFAULT
   withfdwQuality: ANTIALIASED_QUALITY
   withfdwPitchAndFamily: family

Surely this is the sort of thing to emulate, rather than C's dumb list.

Andrew.

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

#25363

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>In Smalltalk, though, you wouldn't have such a problem.
>You'd say:
>
>CreateFont
>   withnHeight: h
>   withnWidth: w
>   withnEscapement: 0
>   withnOrientation: 0
>   withfnWeight: 0
>   withfdwItalic: flag0
>   withfdwUnderline: flag1
>   withfdwStrikeOut: flag2
>   withfdwCharSet: DEFAULT_CHARSET
>   withfdwOutputPrecision: OUT_TT_PRECIS
>   withfdwClipPrecision: CLIP_DEFAULT
>   withfdwQuality: ANTIALIASED_QUALITY
>   withfdwPitchAndFamily: family
>
>Surely this is the sort of thing to emulate, rather than C's dumb list.

There is no accounting for tastes.  Anyway, that's easy to emulate,
e.g., in Forth:

h \ withnHeight
w \ withnWidth
0 \ withnEscapement
0 \ withnOrientation
0 \ withfnWeight
flag0 \ withfdwItalic
flag1 \ withfdwUnderline
flag2 \ withfdwStrikeOut
DEFAULT_CHARSET \ withfdwCharSet
OUT_TT_PRECIS \ withfdwOutputPrecision
CLIP_DEFAULT \ withfdwClipPrecision
ANTIALIASED_QUALITY \ withfdwQuality
family \ withfdwPitchAndFamily
CreateFont

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#25364

Anton Ertl wrote:

> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>In Smalltalk, though, you wouldn't have such a problem.
>>You'd say:
>>
>>CreateFont
>>   withnHeight: h
>>   withnWidth: w
>>   withnEscapement: 0
>>   withnOrientation: 0
>>   withfnWeight: 0
>>   withfdwItalic: flag0
>>   withfdwUnderline: flag1
>>   withfdwStrikeOut: flag2
>>   withfdwCharSet: DEFAULT_CHARSET
>>   withfdwOutputPrecision: OUT_TT_PRECIS
>>   withfdwClipPrecision: CLIP_DEFAULT
>>   withfdwQuality: ANTIALIASED_QUALITY
>>   withfdwPitchAndFamily: family
>>
>>Surely this is the sort of thing to emulate, rather than C's dumb list.
> 
> There is no accounting for tastes.  Anyway, that's easy to emulate,
> e.g., in Forth:
> 
> h \ withnHeight
> w \ withnWidth
> 0 \ withnEscapement
> 0 \ withnOrientation
> 0 \ withfnWeight
> flag0 \ withfdwItalic
> flag1 \ withfdwUnderline
> flag2 \ withfdwStrikeOut
> DEFAULT_CHARSET \ withfdwCharSet
> OUT_TT_PRECIS \ withfdwOutputPrecision
> CLIP_DEFAULT \ withfdwClipPrecision
> ANTIALIASED_QUALITY \ withfdwQuality
> family \ withfdwPitchAndFamily
> CreateFont

This reminds me on module instantiation in Verilog vs. VHDL.  Modules don't 
have parameters, they have ports (wires going in and out), but essentially, 
it's a functional block.  In VHDL, all instantiations need to have the name 
of the port and the assigned wire; in Verilog, this was just position-
dependent.

Later, Verilog added instantiation by name, because hardware modules can 
have tens or sometimes hundrets of interconnections (especially in large 
designs, the top-level cells can have really an awful lot of interconnects).

The syntax is

modulename instancename(
        .port1(parameter1),
        .port2(parameter2), ...);

C could benefit from having such a calling convention for this sort of API, 
though I think the more natural convention would be the one from the 
structural initialization:

function(.param1 = value1, .param2 = value2, ...);

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#25366

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Anton Ertl wrote:
> 
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>In Smalltalk, though, you wouldn't have such a problem.

>> 
>> There is no accounting for tastes.  Anyway, that's easy to emulate,
>> e.g., in Forth:
>> 
>> h \ withnHeight
>> w \ withnWidth
>> 0 \ withnEscapement
>> 0 \ withnOrientation
>> 0 \ withfnWeight
>> flag0 \ withfdwItalic
>> flag1 \ withfdwUnderline
>> flag2 \ withfdwStrikeOut
>> DEFAULT_CHARSET \ withfdwCharSet
>> OUT_TT_PRECIS \ withfdwOutputPrecision
>> CLIP_DEFAULT \ withfdwClipPrecision
>> ANTIALIASED_QUALITY \ withfdwQuality
>> family \ withfdwPitchAndFamily
>> CreateFont
> 
> This reminds me on module instantiation in Verilog vs. VHDL.  Modules don't 
> have parameters, they have ports (wires going in and out), but essentially, 
> it's a functional block.  In VHDL, all instantiations need to have the name 
> of the port and the assigned wire; in Verilog, this was just position-
> dependent.
> 
> Later, Verilog added instantiation by name, because hardware modules can 
> have tens or sometimes hundrets of interconnections (especially in large 
> designs, the top-level cells can have really an awful lot of interconnects).
> 
> The syntax is
> 
> modulename instancename(
>        .port1(parameter1),
>        .port2(parameter2), ...);
> 
> C could benefit from having such a calling convention for this sort of API, 
> though I think the more natural convention would be the one from the 
> structural initialization:
> 
> function(.param1 = value1, .param2 = value2, ...);

That's more like it.  Anton missed the point altogether.

Andrew.

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

#25370

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> C could benefit from having such a calling convention for this sort of
>> API, though I think the more natural convention would be the one from the
>> structural initialization:
>> 
>> function(.param1 = value1, .param2 = value2, ...);
> 
> That's more like it.  Anton missed the point altogether.

And where is your patch to GCC?

IMHO one of the unelegant parts of C is the , operator.  Go does it somewhat 
better, even though perfection hasn't been achieved.  For me, the right way 
to think about , is to form a tuple, which is some sort of struct.  A 
function call is a name plus a tuple.  So you could call a function either 
with

struct threeints foo = (a, b, c);

function foo;

or

function(a, b, c);

or of course

function(.x=a, .y=b, .z=c);

or in different order like

function(.z=c, .y=b, .x=a);

as you know here which names the tuple elements have, and therefore also 
their position.  Of course you should have lvalue tuples, too, so

(a, b) = (b, a);

is swapping a and b (parentheses needed, since for compatibility, = is 
stronger than ,).  If your lvalue has less elements than the rvalue, assign 
only those on the rightmost side.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#25373

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> C could benefit from having such a calling convention for this sort of
>>> API, though I think the more natural convention would be the one from the
>>> structural initialization:
>>> 
>>> function(.param1 = value1, .param2 = value2, ...);
>> 
>> That's more like it.  Anton missed the point altogether.
> 
> And where is your patch to GCC?

What patch would that be?  What are you talking about?

> IMHO one of the unelegant parts of C is the , operator.  Go does it somewhat 
> better, even though perfection hasn't been achieved.  For me, the right way 
> to think about , is to form a tuple, which is some sort of struct.  A 
> function call is a name plus a tuple.  So you could call a function either 
> with
> 
> struct threeints foo = (a, b, c);
> 
> function foo;
> 
> or
> 
> function(a, b, c);
> 
> or of course
> 
> function(.x=a, .y=b, .z=c);
> 
> or in different order like
> 
> function(.z=c, .y=b, .x=a);
> 
> as you know here which names the tuple elements have, and therefore also 
> their position.  Of course you should have lvalue tuples, too, so
> 
> (a, b) = (b, a);
> 
> is swapping a and b (parentheses needed, since for compatibility, = is 
> stronger than ,).  If your lvalue has less elements than the rvalue, assign 
> only those on the rightmost side.

Absolutely.  But why mention C in this context?  C is what it is.

Andrew.

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

#25384

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> And where is your patch to GCC?
> 
> What patch would that be?  What are you talking about?

You seem to like this feature, so add it to GCC!  Oh, I suppose the time 
where GCC wanted to set new standards is over.

[some suggestions]
> Absolutely.  But why mention C in this context?  C is what it is.

C is, by and large, like any other language, what the major compiler makers 
make of it.  And one of the biggest is GCC.  It did set standards to which a 
number of other big compiler makers had to comply.

The question is essentially if you can make these changes while being 
compatible, and if you can, cleaning up that mess an improving the language 
is entirely possible.

C used to be K&R C some decades ago, and you probably can't even compile 
that today anymore.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#25385

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> And where is your patch to GCC?
>> 
>> What patch would that be?  What are you talking about?
> 
> You seem to like this feature, so add it to GCC!

Why on Earth would I want to improve C, though?

> Oh, I suppose the time where GCC wanted to set new standards is
> over.

Absolutely, and deliberately so.  GCC's local extensions have had a
rather, er, mixed success.

> [some suggestions]
>> Absolutely.  But why mention C in this context?  C is what it is.
> 
> C is, by and large, like any other language, what the major compiler
> makers make of it.  And one of the biggest is GCC.  It did set
> standards to which a number of other big compiler makers had to
> comply.
> 
> The question is essentially if you can make these changes while
> being compatible, and if you can, cleaning up that mess an improving
> the language is entirely possible.
> 
> C used to be K&R C some decades ago, and you probably can't even
> compile that today anymore.

Probably not.

I've been impressed recently by the additions to GCC to enable
advanced concurrency features: Cilk+ and STM.  It suggests that C the
language is not, as I thought, moribund.

Andrew.

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

#25374

> So you could call a function either with
> struct threeints foo = (a, b, c);
> function foo;
> or
> function(a, b, c);

That is approximately what Haskell does.  Maybe also Ruby.

> or of course
> function(.x=a, .y=b, .z=c);

That is called "keyword arguments" and is available in a lot of dynamic
languages like Python and (much earlier) Lisp.  It doesn't sound
feasible in C because of the need to hair up the linker if calling like
that across modules.  Maybe something like it could be done with C++
templates.

> (a, b) = (b, a);   is swapping a and b 

That is Haskell and Python etc.

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

#25375

Paul Rubin <no.email@nospam.invalid> wrote:

> That is called "keyword arguments" and is available in a lot of
> dynamic languages like Python and (much earlier) Lisp.  It doesn't
> sound feasible in C because of the need to hair up the linker if
> calling like that across modules.

There is no such need: the C compiler has all the information it needs
in the header file.

Andrew.

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

#25380

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> "keyword arguments" ... doesn't sound feasible in C because of the
>> need to hair up the linker if calling like that across modules.
> There is no such need: the C compiler has all the information it needs
> in the header file.

There might not be a header file, depending on the functiion signatures.

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

#25381

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> "keyword arguments" ... doesn't sound feasible in C because of the
>>> need to hair up the linker if calling like that across modules.
>> There is no such need: the C compiler has all the information it needs
>> in the header file.
> 
> There might not be a header file, depending on the functiion signatures.

You've lost me.  How can there be a call with no prototype?

Andrew.

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

#25383

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> There might not be a header file, depending on the functiion signatures.
> You've lost me.  How can there be a call with no prototype?

C doesn't require prototypes unless I'm behind the times.  Are you
thinking of C++?

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

#25386

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>>> There might not be a header file, depending on the functiion
>>> signatures.
>> You've lost me.  How can there be a call with no prototype?
> 
> C doesn't require prototypes unless I'm behind the times.

It does really.  There's the old K&R compatibility mode, but
prototypes are required for anything that passes types other than
default int and double.  But if we're talking about new language
featres, K&R compatibility is irrelevant.  Any new feature like
keywords would certainly require prototypes, so wouldn't require
linker hacking.

> Are you thinking of C++?

No.  C really has moved on, y'know.

Andrew.

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

#25387

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> C doesn't require prototypes unless I'm behind the times.
> It does really.  There's the old K&R compatibility mode...

    $ cat x.c
    #include <stdio.h>
    foo(int x, int y) {  printf("x=%d y=%d\n", x, y); }

    $ cat y.c
    main() { foo(2, 3); }

    $ cc -ansi -pedantic x.c y.c
    $ ./a.out
    x=2 y=3

Am I missing something?

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

#25389

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> C doesn't require prototypes unless I'm behind the times.
>> It does really.  There's the old K&R compatibility mode...
> 
>    $ cat x.c
>    #include <stdio.h>
>    foo(int x, int y) {  printf("x=%d y=%d\n", x, y); }
> 
>    $ cat y.c
>    main() { foo(2, 3); }
> 
>    $ cc -ansi -pedantic x.c y.c
>    $ ./a.out
>    x=2 y=3
> 
> Am I missing something?

zebedee:~ $ gcc -std=c99 x.c y.c
x.c:2:1: warning: return type defaults to 'int' [enabled by default]
y.c:1:1: warning: return type defaults to 'int' [enabled by default]
y.c: In function 'main':
y.c:1:1: warning: implicit declaration of function 'foo' [-Wimplicit-function-declaration]

Andrew.

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

#25395

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> zebedee:~ $ gcc -std=c99 x.c y.c
> y.c:1:1: warning: implicit declaration of function 'foo' [-Wimplicit-function-declaration]

Hmm, interesting that -ansi doesn't use the current standard (which I
guess would be c11...).

    === x.c ===
    #include <stdio.h>
    int foo(int x, int y) {  printf("x=%d y=%d\n", x, y); }

    === y.c ===
    int foo();
    void main() { foo(2, 3); }

gets rid of all warnings with -std=c99 and -std=c11.  I'm not sure if
leaving the parameters out of the prototype in y.c is still considered
conformant but it used to be explicitly allowed.

Anyway, handling keyword args at compile time that way is an interesting
idea, that doesn't sound likely to make it into C, but it would be cool
if it showed up elsewhere.

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

#25454

This post got a good deal longer while I was writing it than I
expected. Please skip if not interested in C.

On Sat, 24 Aug 2013 12:51:51 -0500, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

> Paul Rubin <no.email@nospam.invalid> wrote:
> > Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> >>> C doesn't require prototypes unless I'm behind the times.
> >> It does really.  There's the old K&R compatibility mode...
> > 
> >    $ cat x.c
> >    #include <stdio.h>
> >    foo(int x, int y) {  printf("x=%d y=%d\n", x, y); }
> > 
This appears to be a common confusion of terminology. Many people
think 'prototype' means a function declaration visible in the caller,
usually (though not necessarily) from a header file. That's incorrect.
'prototype' in C>=89 means either a function declaration or definition
with the parameter types and names in the parentheses, using syntax
backported from C++. Your foo there is a prototype definition, with
implicit return type int.

The opposite of prototype is the classic aka K&R1* syntax. K&R1
definitions look like, for your example:
  int foo(x,y) /* only names not types */
    /* for C<99 can omit return type if int */
    /* and unlike declaration does not need another specifier */
    int x, y; /* before { ! */
    /* for C<99 if the type is int this declaration can be omitted */
  { printf... }
and K&R1 declarations look like:
  int foo(); /* note nothing in parentheses */
  extern int foo(); /* same but explicit about linkage */
  extern foo(); /* for C<99 the return type can be omitted, */
    /* but only if something else (linkage) is specified */

(* The Standard doesn't actually call these K&R1. Sometimes it says
non-prototype, which is reasonably clear if bureaucratese, and
sometimes it uses clumsy locutions like 'defined using identifier-list
syntax', but it means K&R1.)

K&R1 definitions, and calls using a K&R1 declaration -- or in C<99 no
declaration, which defaults to K&R1 declaration as int -- don't always
pass 'narrow' parameter types (lower than int or double) the same way
as prototype definitions and calls. The Standard has complicated rules
about what does and doesn't work, but it's easier to Not Do That; just
use prototype declarations with prototype definitions (the best idea
for new or revised code), and K&R1 declarations or C<99 implicit
declarations with K&R1 definitions. Your case, a prototype definition
with an implicit=K&R1 declaration, lucked out, but I could construct
similar-looking cases that don't.

> >    $ cat y.c
> >    main() { foo(2, 3); }
> > 
> >    $ cc -ansi -pedantic x.c y.c
> >    $ ./a.out
> >    x=2 y=3
> > 
> > Am I missing something?
> 
> zebedee:~ $ gcc -std=c99 x.c y.c
> x.c:2:1: warning: return type defaults to 'int' [enabled by default]
> y.c:1:1: warning: return type defaults to 'int' [enabled by default]
> y.c: In function 'main':
> y.c:1:1: warning: implicit declaration of function 'foo' [-Wimplicit-function-declaration]
> 
C>=99 officially removes implicit int in declarations and definitions,
and implicit function declarations (as K&R1 returning int). gcc, quite
reasonably, still supports them with only a warning (formally making
them a C99 extension which happens to be C89!). C>=99 still officially
includes the K&R1 syntaxes I showed above, as long as you don't use
implicit int for return type or parameter type(s). C>=99 thus requires
some kind of declaration for a function you call, but that declaration
can be prototype syntax or K&R1 syntax, and it's usually most
convenient but not required to have it in a header file.

Whew!

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

#25453

On Fri, 23 Aug 2013 01:49:24 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

> > So you could call a function either with
> > struct threeints foo = (a, b, c);
> > function foo;
> > or
> > function(a, b, c);
> 
> That is approximately what Haskell does.  Maybe also Ruby.
> 
And Lisp apply. In Java you can use reflection to construct an arglist
and call with it, but it's too clumsy for in-line code and mostly used
for infrastructure things like RPC.

> > or of course
> > function(.x=a, .y=b, .z=c);
> 
> That is called "keyword arguments" and is available in a lot of dynamic
> languages like Python and (much earlier) Lisp.  It doesn't sound

And Fortran since 90 and Ada. And S/360 assembler macros!

Not quite the same, Smalltalk and ObjectiveC usually construct the
method name from a series of parameter names:
  [ widget   setname:"fred"   visible:true   tile:4 ]
would invoke a Widget method setname:visible:tile: 
but you can't omit or reorder the parameters -- unless you implement
another method with that different parameter list, which can then map
to the first method/signature or both of them to shared code.

algol60 had syntax to allow you write identifiers on the actuals in a
call, but they were only comments; the actual matching was positional.

awk and perl, and Java and C++ and (recent) Ada, standardly allow you
to create name to value maps, which can be passed and used explicitly
but separate from the builtin argument mechanism. Of course you can
also code maps yourself in almost any language. 

> feasible in C because of the need to hair up the linker if calling like
> that across modules.  Maybe something like it could be done with C++
> templates.
> 
Doing it at link time would be silly. Although as asked elsethread C
(still) doesn't *require* prototype declarations, they are now almost
universally good practice and it would make fine sense for a *new*
feature like this to only work with them. Approximately the same way
C++ argument defaulting (and thus transparent adding of new arguments)
depends on the presence and use of the correct prototype,.

C++ templates wouldn't help, though. They can do numbers and types,
not names or strings or maps.

> > (a, b) = (b, a);   is swapping a and b 
> 
> That is Haskell and Python etc.

and Lisp again, and perl.

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

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

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

csiph-web