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

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

things i would ban from clc

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

Contents

  things i would ban from clc jgk@panix.com (Joe keane) - 2012-03-11 23:05 +0000
    Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-12 10:33 -0700
      Re: things i would ban from clc gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-12 23:57 +0000
    Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-12 18:44 +0100
      Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 12:26 -0700
        Re: things i would ban from clc "osmium" <r124c4u102@comcast.net> - 2012-03-12 14:36 -0600
          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 13:57 -0700
        Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-12 17:34 -0400
          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 15:00 -0700
            Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-12 18:21 -0400
              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 15:43 -0700
                Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-12 23:53 +0100
                  Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 17:17 -0700
                    Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 09:09 +0100
                      Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 01:24 -0700
                        Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-13 05:59 -0700
                          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 10:55 -0700
                            Re: things i would ban from clc blp@cs.stanford.edu (Ben Pfaff) - 2012-03-13 11:07 -0700
                              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 11:25 -0700
                                Re: things i would ban from clc blp@cs.stanford.edu (Ben Pfaff) - 2012-03-13 11:32 -0700
                                  Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-13 12:18 -0700
                                    Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:13 -0700
                                  Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 13:49 -0700
                                    Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 17:14 -0400
                                      Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 14:35 -0700
                                        Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 18:09 -0400
                                          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:06 -0700
                                            Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 08:18 +0100
                                              Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 10:07 +0100
                                              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 12:41 -0700
                                                Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 21:53 +0100
                                                  Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 14:16 -0700
                                                    Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-18 07:14 +0100
                                          Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-14 10:39 +0100
                                    Re: things i would ban from clc Ben Pfaff <blp@cs.stanford.edu> - 2012-03-13 14:33 -0700
                                      Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 14:40 -0700
                              Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 16:25 -0700
                                Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 00:51 -0700
                                  Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-14 14:25 -0700
                                    Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 13:40 -0700
                                      Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-18 17:05 -0700
                                        Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-23 11:59 -0700
                                          Re: things i would ban from clc Robert Wessel <robertwessel2@yahoo.com> - 2012-03-23 17:02 -0500
                                            Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-23 16:51 -0700
                                              Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-24 07:16 +0100
                                          Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-27 11:26 -0700
                                        Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-23 19:43 +0000
                                          Re: things i would ban from clc Rui Maciel <rui.maciel@gmail.com> - 2012-03-23 19:45 +0000
                                          Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 23:49 +0100
                                            Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-24 11:54 +1300
                                              Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:26 +0100
                                              Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-26 07:31 -0700
                                            Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-24 05:45 +0000
                                              Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:31 +0100
                            Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 14:34 -0400
                            Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 16:18 -0700
                              Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 08:18 +0100
                                Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-14 14:06 -0700
                        Re: things i would ban from clc Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-15 15:22 +0000
                          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 12:26 -0700
                            Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-15 21:28 +0100
                              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 13:49 -0700
                        Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-15 16:36 +0000
                          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 12:16 -0700
                            Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-16 00:13 +0000
                              Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 20:40 -0700
                  Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-13 01:52 -0700
                    Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-13 11:31 +0100
                    Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 11:41 +0100
                      Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-13 06:06 -0700
                        Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 15:06 +0100
                        Re: things i would ban from clc ImpalerCore <jadill33@gmail.com> - 2012-03-13 07:46 -0700
                        Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 19:08 +0100
                      Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-13 13:20 +0000
                        Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-13 20:41 +0100
                  Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-13 19:34 +0000
                    Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:14 -0700
                      Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-13 23:28 +0000
                        Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 21:18 -0700
        Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-13 20:19 +1300
          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 01:09 -0700
            Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-13 21:32 +1300
    Re: things i would ban from clc nick_keighley_nospam@hotmail.com - 2012-03-13 01:52 -0700
      Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-13 11:31 +0100
        Re: things i would ban from clc nick_keighley_nospam@hotmail.com - 2012-03-14 01:18 -0700
          Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 12:09 -0700
    Re: things i would ban from clc ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-03-14 13:01 -0700

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

#18560 — things i would ban from clc

1. it's not twos' complement

2. an 'int' may have a trap value

-who- -cares-
go have sex with youselves

[toc] | [next] | [standalone]

#18595

jgk@panix.com (Joe keane) writes:
> 1. it's not twos' complement
>
> 2. an 'int' may have a trap value
>
> -who- -cares-

If you don't care, you don't have to participate in such discussions.
They are certainly on topic for a group that discusses the C
programming language.  Would you suggest another forum to discuss
such issues, or would you censor them entirely?

> go have sex with youselves

You are teetering on the edge of my killfile.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#18619

In article <lnehsxenb3.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>jgk@panix.com (Joe keane) writes:
>> 1. it's not twos' complement
>>
>> 2. an 'int' may have a trap value
>>
>> -who- -cares-
>
>If you don't care, you don't have to participate in such discussions.
>They are certainly on topic for a group that discusses the C
>programming language.  Would you suggest another forum to discuss
>such issues, or would you censor them entirely?
>
>> go have sex with youselves
>
>You are teetering on the edge of my killfile.

It is to laugh.  For so long, Kiki was the champion of "I don't use a
killfile, because only peons use killfiles, and I am above that sort of
thing."

Now, he can't resist the urge to do that stupidest of all things: Use his
(supposed) killfile as a weapon in battle.

How things change...

-- 
One of the best lines I've heard lately:

    Obama could cure cancer tomorrow, and the Republicans would be
    complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it.  We've constructed an economy in which eliminating
cancer would be a horrible disaster.  There are many other such examples.)

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

#18597

Le 12/03/12 00:05, Joe keane a écrit :
> 1. it's not twos' complement
>
> 2. an 'int' may have a trap value
>
> -who- -cares-
> go have sex with youselves

As you have seen from the promoters of those sterile discussions
(thompson for instance) they need to go on forever with those
discussions...


The prototype of main() is a hot topic for them too.

At the same time, thompson and the others shun REAL discussions about
REAL progress that can be done to improve the language.

In all my discussions about the C containers library thompson and the
other "clc regulars" were conspicuously ABSENT. Technically they have
absolutely NOTHING to say.

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

#18603

Hi Jacob,

On 3/12/2012 10:44 AM, jacob navia wrote:
> Le 12/03/12 00:05, Joe keane a écrit :
>> 1. it's not twos' complement
>>
>> 2. an 'int' may have a trap value
>>
>> -who- -cares-
>> go have sex with youselves
>
> As you have seen from the promoters of those sterile discussions
> (thompson for instance) they need to go on forever with those
> discussions...
>
> The prototype of main() is a hot topic for them too.
>
> At the same time, thompson and the others shun REAL discussions about
> REAL progress that can be done to improve the language.
>
> In all my discussions about the C containers library thompson and the
> other "clc regulars" were conspicuously ABSENT. Technically they have
> absolutely NOTHING to say.

I can't comment re: your personality assessments as I
have a short/transient tenure, here.

And, I don't see the "containers" thread you mentioned
(possibly old or something I marked as "read" without
having actually *read* it).

The "problem" with any public forum is that participants
dome to it with different expectations and needs.  Some
might want to argue minutia of the language specification;
or a particular implementation; etc.  Others might want
help understanding some *basic* feature of the language;
still others might look for suggestions on techniques or
algorithms to approach a particular problem.

If you've ever dealt with a "building inspector", you've
seen how they might (and *are*, LEGALLY!) be the epitome of
what is allowed/expected in the construction of a building.
But, chances are, you'd never hire any of them to *design*
a building for you!  Or, furnish it.  Sure, it might meet
all the structural, electrical, plumbing, etc. requirements
of the current Codes... but that doesn't mean it would be a
pleasant or *useful* place to live/work!

E.g., an inspector can tell you whether you *must* have a
dedicated electrical outlet for your refrigerator.  *And*,
the ampacity of that circuit.  He can tell you if a single
outlet is required or if a duplex outlet is sufficient.
But, he probably won't explain (or know!) why you should or
shouldn't (in your particular case) -- if you have a choice!

I prepare a lot of formal documentation for my projects.
I'll have an "English major" check my grammar, spelling,
etc.  But, I'd never trust any of them to *write* (or
rewrite) the documents -- even if they were as knowledgeable
about the material as I!  E.g., they might not appreciate
the choice and role of analogies used in the descriptions.
Or, might write a "text book" that no one is inclined to
*read*!

If you're unhappy with a particular discussion -- or
*aspect* of a discussion -- skip past it.  Pick the fruit
that is more to your liking!

Of course, YMMV.

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

#18604

"Don Y" wrote:

> I prepare a lot of formal documentation for my projects.
> I'll have an "English major" check my grammar, spelling,
> etc.  But, I'd never trust any of them to *write* (or
> rewrite) the documents -- even if they were as knowledgeable
> about the material as I!  E.g., they might not appreciate
> the choice and role of analogies used in the descriptions.
> Or, might write a "text book" that no one is inclined to
> *read*!

I assumed twos' complement was mentioned because of the way it was spelled.

Who knows?  And does anyone *really* care? 

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

#18605

On 3/12/2012 1:36 PM, osmium wrote:
> "Don Y" wrote:
>
>> I prepare a lot of formal documentation for my projects.
>> I'll have an "English major" check my grammar, spelling,
>> etc.  But, I'd never trust any of them to *write* (or
>> rewrite) the documents -- even if they were as knowledgeable
>> about the material as I!  E.g., they might not appreciate
>> the choice and role of analogies used in the descriptions.
>> Or, might write a "text book" that no one is inclined to
>> *read*!
>
> I assumed twos' complement was mentioned because of the way it was spelled.
>
> Who knows?  And does anyone *really* care?

A language pedant might.  :>

Or, someone poking around at the edges of the language
(strange things lurk in dark corners!)

It's good to be *aware* that things aren't ever as *simple*
as they seem -- so you aren't surprised, one day, when you
stumble into one of these "dark corners".  But letting that
sort of preoccupation get in the way with "useful work"
tends to be a waste of time, IMO (YMMV).

(E.g., product starts running code at location 0x00..0.
How do you dereference that address for a reset() routine?)

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

#18606

On 03/12/2012 03:26 PM, Don Y wrote:
> Hi Jacob,
> 
> On 3/12/2012 10:44 AM, jacob navia wrote:
...
>> At the same time, thompson and the others shun REAL discussions about
>> REAL progress that can be done to improve the language.

That's just how jacob perceives it when someone disagrees with him about
whether or not one of his proposals counts as "progress" or an
"improvement". He only wants to discuss how his proposals should be
implemented. Any disagreement with the fundamental concept of his
proposals is treated as a personal attack; which tends to discourage
those who would otherwise be willing to engage in a "REAL" discussion of
why they think the proposals should not be implemented.

>> In all my discussions about the C containers library thompson and the
>> other "clc regulars" were conspicuously ABSENT. Technically they have
>> absolutely NOTHING to say.
...
> And, I don't see the "containers" thread you mentioned
> (possibly old or something I marked as "read" without
> having actually *read* it).

Google for clc and comp.std.c messages with "containers" in the
Subject:; most of the messages after 2009 are part of the discussion
he's referring to. As you'll see, a fair number of the messages are from
Keith Thompson, though I agree that he's far from being the most active
participant.

That none of the more active participants in that discussion counts as a
"clc regular" in jacob's eyes surprises me, but then the definition of
that term has always been rather peculiar. The term is used, and
therefore defined, almost exclusively by people who don't consider
themselves a member of the group it describes - even though many of
those people are among the ones who post to clc most regularly.
Therefore, it certainly doesn't mean "people who post to clc regularly".

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

#18608

Hi James,

On 3/12/2012 2:34 PM, James Kuyper wrote:
> On 03/12/2012 03:26 PM, Don Y wrote:
>> On 3/12/2012 10:44 AM, jacob navia wrote:
> ...
>>> At the same time, thompson and the others shun REAL discussions about
>>> REAL progress that can be done to improve the language.
>
> That's just how jacob perceives it when someone disagrees with him about
> whether or not one of his proposals counts as "progress" or an
> "improvement". He only wants to discuss how his proposals should be
> implemented. Any disagreement with the fundamental concept of his
> proposals is treated as a personal attack; which tends to discourage
> those who would otherwise be willing to engage in a "REAL" discussion of
> why they think the proposals should not be implemented.

Again, I can't comment re: "personalities" as I don't
know histories, etc.

>>> In all my discussions about the C containers library thompson and the
>>> other "clc regulars" were conspicuously ABSENT. Technically they have
>>> absolutely NOTHING to say.
> ...
>> And, I don't see the "containers" thread you mentioned
>> (possibly old or something I marked as "read" without
>> having actually *read* it).
>
> Google for clc and comp.std.c messages with "containers" in the
> Subject:; most of the messages after 2009 are part of the discussion

------------------------------------------^

Yikes!  Can you spell "ancient history"?

> he's referring to. As you'll see, a fair number of the messages are from
> Keith Thompson, though I agree that he's far from being the most active
> participant.
>
> That none of the more active participants in that discussion counts as a
> "clc regular" in jacob's eyes surprises me, but then the definition of
> that term has always been rather peculiar. The term is used, and
> therefore defined, almost exclusively by people who don't consider
> themselves a member of the group it describes - even though many of
> those people are among the ones who post to clc most regularly.
> Therefore, it certainly doesn't mean "people who post to clc regularly".

(sigh)  Unfortunately, this is often the case when people
"talk".

As I said, each has his/her own motivations, goals, etc.
which might not coincide with your own.  One has to learn to
"cherry pick" the useful (in your *own* assessment) from
that which is "less" useful.

In my case, I care little about the formal specification
of the language and how it is (or will) evolving.  I'll pick
what aspects appeal to me and deprecate those that don't.
(I can always fall back on any of the previous "versions").

OTOH, others (Jacob?) concerned with standards efforts would
have a far different outlook

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

#18609

On 03/12/2012 06:00 PM, Don Y wrote:
> Hi James,
> 
> On 3/12/2012 2:34 PM, James Kuyper wrote:
>> On 03/12/2012 03:26 PM, Don Y wrote:
...
>>> And, I don't see the "containers" thread you mentioned
>>> (possibly old or something I marked as "read" without
>>> having actually *read* it).
>>
>> Google for clc and comp.std.c messages with "containers" in the
>> Subject:; most of the messages after 2009 are part of the discussion
> 
> ------------------------------------------^
> 
> Yikes!  Can you spell "ancient history"?

Yes, and for me it starts a millennium or two earlier than it does for
you. I come from a background in science and in particular astronomy -
for some purposes, I consider anything less than a billion years old to
be relatively young :-)

While the start of that discussion is several years old, the most recent
messages are relatively recent. Jacob's still working on it, and is
still interested in discussing it, so it's still current.

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

#18611

Hi James,

On 3/12/2012 3:21 PM, James Kuyper wrote:

[snip]

>>>> And, I don't see the "containers" thread you mentioned
>>>> (possibly old or something I marked as "read" without
>>>> having actually *read* it).
>>>
>>> Google for clc and comp.std.c messages with "containers" in the
>>> Subject:; most of the messages after 2009 are part of the discussion
>>
>> -----------------------------------------^
>>
>> Yikes!  Can you spell "ancient history"?
>
> Yes, and for me it starts a millennium or two earlier than it does for
> you. I come from a background in science and in particular astronomy -
> for some purposes, I consider anything less than a billion years old to
> be relatively young :-)

Ah, women-folk must *love* you at the local bars!!  ;-)

> While the start of that discussion is several years old, the most recent
> messages are relatively recent. Jacob's still working on it, and is
> still interested in discussing it, so it's still current.

It's not uncommon for people to fixate on *an* issue.  There's
a guy in one of the database groups that keeps harping on a
certain *feature* that he wants but that others (i.e., the
*implementers*) have decided against.  That doesn't stop him
from bringing up the subject regularly...

<frown>  OK, maybe I should go take a peek to see if there's
any fire behind the smoke.  Though if it is some part of the
"Standard", I probably wouldn't be interested.

("OK, so you want the steering wheel to be on the *RIGHT*
side?  <shrug>  Just tell me where I insert the key...")

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

#18612

If you are interested in knowing what the container's library is about 
look at

http://code.google.com/p/ccl/

There you will find the whole containers library for C, the
documentation, and the source code.

"containers" means lists (single/double linked), hash-tables,
flexible arrays, buffers, circular buffers, trees, and several others.

My proposal is to standardize this in a similar way to C++
stl and allow you to use lists and hashtables in your C code without
reinventing the wheel.

The other people here that do not like this project complain that
there will be never a single package that satisfy all needs, etc.

They are in general against any modification of the language, except
trivialities like the prototype of main() (thompson).


have fun with the library and tell me if you find any bug

jacob

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

#18620

Hi Jacob,

On 3/12/2012 3:53 PM, jacob navia wrote:
> If you are interested in knowing what the container's library is about
> look at
>
> http://code.google.com/p/ccl/
>
> There you will find the whole containers library for C, the
> documentation, and the source code.
>
> "containers" means lists (single/double linked), hash-tables,
> flexible arrays, buffers, circular buffers, trees, and several others.
>
> My proposal is to standardize this in a similar way to C++
> stl and allow you to use lists and hashtables in your C code without
> reinventing the wheel.

But what is the *philosophy* behind the language maintainers?
I.e., *should* C's libraries continue to grow to creep further
into the application domain?  Where do you stop -- what about
cryptographic functions?  Infinite precision/decimal math?
etc.

I've always assumed a big part of the reasoning behind the STL
was to bootstrap the adoption and "learning" of C++.  Not
things that would really translate to C (this late in the game)

C always had a nice, light "feel" -- something that C++ can't
approach.  The existing libraries almost seem to be pushing the
limits of that (though they tend not to be as bloated as C++'s
approach to things).

[If you've ever tackled Ada, you understand the difference in
"attitude" taken/portrayed by the language(s)]

> The other people here that do not like this project complain that
> there will be never a single package that satisfy all needs, etc.
>
> They are in general against any modification of the language, except
> trivialities like the prototype of main() (thompson).
>
> have fun with the library and tell me if you find any bug
>
> jacob
>

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

#18649

Le 13/03/12 01:17, Don Y a écrit :
>
> But what is the *philosophy* behind the language maintainers?
> I.e., *should* C's libraries continue to grow to creep further
> into the application domain?

No. The containers library is not an application; A container is used
in most applications though, and that is the difference.

Most serious programs use lists, need flexible arrays, hash tables, etc.
The "solution" now is that each program redevelops a linked list
package, a hash table package, etc from scratch at each project.

Since there isn't a common interface all this programs are incompatible 
and need to be adapted when used together.

If I use package "A" with its list module and package "B" with another
incompatible lost module, I have to write adapter code to pass lists
written in package "A" to lists in package "B".

And you know very well what I am talking about. Never done
a list package? You never used a list in your programs?

> Where do you stop -- what about
> cryptographic functions? Infinite precision/decimal math?
> etc.


Many of those functions are provided by my compiler system
lcc-win but I am not proposing to generalize them. What I am
proposing is standardizing the principal containers.

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

#18652

On 3/13/2012 1:09 AM, jacob navia wrote:
> Le 13/03/12 01:17, Don Y a écrit :
>>
>> But what is the *philosophy* behind the language maintainers?
>> I.e., *should* C's libraries continue to grow to creep further
>> into the application domain?
>
> No. The containers library is not an application; A container is used
> in most applications though, and that is the difference.

I didn't claim it was an application.  Rather, I said "creep
further into the application domain".  I.e., where do you
draw the line between "part of the language" and "*part* of
the application"?

I use lots of geometric functions.  Should the language tout
a library that provides these to me in some "standard" way?
What about crypto functions?  Secure hashes?  etc.

Why not support for *tasking* -- native to the language
(instead of in a library!) like Limbo?

> Most serious programs use lists, need flexible arrays, hash tables, etc.
> The "solution" now is that each program redevelops a linked list
> package, a hash table package, etc from scratch at each project.
>
> Since there isn't a common interface all this programs are incompatible
> and need to be adapted when used together.
>
> If I use package "A" with its list module and package "B" with another
> incompatible lost module, I have to write adapter code to pass lists
> written in package "A" to lists in package "B".
>
> And you know very well what I am talking about. Never done
> a list package? You never used a list in your programs?

You *really* don't want to pose that question to me!  :>
I often rewrite major portions of the standard libraries
as I move from project to project -- because the execution
environments frequently differ and I don't need the "generality"
that most of the libraries provide.  Or, I am bastardizing a
standard data type, etc.

When was the last time you used:

    digits = INT_MAX
    decimals = INT_MAX
    printf("The answer is %*.*e", value, digits, decimals)

In fact, when was the last time you used the '*' flag in printf??
Will your copy of the libraries even *handle* this specific
case??

I.e., I tend to err on the side of "leaner" vs. "fatter".
So, need to see a real reason for *adding* something in
that can't already be handled some other way.

E.g., Limbo's support for tasking and IPC "belongs" in the
language (Limbo, that is).  It noticeably changes the
feel and capabilities of the language -- and the applications
it tries to address (moreso than a "library" would have)

>> Where do you stop -- what about
>> cryptographic functions? Infinite precision/decimal math?
>> etc.
>
> Many of those functions are provided by my compiler system
> lcc-win but I am not proposing to generalize them. What I am
> proposing is standardizing the principal containers.

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

#18672

Don Y <this@isnotme.com> writes:
[...]
> Why not support for *tasking* -- native to the language
> (instead of in a library!) like Limbo?
[...]

The 2011 ISO C standard includes (optional) support for threading.

See <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>
section 7.26.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#18684

Hi Keith,

On 3/13/2012 5:59 AM, Keith Thompson wrote:
> Don Y<this@isnotme.com>  writes:
> [...]
>> Why not support for *tasking* -- native to the language
>> (instead of in a library!) like Limbo?
> [...]
>
> The 2011 ISO C standard includes (optional) support for threading.
>
> See<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>
> section 7.26.

OK.  But that's just another standard library.  The language
itself doesn't include those provisions.

E.g., Limbo includes a "spawn" keyword and the mechanisms
to dynamically create that "thread" (trying not to get
bogged down into thread/process/task/etc. lexicon) along
with mechanisms to *load* modules ("programs"), tear
"processes" down and pass values between "processes".

It's not an "add on" but, rather, an integral part of
the language, itself.

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

#18685

Don Y <this@isnotme.com> writes:

> On 3/13/2012 5:59 AM, Keith Thompson wrote:
>> Don Y<this@isnotme.com>  writes:
>>> Why not support for *tasking* -- native to the language
>>> (instead of in a library!) like Limbo?
>>
>> The 2011 ISO C standard includes (optional) support for threading.
>>
>> See<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>
>> section 7.26.
>
> OK.  But that's just another standard library.  The language
> itself doesn't include those provisions.

What's the advantage of putting threading into language instead
of the library?  (You explained *how* Limbo integrates threading
into the language, but not why it does.)
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

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

#18687

Hi Ben,

On 3/13/2012 11:07 AM, Ben Pfaff wrote:
> Don Y<this@isnotme.com>  writes:
>
>> On 3/13/2012 5:59 AM, Keith Thompson wrote:
>>> Don Y<this@isnotme.com>   writes:
>>>> Why not support for *tasking* -- native to the language
>>>> (instead of in a library!) like Limbo?
>>>
>>> The 2011 ISO C standard includes (optional) support for threading.
>>>
>>> See<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>
>>> section 7.26.
>>
>> OK.  But that's just another standard library.  The language
>> itself doesn't include those provisions.
>
> What's the advantage of putting threading into language instead
> of the library?  (You explained *how* Limbo integrates threading
> into the language, but not why it does.)

It elevates threads to first-class objects.  It recognizes
that programs are more "collections of threads" than "monolithic,
single-threaded processes" that have to *struggle* to
CO-operate.

C could have put all floating point math operations
(including +, -, etc.) into a "floating point library".
Instead, floats/doubles are an integral part of the
language -- even on platforms where supporting
floats is "troublesome" (no FP hardware).

Moving things into the language also changes who is
responsible for the implementation and performance of
the feature.  In Limbo, the "compiler"/runtime VM handle
ALL of the mechanisms associated with these features.
it means that those features are accessible to your
code on any platform that can support Limbo programs.
(double edged sword... if you don't like how they do
it, you can't just swap out that aspect like you can with
a separate library).

I also think you end up with skinnier interfaces and
"simpler" (cleaner?) syntax.

(Again, all this comes at a price -- you don't have
the same sort of control that you do when the
*mechanisms* are "exported" in a library... that you
could potentially *modify*)

As to the creators' reasons... <shrug>  you would have
to ask them (Pike, Dorward, Winterbottom)

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

#18689

Don Y <this@isnotme.com> writes:

> On 3/13/2012 11:07 AM, Ben Pfaff wrote:
>> Don Y<this@isnotme.com>  writes:
>>
>>> On 3/13/2012 5:59 AM, Keith Thompson wrote:
>>>> Don Y<this@isnotme.com>   writes:
>>>>> Why not support for *tasking* -- native to the language
>>>>> (instead of in a library!) like Limbo?
>>>>
>>>> The 2011 ISO C standard includes (optional) support for threading.
>>>>
>>>> See<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>
>>>> section 7.26.
>>>
>>> OK.  But that's just another standard library.  The language
>>> itself doesn't include those provisions.
>>
>> What's the advantage of putting threading into language instead
>> of the library?  (You explained *how* Limbo integrates threading
>> into the language, but not why it does.)
>
> It elevates threads to first-class objects.  It recognizes
> that programs are more "collections of threads" than "monolithic,
> single-threaded processes" that have to *struggle* to
> CO-operate.

That is a nice statement of principles, but it's hard for me to
imagine what practical effect it would have on threaded C
programs.  Do you have an example to propose?

> Moving things into the language also changes who is
> responsible for the implementation and performance of
> the feature.  In Limbo, the "compiler"/runtime VM handle
> ALL of the mechanisms associated with these features.
> it means that those features are accessible to your
> code on any platform that can support Limbo programs.
> (double edged sword... if you don't like how they do
> it, you can't just swap out that aspect like you can with
> a separate library).

Threading is intentionally an optional feature for C
implementations, because C is supposed to work on platforms that
do not or cannot support threads.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

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

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

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

csiph-web