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

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

Advantages of C

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

Contents

  Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:02 +0200
    Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 16:16 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 19:13 +0200
      Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:56 +0530
    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 08:17 -0700
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:38 +0200
    Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 16:48 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:58 +0200
        Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-18 17:27 +0100
          Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 15:19 -0400
          Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 21:49 +0100
            Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-18 22:06 +0100
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:11 +0100
                Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 01:31 +0100
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 02:29 +0100
                  Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 21:58 -0400
            Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:30 -0700
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 02:06 +0100
                Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 19:39 -0700
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:29 +0100
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:39 -0700
                      Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:19 +0100
          Re: Advantages of C luser droog <luser.droog@gmail.com> - 2016-07-18 21:16 -0700
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:47 +0100
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:48 -0700
        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-19 10:21 +1200
          Re: Advantages of C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:43 +0000
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 18:05 +0200
        Re: Advantages of C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 21:45 +0200
          Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 21:16 +0100
            Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:00 +0530
              Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-19 11:00 +0100
                Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-20 10:08 +0530
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 23:32 +0200
            Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:54 -0700
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:54 +0100
                Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 20:02 -0700
                  Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:26 +0530
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 01:43 -0700
                      Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-20 10:33 +0530
                        Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 01:07 -0700
                          Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 12:53 +0530
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:33 +0100
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:04 -0700
                      Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:35 +0100
                Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-19 19:21 +0100
            Re: Advantages of C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-20 12:05 +0200
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:51 -0700
            Re: Advantages of C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:24 +0000
              Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 02:33 -0700
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:36 +0100
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 00:00 +0200
            Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:46 +0100
            Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-20 19:49 +0100
              Re: Advantages of C supercat@casperkitty.com - 2016-07-20 12:02 -0700
                Re: Advantages of C Keith Thompson <kst-u@mib.org> - 2016-07-20 12:32 -0700
                  Re: Advantages of C supercat@casperkitty.com - 2016-07-20 13:18 -0700
                Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-20 20:37 +0100
              Re: Advantages of C jadill33@gmail.com - 2016-07-20 13:06 -0700
              Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-20 23:07 +0200
                Re: Advantages of C jadill33@gmail.com - 2016-07-21 09:48 -0700
                  Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 10:14 +0200
                    Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 20:25 +1200
                      Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 02:17 -0700
                        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 23:56 +1200
                      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 11:28 +0200
                        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 23:49 +1200
                    Re: Advantages of C jadill33@gmail.com - 2016-07-22 06:46 -0700
          Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 23:13 +0100
            Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:45 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 19:18 +0200
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:47 +0100
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 00:07 +0200
            Re: Advantages of C Melzzzzz <mel@zzzzz.com> - 2016-07-19 00:18 +0200
              Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 01:36 +0200
            Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-19 10:28 +1200
              Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:34 -0400
            Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:33 -0400
              Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 19:30 -0700
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 17:01 -0700
    Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:51 +0530
      Re: Advantages of C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-20 09:01 -0700

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

#90727

On Wednesday, July 20, 2016 at 5:07:14 PM UTC-4, jacobnavia wrote:
> Le 20/07/2016 à 20:49, Gareth Owen a écrit :
> > jacobnavia <j...@...fr> writes:
> >
> >> Lisp spends an awful lot of time checking the arguments, what C
> >> generated code doesn't do since the types are checked at compile time.
> >
> > ... says the man who implemented an entire container library using void*
> > pointers and essentially no type checking.
> >
> If you take some time to see the CCL you will see that there is a 
> generic interface implemented with C macros, that allows you full 
> compiler type checking if you want.
> 
> See the implementation of the generic lists and others. Of course I was 
> told that C macros are primitive and ugly, and what I wanted to do was 
> impossible to do with C macros.

Hmmm, I vaguely remember seeing SGLIB before the CCL.  At least there was
some prior art to a container library that used a macro interface.

The two issues with the macro version that I can see are code "ugliness"
(depending on developer's perception of macros) and code bloat.  I'm not
sure if there exists a purely C container macro incantation that C
developers at large would accept (which at this time in the C standards
lifecycle would be a precursor to getting something that the standards
committee would debate about).  There's a lot of ingrained disdain towards
macros (and it's not without valid reasons).

For a single application, code bloat is not likely to be a problem.  You
just declare the containers for the types you need and link them in.
However, I don't think it scales well.  If you have a suite of applications
and you want to use the same containers generated using the macro interface,
you have the potential to either duplicate code in each of the applications
(e.g. app 1 and 2 uses a macro generated list of integers) or maintain some
library of a mishmash of type specific containers that cover all of your
applications.

Sounds like a maintenance nightmare to me.  The void* version, while being
less type safe, has the advantage that it can be compiled into a single
shared library and linked against all of the applications, (with a different
nightmare scenario, mixing up container types at runtime and summoning all
sorts of nasal demons).

It gets worse if there is a bug in the macro implementation.  Now I have
to rebuild every application that uses that instead of just releasing a
new shared library that contains the fix.  As an example, consider how
one would support a MSVC C Runtime library model with standard container
library support using the macro implementation.  I don't find it to be
feasible.

It's nice that you make both options available.  C++ went the "macro"
route with templates (although internally some implementations may use
void* under the hood to avoid the code bloat problem).  From my
perspective, it appears uncertain if any incarnation of a container
library (macro or void*) can grab enough of a foothold to make the
standards committee notice, especially when alternative languages with
more "mature" container implementations exist (and a large number of
people here point their finger in that direction).  If you can't win
over comp.lang.c, I don't see how the standards committee is going to
be any different.

It's great that you've contributed to the C community with your container
library.  It's a success just releasing it out there.  That's all that
you can control; the rest is just part of the adventure of seeing where it
goes.

Best regards,
John D.

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

#90755

Le 21/07/2016 à 18:48, jadill33@gmail.com a écrit :
> On Wednesday, July 20, 2016 at 5:07:14 PM UTC-4, jacobnavia wrote:
>> Le 20/07/2016 à 20:49, Gareth Owen a écrit :
>>> jacobnavia <j...@...fr> writes:
>>>
>>>> Lisp spends an awful lot of time checking the arguments, what C
>>>> generated code doesn't do since the types are checked at compile time.
>>>
>>> ... says the man who implemented an entire container library using void*
>>> pointers and essentially no type checking.
>>>
>> If you take some time to see the CCL you will see that there is a
>> generic interface implemented with C macros, that allows you full
>> compiler type checking if you want.
>>
>> See the implementation of the generic lists and others. Of course I was
>> told that C macros are primitive and ugly, and what I wanted to do was
>> impossible to do with C macros.
>
> Hmmm, I vaguely remember seeing SGLIB before the CCL.  At least there was
> some prior art to a container library that used a macro interface.
>
Never heard of the "SGLIB". Where is it?

> The two issues with the macro version that I can see are code "ugliness"
> (depending on developer's perception of macros) and code bloat.  I'm not
> sure if there exists a purely C container macro incantation that C
> developers at large would accept (which at this time in the C standards
> lifecycle would be a precursor to getting something that the standards
> committee would debate about).  There's a lot of ingrained disdain towards
> macros (and it's not without valid reasons).
>

Well C macros aren't as ugly as other c++ constructs. "Ugly" is not a 
valid adjective here.

> For a single application, code bloat is not likely to be a problem.  You
> just declare the containers for the types you need and link them in.


Or you put the object code in a library. Only the needed functions will 
be linked in.

> However, I don't think it scales well.  If you have a suite of applications
> and you want to use the same containers generated using the macro interface,
> you have the potential to either duplicate code in each of the applications
> (e.g. app 1 and 2 uses a macro generated list of integers) or maintain some
> library of a mishmash of type specific containers that cover all of your
> applications.
>

I think you should look at c++. If you have a template, the template 
code will be replicated in all your applications ALSO. Here the 
situation  is exactly the same.

> Sounds like a maintenance nightmare to me.

You pose a non-existing problem and then bloat it like a C macro!
:-)

The void* version, while being
> less type safe, has the advantage that it can be compiled into a single
> shared library and linked against all of the applications, (with a different
> nightmare scenario, mixing up container types at runtime and summoning all
> sorts of nasal demons).
>

What a catastrophe!

With templates those catastrophes are so common that Bjarne tried 
(unsuccessfully) to figure out args checking for templates (the 
"concepts" debacle) but couldn't do it.

> It gets worse if there is a bug in the macro implementation.

Yes. See what happens when you have a bug in the template code.

Now I have
> to rebuild every application that uses that instead of just releasing a
> new shared library that contains the fix.  As an example, consider how
> one would support a MSVC C Runtime library model with standard container
> library support using the macro implementation.  I don't find it to be
> feasible.
>

????
I just do not see what the MSVC C runtime has anything to do here.

> It's nice that you make both options available.  C++ went the "macro"
> route with templates (although internally some implementations may use
> void* under the hood to avoid the code bloat problem).  From my
> perspective, it appears uncertain if any incarnation of a container
> library (macro or void*) can grab enough of a foothold to make the
> standards committee notice, especially when alternative languages with
> more "mature" container implementations exist (and a large number of
> people here point their finger in that direction).  If you can't win
> over comp.lang.c, I don't see how the standards committee is going to
> be any different.
>

Yeah c++ makes everything better. I know the story.

> It's great that you've contributed to the C community with your container
> library.  It's a success just releasing it out there.  That's all that
> you can control; the rest is just part of the adventure of seeing where it
> goes.
>
> Best regards,
> John D.
>

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

#90757

On 07/22/16 08:14 PM, jacobnavia wrote:
> Le 21/07/2016 à 18:48, jadill33@gmail.com a écrit :
>
>> However, I don't think it scales well.  If you have a suite of applications
>> and you want to use the same containers generated using the macro interface,
>> you have the potential to either duplicate code in each of the applications
>> (e.g. app 1 and 2 uses a macro generated list of integers) or maintain some
>> library of a mishmash of type specific containers that cover all of your
>> applications.
>>
>
> I think you should look at c++. If you have a template, the template
> code will be replicated in all your applications ALSO. Here the
> situation  is exactly the same.

Not so.  A templated function is still a function, so it will only be 
instantiated once where a macro will always be expanded.  With a 
function template then compiler can choose whether to call or inline the 
function.  With a function like macro it doesn't.

-- 
Ian

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

#90761

On Friday, July 22, 2016 at 9:25:29 AM UTC+1, Ian Collins wrote:
> On 07/22/16 08:14 PM, jacobnavia wrote:
> 
> > I think you should look at c++. If you have a template, the template
> > code will be replicated in all your applications ALSO. Here the
> > situation  is exactly the same.
> 
> Not so.  A templated function is still a function, so it will only be 
> instantiated once where a macro will always be expanded.  With a 
> function template then compiler can choose whether to call or inline the 
> function.  With a function like macro it doesn't.
> 
Theoretically templates should be less code space hungry than macros.
In fact that's not the case, people tend to keep macros quite short,
whilst they cheerfully build templated classes that then expand into
an entire object file for every single type the template is instantiated
with. There's also a tendency for templates to encourage heavy use
of user-defined types.

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

#90775

On 07/22/16 09:17 PM, Malcolm McLean wrote:
> On Friday, July 22, 2016 at 9:25:29 AM UTC+1, Ian Collins wrote:
>> On 07/22/16 08:14 PM, jacobnavia wrote:
>>
>>> I think you should look at c++. If you have a template, the template
>>> code will be replicated in all your applications ALSO. Here the
>>> situation  is exactly the same.
>>
>> Not so.  A templated function is still a function, so it will only be
>> instantiated once where a macro will always be expanded.  With a
>> function template then compiler can choose whether to call or inline the
>> function.  With a function like macro it doesn't.
>>
> Theoretically templates should be less code space hungry than macros.
> In fact that's not the case,

I my experience it is and the code I wok with uses them extensively.

> people tend to keep macros quite short,

Not in a lot of code I've seen...

> whilst they cheerfully build templated classes that then expand into
> an entire object file for every single type the template is instantiated
> with.

Which can never produce more code than the equivalent solution with 
macros would produce.  If a class template is the cleanest solution (in 
the C++ world), use it.  Only the functions that get used will be 
instantiated (only once), so the net result is much the same as Jacob's 
solution.

> There's also a tendency for templates to encourage heavy use
> of user-defined types.

No, the two are orthogonal.  Templates simply make it easier to do 
generic things with user-defined types.

-- 
Ian

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

#90765

Le 22/07/2016 à 10:25, Ian Collins a écrit :
> On 07/22/16 08:14 PM, jacobnavia wrote:
>> Le 21/07/2016 à 18:48, jadill33@gmail.com a écrit :
>>
>>> However, I don't think it scales well.  If you have a suite of
>>> applications
>>> and you want to use the same containers generated using the macro
>>> interface,
>>> you have the potential to either duplicate code in each of the
>>> applications
>>> (e.g. app 1 and 2 uses a macro generated list of integers) or
>>> maintain some
>>> library of a mishmash of type specific containers that cover all of your
>>> applications.
>>>
>>
>> I think you should look at c++. If you have a template, the template
>> code will be replicated in all your applications ALSO. Here the
>> situation  is exactly the same.
>
> Not so.  A templated function is still a function, so it will only be
> instantiated once where a macro will always be expanded.  With a
> function template then compiler can choose whether to call or inline the
> function.  With a function like macro it doesn't.
>

If you look at CCL's code you will see that the macros are used for 
generic containers that will expand the WHOLE container code into a library

Suppose you have a "FOO" data type. The list macros will expand into
iFOOAdd, iFOOApply, etc for the whole list container code, so the 
generated code is always the full implementation of the list container. 
If you put that in a library, the linker will pull in only the functions 
you need.

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

#90774

On 07/22/16 09:28 PM, jacobnavia wrote:
> Le 22/07/2016 à 10:25, Ian Collins a écrit :
>> On 07/22/16 08:14 PM, jacobnavia wrote:
>>> Le 21/07/2016 à 18:48, jadill33@gmail.com a écrit :
>>>
>>>> However, I don't think it scales well.  If you have a suite of
>>>> applications
>>>> and you want to use the same containers generated using the macro
>>>> interface,
>>>> you have the potential to either duplicate code in each of the
>>>> applications
>>>> (e.g. app 1 and 2 uses a macro generated list of integers) or
>>>> maintain some
>>>> library of a mishmash of type specific containers that cover all of your
>>>> applications.
>>>>
>>>
>>> I think you should look at c++. If you have a template, the template
>>> code will be replicated in all your applications ALSO. Here the
>>> situation  is exactly the same.
>>
>> Not so.  A templated function is still a function, so it will only be
>> instantiated once where a macro will always be expanded.  With a
>> function template then compiler can choose whether to call or inline the
>> function.  With a function like macro it doesn't.
>>
>
> If you look at CCL's code you will see that the macros are used for
> generic containers that will expand the WHOLE container code into a library
>
> Suppose you have a "FOO" data type. The list macros will expand into
> iFOOAdd, iFOOApply, etc for the whole list container code, so the
> generated code is always the full implementation of the list container.
> If you put that in a library, the linker will pull in only the functions
> you need.

That's a good way to minimise macro bloat.

-- 
Ian

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

#90782

On Friday, July 22, 2016 at 4:14:55 AM UTC-4, jacobnavia wrote:
> Le 21/07/2016 à 18:48, j...@...com a écrit :
> > On Wednesday, July 20, 2016 at 5:07:14 PM UTC-4, jacobnavia wrote:
> >> Le 20/07/2016 à 20:49, Gareth Owen a écrit :
> >>> jacobnavia <j...@...fr> writes:
> >>>
> >>>> Lisp spends an awful lot of time checking the arguments, what C
> >>>> generated code doesn't do since the types are checked at compile time.
> >>>
> >>> ... says the man who implemented an entire container library using void*
> >>> pointers and essentially no type checking.
> >>>
> >> If you take some time to see the CCL you will see that there is a
> >> generic interface implemented with C macros, that allows you full
> >> compiler type checking if you want.
> >>
> >> See the implementation of the generic lists and others. Of course I was
> >> told that C macros are primitive and ugly, and what I wanted to do was
> >> impossible to do with C macros.
> >
> > Hmmm, I vaguely remember seeing SGLIB before the CCL.  At least there was
> > some prior art to a container library that used a macro interface.
> >
> Never heard of the "SGLIB". Where is it?

http://sglib.sourceforge.net/

I don't think it's been maintained for quite a while, but you can take a
look if you're curious.

Best regards,
John D.

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

#90544

On 18/07/2016 22:36, Ben Bacarisse wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:

>> The only difference is that in C notation the parentheses is AFTER the
>> verb like this:
>>
>> Verb ( arguments-list)
>
> There are other differences.  For example:
>
>   (+ a b c d)
>   (+ 1.2 1.5e-2 a b)
>   (+ 1/2 3 3/4)
>   (+ a #c(2 3) 1)
>   (+ a 1234567890987654321234567890987654321)

Most of these differences are those you would expect between a 
low-level, statically typed language, and what would appears to be a 
dynamically typed one with bignums and rationals thrown in.

(I don't know what #c(2 3) means. Perhaps no one knows everything that's 
in Lisp; last time I looked, only the kitchen sink was missing!)

So it is a little unfair. There are plenty of languages like the latter 
but which use conventional syntax.

Apart from that, the main difference is that (+ a b c) can be used in 
place of a+b+c, which would be awkward in infix notation. (Possible 
perhaps using the postfix form +(a b c), so that unary '+' operating on 
a list will sum elements of the list. Obviously that doesn't exist in C.)

>
>> That is exactly "lisp" notation but with parentheses moved.
>
> Exactly like it except for the variable number of arguments and the
> mixed types with the permitted types being different too.  And you
> wisely chose example functions with no keyword parameters.

C could easily have keyword arguments but this is one of those very 
obvious enhancements that no one is interested in adding. (I think 
lccwin might have it.)

> But the most important difference is that the C version doesn't buy you
> any advantages.  The Lisp form is designed to work as a unified whole
> with the rest of the language.  Small example: if you have a list of
> numbers, you can add them with the same addition function with (apply
> #'+ nums).

That is an example that is /apart/ from the rest of the language, as it 
can be bolted on. Example from one of mine:

function apply(op, L)=
     x := head(L)
     forall y in tail(L) do
         x := applyop(op, x, y)
     od
     return x
end

a := (10,20,30,40,50)
println apply((+), a)      # 150

-- 
Bartc

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

#90558

BartC <bc@freeuk.com> writes:

> On 18/07/2016 22:36, Ben Bacarisse wrote:
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>
>>> The only difference is that in C notation the parentheses is AFTER the
>>> verb like this:
>>>
>>> Verb ( arguments-list)
>>
>> There are other differences.  For example:
>>
>>   (+ a b c d)
>>   (+ 1.2 1.5e-2 a b)
>>   (+ 1/2 3 3/4)
>>   (+ a #c(2 3) 1)
>>   (+ a 1234567890987654321234567890987654321)
>
> Most of these differences are those you would expect between a
> low-level, statically typed language, and what would appears to be a
> dynamically typed one with bignums and rationals thrown in.

Yes.  You'd expect them.  I wonder why Jacob did not (or was his "The
only difference..." just polemic?).

<snip>
> So it is a little unfair. There are plenty of languages like the
> latter but which use conventional syntax.

It's unfair to use the actual differences between two things to show
that they are not the same as claimed?  Blimey, that's tough.  How would
you do it if showing the actual differences is a little unfair?

<snip>
-- 
Ben.

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

#90523

Le 18/07/2016 à 17:48, Ben Bacarisse a écrit :
> I want to make a meta-point: in general I'm wary of unbalanced
> criticism.  I think you should also point out some of the reason why
> this is a disadvantage that C has.

The disadvantages of C?

I have often spoken about those here and I tried to show a way out in my 
small compiler system lcc-win:

I added operator overloading to cope easily with other classes of 
numbers, user defined.

I added generic functions to be able to express several similar 
functions with a single name and different arguments

But I stick to C. And in the CCL there is nothing new: just C89.

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

#90540

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 18/07/2016 à 17:48, Ben Bacarisse a écrit :
>> I want to make a meta-point: in general I'm wary of unbalanced
>> criticism.  I think you should also point out some of the reason why
>> this is a disadvantage that C has.
>
> The disadvantages of C?

No, I said "this" and you cut the text to which that word refers.  It
was that "C doesn't impose a particular view of your data".  I'm not
sure what that means, but if you what's good and bad about that it would
be a string argument (as well as maybe making the notion clearer).

<snip>
-- 
Ben.

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

#90543

Le 18/07/2016 à 23:47, Ben Bacarisse a écrit :
> "C doesn't impose a particular view of your data".  I'm not
> sure what that means,

It means there isn't in C an unifying concept that has language scope 
like classes/templates in C++, or arrays in APL, or lists in Lisp.

C has lists, arrays, flexible arrays whatever, but none of those 
constructs has a primordial position.

In C++ you should do classes (at the beginning), templates (yesterday) 
or lambdas (now).

Now the problem with all those languages is that you have to fit your 
data into the language. Doesn't matter if you have no classes of objects 
in your data. If you are programming in SmallTalk you HAVE TO write a 
class. If you use APL, you have to use an array or a list in Lisp.

In C you can use anything YOU want, the labguage doesn't impose anything.

Absolute freedom. I like that.

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

#90545

On Tue, 19 Jul 2016 00:07:25 +0200
jacobnavia <jacob@jacob.remcomp.fr> wrote:

> Le 18/07/2016 à 23:47, Ben Bacarisse a écrit :
> > "C doesn't impose a particular view of your data".  I'm not
> > sure what that means,  
> 
> It means there isn't in C an unifying concept that has language scope 
> like classes/templates in C++, or arrays in APL, or lists in Lisp.
> 
> C has lists, arrays, flexible arrays whatever, but none of those 
> constructs has a primordial position.
> 
> In C++ you should do classes (at the beginning), templates
> (yesterday) or lambdas (now).
> 
> Now the problem with all those languages is that you have to fit your 
> data into the language. Doesn't matter if you have no classes of
> objects in your data. If you are programming in SmallTalk you HAVE TO
> write a class. If you use APL, you have to use an array or a list in
> Lisp.
> 
> In C you can use anything YOU want, the labguage doesn't impose
> anything.

You don't have to use structs or arrays?

> 
> Absolute freedom. I like that.
> 
> 

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

#90549

Le 19/07/2016 à 00:18, Melzzzzz a écrit :
>> In C you can use anything YOU want, the labguage doesn't impose
>> > anything.
> You don't have to use structs or arrays?
>
If you need to of course. But only if you need them.

You can also write useful programs without structures or arrays. You can 
do math work, input/output controllers, many things that do not require 
sophisticated data structures.

int fib(int n)
{
	double phi = (sqrt(5.0)+1)/2.0;
	return floor(pow(phi,n)/sqrt(5)+0.5);
}

Nice isn't it?

NO RECURSION!

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

#90547

On 07/19/16 10:07 AM, jacobnavia wrote:
> Le 18/07/2016 à 23:47, Ben Bacarisse a écrit :
>> "C doesn't impose a particular view of your data".  I'm not
>> sure what that means,
>
> It means there isn't in C an unifying concept that has language scope
> like classes/templates in C++, or arrays in APL, or lists in Lisp.
>
> C has lists, arrays, flexible arrays whatever, but none of those
> constructs has a primordial position.
>
> In C++ you should do classes (at the beginning), templates (yesterday)
> or lambdas (now).

You don't you your cause any favours writing nonsense like that. 
Slagging off C++ (or any other language) doesn't promote your cause, it 
just makes you look bitter.

> Now the problem with all those languages is that you have to fit your
> data into the language. Doesn't matter if you have no classes of objects
> in your data. If you are programming in SmallTalk you HAVE TO write a
> class. If you use APL, you have to use an array or a list in Lisp.

But if you are writing in a multi-paradigm language such as C++ you have 
a choice!  You can do things exactly as you would in C or or can wholly 
adopt the C++ standard library or you can pick a happy place in between.

> In C you can use anything YOU want, the labguage doesn't impose anything.
>
> Absolute freedom. I like that.

That statement (modulo typos) applies equally to both C and C++....

-- 
Ian

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

#90557

On 7/18/2016 6:28 PM, Ian Collins wrote:
> On 07/19/16 10:07 AM, jacobnavia wrote:
>> Le 18/07/2016 à 23:47, Ben Bacarisse a écrit :
>>> "C doesn't impose a particular view of your data".  I'm not
>>> sure what that means,
>>
>> It means there isn't in C an unifying concept that has language scope
>> like classes/templates in C++, or arrays in APL, or lists in Lisp.
>>
>> C has lists, arrays, flexible arrays whatever, but none of those
>> constructs has a primordial position.
>>
>> In C++ you should do classes (at the beginning), templates (yesterday)
>> or lambdas (now).
> 
> You don't you your cause any favours writing nonsense like that.
> Slagging off C++ (or any other language) doesn't promote your cause, it
> just makes you look bitter.
> 
>> Now the problem with all those languages is that you have to fit your
>> data into the language. Doesn't matter if you have no classes of objects
>> in your data. If you are programming in SmallTalk you HAVE TO write a
>> class. If you use APL, you have to use an array or a list in Lisp.
> 
> But if you are writing in a multi-paradigm language such as C++ you have
> a choice!  You can do things exactly as you would in C or or can wholly
> adopt the C++ standard library or you can pick a happy place in between.
> 
>> In C you can use anything YOU want, the labguage doesn't impose anything.
>>
>> Absolute freedom. I like that.
> 
> That statement (modulo typos) applies equally to both C and C++....
> 

He obviously has no real familiarity with C++.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#90556

On 7/18/2016 6:07 PM, jacobnavia wrote:
> Le 18/07/2016 à 23:47, Ben Bacarisse a écrit :
>> "C doesn't impose a particular view of your data".  I'm not
>> sure what that means,
> 
> It means there isn't in C an unifying concept that has language scope
> like classes/templates in C++, or arrays in APL, or lists in Lisp.
> 
> C has lists, arrays, flexible arrays whatever, but none of those
> constructs has a primordial position.
> 
> In C++ you should do classes (at the beginning), templates (yesterday)
> or lambdas (now).
>

Classes, templates and lambdas are three different solutions to three
different problems.

> Now the problem with all those languages is that you have to fit your
> data into the language. Doesn't matter if you have no classes of objects
> in your data. If you are programming in SmallTalk you HAVE TO write a
> class. If you use APL, you have to use an array or a list in Lisp.
> 

No more in C++ than in C.  In either, you fit your code to the existing
data.

> In C you can use anything YOU want, the labguage doesn't impose anything.
> 
> Absolute freedom. I like that.
> 
> 

No difference in C++.  Anything you can do in C you can do in C++.  You
just have more tools with which to work.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#90564

On Tuesday, July 19, 2016 at 1:33:29 AM UTC+1, Jerry Stuckle wrote:
> On 7/18/2016 6:07 PM, jacobnavia wrote:
> 
> Classes, templates and lambdas are three different solutions to three
> different problems.
> 
Yes and no.
The problem that all that syntax and machinery addresses is mainly
one of trivial data reformatting.

We want to take a mean. So obviously we need to pass a list of numbers
to an accumulator, sum them, count them, then divide the sum by the
count.
But the numbers could be represented in several formats - integers
of different widths, floats in various formats, maybe even strings
or bignums. Then the languages themselves tend to allow aliasing of
basic types. The underlying bits might be 32-bit integer, but
the language sees it as a "currency". Then the list itself is
unlikely to be a contiguous array in memory, more likely it is
"salary" fields in an "employee" structure. 

Classes, via inheritance or dynamic binding, allow the "mean" function
to be soft-coded to anything with a "salary" member. Templates
allow the type to be "currency" or "x,y co-ordinates", as long as it
supports the basic arithmetical operations. Lambdas allow the user
to pass in a function to extract either the salary, or the tax to date.

But you can recast these operations in terms of each other (declare
a base class with a virtual "getActiveScalarField()" method, and
you have a lambda). And they are all achieving essentially the same
goal. 

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

#90553

On Monday, July 18, 2016 at 10:47:34 PM UTC+1, Ben Bacarisse wrote:
> 
> No, I said "this" and you cut the text to which that word refers.  It
> was that "C doesn't impose a particular view of your data".  I'm not
> sure what that means, but if you what's good and bad about that it would
> be a string argument (as well as maybe making the notion clearer).
> 
In Lisp, everything is a tree. In Javascript, everything is a
hash table. In Matlab, everything is  matrix. In C++, everything
is a class or controlled sequence.
In C, everything is bits, with a light layer of abstraction over
them to represent the types the machine has built-in operations
for, and a tagging scheme for addresses which the language allows
you to easily circumvent if it breaks down.

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

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

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

csiph-web