Olin Lathrop wrote:

> It really has been confusing trying to figure out what exactly your
> point is.

Sergio's point is that there is a really important difference WRT
optimizations between constructs that are implemented in the compiler
and constructs that are implemented in a standard library (that is
defined in the same language standard). My point is that I don't see a
difference.

His example with respect to this was that in the case that the compiler
implements list handling, it is able to "know" that a 'delete' followed
by an 'insert' into the same location can be replaced by a 'replace' as
optimization. He talks about 'intent', and that the list handling being
implemented by the compiler allows it to better grasp the programmers
intent.

My point is that if the list handling functions 'delete', 'insert' and
'replace' are defined in the language standard that the compiler
implements, it is able to detect that intent in the same way and make
this optimization, no matter whether the functions themselves are
implemented in the compiler or in a (standard) library. The important
thing here is that they are defined by the language standard.

Most of the rest of the thread goes back to this; this is fundamental to
keep in mind as the issue.


>> Not quite. Firstly, I was talking about /standard/ libraries, where
>> the compiler also "knows" what the functions are supposed to do
>> (because it's defined in the same place where is defined what the
>> compiler itself is supposed to do).
> 
> But that's exactly what intrinsic functions are, which you strongly
> claimed you weren't talking about when I suggested that's what you
> might mean.  Now I am (and I think Sergio too) really confused.  How
> is what you mean not intrinsic functions?

For example, in C++ there is are list handling function defined in the
standard (e.g. std::list::insert). This is what I mean, this is what I
wrote. I have never heard anybody refer to this as "intrinsic function".
The intrinsic functions that are called so by Microsoft (in VC++) and
the writers of gcc are typically /not/ part of the language standard,
and therefore something completely different from what I'm talking
about.


> Note that you're no worse off if it doesn't support the character
> representation you like.  

Yes, I am -- if the string library doesn't use the same syntax that the
built-in strings use. Consistency is important for code quality, and
having to use different code constructs and functions for doing the same
things with different types of strings lowers consistency and therefore
code quality. For example, you may be able to use "string1 + string2"
for concatenating ASCII strings, but have to use concat(string1,string2)
for Unicode strings or 8-bit strings that handle codepage translations.
I have to repeat myself: what a pain.

> The reverse can also be a pain, like Java where everything is one of
> those unicode thingies.  

Exactly. For flexibility, it is important to be able to choose -- which
speaks against being built-in. (Not necessarily, but as a tendency.)

> Maybe that's nice if you want to appease some illiterate in a distance
> jungle somewhere, 

Now this is a completely unnecessary and stupid remark. What has using a
character set that can't be represented in ASCII to do with illiteracy
or distant jungles? 


> So it sounds like you want a bunch of intrinsic functions (which
> represent a large amount of compiler work), but have any optimization
> defeated and your own function called if you define one?

I don't "want" any of this. You need to understand the context of this
argument, and place what I write into this context. No affirmation here
stands alone. 

But yes, this would be (and is) typically possible with standard
functions that are implemented in a library. No amount of optimization
in the compiler is guaranteed to address all cases, so being able to use
a custom implementation is possibly one of the reasons of the popularity
of C in the small micro market.


>> It's the number of symbols and their structure that makes a feature
>> set "over inflated". IMO it doesn't make a difference whether you
>> have 5000 symbols in a library and people think it's too much or
>> whether you have 5000 symbols in a compiler and people think it's
>> too much.
> 
> I think part of the point is that certain features, like the string
> handling Sergio described, require a lot less special syntax when
> built in than they would require special functions if "built in" that
> way.

Can you make up an example here? I think it's the other way round: if
it's built into the language, there tends to be a special syntax,
whereas if it's part of a standard library, it tends to use the standard
syntax that's already there.

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist