«

On 2010-11-13, BartC <> wrote:
> "sandeep" <> wrote in message
> news:ibmurn$5fi$...
>> Sometimes I imagine that you and Mr Sosmanji just look for reasons to
>> oppose my suggestions...

FWIW, sandeep, I have not yet seen a suggestion from you that one would
have to *look* for reasons to oppose. In this case, the reasons to
oppose it have broken into the FBI's computers so they can look up our
home and work addresses and send us threatening letters. Also, they
are breaking into our offices and photocopying their body parts. We are
not looking for them; they are looking for us.

>> But the true point is that if the problem is not being able to pass type
>> names to functions, but being able to pass them to macros, why not
>> improve the language to allow *all* functions (both implementation and
>> user functions) to accept type names as arguments?

> You want to totally reinvent the language into something quite different,
> just so some built-in macros can be functions instead? (And after that you
> will presumably ask why statements cannot also be implemented as functions.)

To make that work at runtime, runtime code would have to have access to
the entire type system, when the entire POINT of a statically typed
compiled language is to GET AWAY FROM THAT.

If you want dynamic typing, you are probably not looking for C.

> I don't see how it would help. Any 'type arguments' you see in templates
> aren't runtime values.

Well, that's the thing. They'd have to be, meaning that C would have
turned into a fully dynamic runtime language. Which is, well.

I love languages like that. I program in several of them. They're not C.

> With getc(), that is easy enough to arrange without turning the entire
> language upside-down.

Yes.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 11/14/10 11:20 AM, Seebs wrote:
> On 2010-11-13, BartC<> wrote:
>> "sandeep"<> wrote in message
>> news:ibmurn$5fi$...
>>> Sometimes I imagine that you and Mr Sosmanji just look for reasons to
>>> oppose my suggestions...
>
> FWIW, sandeep, I have not yet seen a suggestion from you that one would
> have to *look* for reasons to oppose. In this case, the reasons to
> oppose it have broken into the FBI's computers so they can look up our
> home and work addresses and send us threatening letters. Also, they
> are breaking into our offices and photocopying their body parts. We are
> not looking for them; they are looking for us.
>
>>> But the true point is that if the problem is not being able to pass type
>>> names to functions, but being able to pass them to macros, why not
>>> improve the language to allow *all* functions (both implementation and
>>> user functions) to accept type names as arguments?
>
>> You want to totally reinvent the language into something quite different,
>> just so some built-in macros can be functions instead? (And after that you
>> will presumably ask why statements cannot also be implemented as functions.)
>
> To make that work at runtime, runtime code would have to have access to
> the entire type system, when the entire POINT of a statically typed
> compiled language is to GET AWAY FROM THAT.
>
> If you want dynamic typing, you are probably not looking for C.
>
>> I don't see how it would help. Any 'type arguments' you see in templates
>> aren't runtime values.
>
> Well, that's the thing. They'd have to be, meaning that C would have
> turned into a fully dynamic runtime language. Which is, well.

Not in the C++ meaning of "templates". All the instantiation magic
occurs at compile time when the types are known.

--
Ian Collins

Keith Thompson <kst-> writes:

[much sense, and this...]

> Oh, and setjmp() saves its calling environment; how would you write
> that in an extended C?

I don't think one has to be able to write `setjmp' in C. It's certainly
not possible in strictly conforming C, but there are other standard
library functions which can't be implemented in strictly conforming C
either -- such as `exit' -- so that's not a useful criterion. I don't
see offhand why it might be impossible to implement `setjmp' and
`longjmp' in really awful platform-specific C.

The GNU libc actually appears to implement `setjmp' as a function, which
at least saves me the effort of demonstrating possibility.

-- [mdw]

On 2010-11-13, Ian Collins <ian-> wrote:
> On 11/14/10 11:20 AM, Seebs wrote:
>> Well, that's the thing. They'd have to be, meaning that C would have
>> turned into a fully dynamic runtime language. Which is, well.

> Not in the C++ meaning of "templates". All the instantiation magic
> occurs at compile time when the types are known.

Hmm. True. I guess I was just thinking about writing an actual function
which takes a type as an argument, rather than a meta-language thing which
takes a type, but is not a function, but uses the type to generate a
function.

If offsetof() ought to be implementable as a function, then it needs to
really be dynamic. If we're just templating it, it's still an out-of-band
thing which is done dynamically and there's no function you can extract
and call generically.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

(Mark Wooding) writes:
> Keith Thompson <kst-> writes:
> [much sense, and this...]
>
>> Oh, and setjmp() saves its calling environment; how would you write
>> that in an extended C?
>
> I don't think one has to be able to write `setjmp' in C. It's certainly
> not possible in strictly conforming C, but there are other standard
> library functions which can't be implemented in strictly conforming C
> either -- such as `exit' -- so that's not a useful criterion. I don't
> see offhand why it might be impossible to implement `setjmp' and
> `longjmp' in really awful platform-specific C.
>
> The GNU libc actually appears to implement `setjmp' as a function, which
> at least saves me the effort of demonstrating possibility.

I think you're right.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 11/13/2010 4:48 PM, Ian Collins wrote:
> On 11/14/10 10:10 AM, sandeep wrote:
>> [...]
>> But the true point is that if the problem is not being able to pass type
>> names to functions, but being able to pass them to macros, why not
>> improve the language to allow *all* functions (both implementation and
>> user functions) to accept type names as arguments? This would also be
>> very helpful for type-generic / template-based programming which is now
>> very difficult in C.
>
> Types aren't "passed" to macros. Nothing is passed to a macro. A macro
> is expanded at compile time, which is the time when type information
> exists.[...]

Just to sharpen the point to greater keenness: Macros are
expanded at a time *before* types exist. That's why, for example,
you can't use #if to test the sizeof(something): sizeof can only
operate on things that have types, and at preprocessing time there
are as yet no types at all.

--
Eric Sosman
lid

On 11/13/2010 5:08 PM, Keith Thompson wrote:
> [...]
> The vast majority of entities in the standard library that can
> be invoked using syntax that looks like a function call *must*
> be implemented as functions, and in addition *may* be implemented
> as macros (which can be bypassed to get to the actual function).
>
> Just one such entity, getc(), comes with permission for the macro
> to evaluate its argument more than once.[...]

Nit: For sufficiently large values of "one," or if we decide
to ignore putc(). (I once knew a girl nicknamed "Putsi;" she was
nice. She was also rather large, and thus could have been called
a macro -- but she was nice, as I said, and no one with any sense
or sensitivity would have been so boorish. In any event, neither
Putsi nor putc() deserve to be ignored.)

--
Eric Sosman
lid

Eric Sosman <> writes:
> On 11/13/2010 5:08 PM, Keith Thompson wrote:
>> [...]
>> The vast majority of entities in the standard library that can
>> be invoked using syntax that looks like a function call *must*
>> be implemented as functions, and in addition *may* be implemented
>> as macros (which can be bypassed to get to the actual function).
>>
>> Just one such entity, getc(), comes with permission for the macro
>> to evaluate its argument more than once.[...]
>
> Nit: For sufficiently large values of "one," or if we decide
> to ignore putc(). (I once knew a girl nicknamed "Putsi;" she was
> nice. She was also rather large, and thus could have been called
> a macro -- but she was nice, as I said, and no one with any sense
> or sensitivity would have been so boorish. In any event, neither
> Putsi nor putc() deserve to be ignored.)

My apologies, putc(). You deserved better from me.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Sat, 13 Nov 2010 21:10:15 +0000, sandeep wrote:

> Obviously the implementation can "work magic" and do anything by
> functions.

No it can't. You're not talking about "functions", but "special forms".
Just because something uses the syntax "name(argument list)", that doesn't
make it a function.

There isn't a single *function* in the standard which requires special
treatment from the compiler. Anything which looks like a function either
can be implemented in a library on any sane platform or is a macro.

> But the true point is that if the problem is not being able to pass type
> names to functions, but being able to pass them to macros, why not
> improve the language to allow *all* functions (both implementation and
> user functions) to accept type names as arguments? This would also be
> very helpful for type-generic / template-based programming which is now
> very difficult in C.

If you want C++, you know where to find it.

On 11/14/2010 1:05 PM, christian.bau wrote:
> On Nov 14, 3:25 pm, Nobody<nob...@nowhere.com> wrote:
>
>> There isn't a single *function* in the standard which requires special
>> treatment from the compiler. Anything which looks like a function either
>> can be implemented in a library on any sane platform or is a macro.
>
> setjmp and longjmp seem to be exceptions. For example, there are
> requirements for the semantics of "volatile" when setjmp and longjmp
> are called.

7.13p1: "The header <setjmp.h> defines the *macro* setjmp, ..."
(emphasis mine).

--
Eric Sosman
lid