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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#90639

On Wednesday, July 20, 2016 at 6:03:10 AM UTC+1, Udyant Wig wrote:
> On 07/19/2016 02:13 PM, Malcolm McLean wrote:
> > It's easy to write the interpreter for Lisp.
> 
>   You have repeated this.
> 
> > In the 1950s, when programs were entered on punched cards into
> > computers with tiny memories, and there were few professional
> > programmers, that was a very important, reasonable design goal.
> 
>   Do you have a source for this claim?
> 
>   There already was a Lisp compiler in 1962.
> 
There's more to being a scholarly man than saying "do you have
a source for this claim?". You expect a source for the claim
that computers in the 1950s had tiny memories?
>
> > But the language gives the interpreter, not the human programmer, the
> > ideal environment to work in.
> 
>   You made no mentions about ideals earlier.  Why bring it up now?
> 
>   You repeat that it is not an (ideal) environment for the human
>   programmer.  But you do not establish this in any way.
> 
I've said Lisp doesn't give an ideal environment for the human
programmer, and I've given a plausible explanation, which is that
there is trade-off between the human programmer's needs and the
need to make the interpreter easy to write, and I've also explained
why that was more important when Lisp was designed than now.

So actually the claim is pretty solidly backed up. Not irrefutable,
but not a claim made up out of thin air.

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

#90711

On 07/20/2016 01:37 PM, Malcolm McLean wrote:
> There's more to being a scholarly man than saying "do you have a
> source for this claim?". You expect a source for the claim that
> computers in the 1950s had tiny memories?

  Perhaps I worded the question badly or perhaps you misread it. Let me
  make it unambiguous, anyhow.

  Do you have a source for the claim that making it easy to write an
  interpreter was an design goal for Lisp?
  
> I've said Lisp doesn't give an ideal environment for the human
> programmer, and I've given a plausible explanation, which is that
> there is trade-off between the human programmer's needs and the need
> to make the interpreter easy to write, and I've also explained why
> that was more important when Lisp was designed than now.
> 
> So actually the claim is pretty solidly backed up. Not irrefutable,
> but not a claim made up out of thin air.

  That there is a trade-off between programmers' needs and computers' is
  a truism is software.  Just as the designers of C omitted many useful
  facilities from C in order to get speed from their programs on their
  machines.

  S-expressions were to be just the internal form of Lisp.  However, the
  proposed form of Lisp programs, M-expressions, never came about.  The
  programmers, presumably human, found the existing notation ideal for
  many things not originally prepared for.

  So, while I grant that making the environment easy to write would have
  had some significance, I do not remember reading it being a goal of
  the design, which was what you claimed.  Hence my question.
  
-- 
Udyant Wig

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

#90583

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Tuesday, July 19, 2016 at 1:55:05 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> > On Monday, July 18, 2016 at 10:32:27 PM UTC+1, jacobnavia wrote:
>> >> 
>> >> I am the author of the Common Lisp Plus (CL+) lisp interpreter that I 
>> >> developed between 1985 and 1993. Starting with Betz's free lisp 
>> >> interpreter I developed a full implementation of Common Lisp, complete 
>> >> with setf special forms, bignums, and a compiler that translated the 
>> >> lisp virtual machine code (byte code) into straight C.
>> >> 
>> > Typical.
>> > As I said, it's the only language which is easier to write the
>> > interpreter for than to write the simplest non-trivial program
>> > in.
>> 
>> Is there any actual evidence (such as watching me write a simple
>> non-trivial program in Lisp) that could convince you that you are
>> wrong?

Can you at least say that you won't answer this question?  Obviously you
don't owe me an answer, but I' like to know for sure that there's no
point in asking again.

>> I note you've pulled a sneaky switch -- it's now a "non-trivial program"
>> where before it was a "basic function in Lisp".  Can I assume that
>> you've decided that at least that piece of polemic is untenable?

And this?  Will you answer it or shall I just move one?

<snip lisp examples>
> Now are you seriously telling me that you can give that to
> an average person and expect any type of comprehension about
> what it is doing?

No, I'm not.  Why would you think I was saying that and what has that to
do with your preposterous claims above?

<snip>
-- 
Ben.

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

#90587

On Tuesday, July 19, 2016 at 3:33:22 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> >> Is there any actual evidence (such as watching me write a simple
> >> non-trivial program in Lisp) that could convince you that you are
> >> wrong?
> 
> Can you at least say that you won't answer this question?  Obviously you
> don't owe me an answer, but I' like to know for sure that there's no
> point in asking again.
> 
Ok, apologies for the length of this post.

Here's a short by real program to generate Worley noise. Worley noise is a
sort of Voronoi cell noise - the noise function is based on a Voronoi cell
structure generated from  random seed points.
 
The actual noise function is a distance measure - Euclidean, Manhattan, and
so forth.

Obviously you need a graphical output, and I'm writing to a PNG, but that's not
the focus of the exercise. We'll assume there's a Lisp function available that
does that for us (if not output as a BMP or other simple format).

To explain how to call the Worley function, 
out, width and height are the raster output buffer.
Points is the list of seed points (which should extend slightly beyond the limits
of the output buffer).
maxdist tells us how closely the points are spaced, to help the function out
a bit.
distfunc is the function used to calculate the nearest point to each pixel in the
output buffer.
noisefunc is the function that generates noise based on the three nearest points,
(N is usually 3, but may be lower at edge conditions).



#include <stdlib.h>
#include <math.h>

#include "worleynoise.h"

struct plist
{
  double x;
  double y;
  struct plist *next;
};

static int pointtocell(Point2 *pt, double maxdist, int width, int height);

int worleynoise(unsigned char *out, int width, int height, Point2 *points, int Npoints, double maxdist, double (*distfunc)(Point2 *p, Point2 *q),
		double (*noisefunc) (void *ptr, Point2 *pt, Point2 *nearest, int N, double maxdist), void *ptr)
{
  int Nx, Ny;
  struct plist **cells = 0;
  struct plist *pbuff = 0;
  struct plist *cptr;
  int i, ii;
  int x, y;
  int ix, iy;
  int index;
  double best1, best2, best3;
  Point2 bestpts[3];
  int Nbest;
  Point2 p, q;
  double d;

  Nx = (int) ceil(width/maxdist) + 2;
  Ny = (int) ceil(height/maxdist) + 2;

  cells = malloc(Nx * Nx * sizeof(struct plist *));
  if(!cells)
    goto error_exit;

  for(i=0;i<Nx*Ny;i++)
    cells[i] = 0;
  pbuff = malloc(Npoints * sizeof(struct plist));
  if(!pbuff)
    goto error_exit;

  for(i=0;i<Npoints;i++)
  {
    pbuff[i].x = points[i].x;
    pbuff[i].y = points[i].y;
    index = pointtocell(&points[i], maxdist, width, height);
    if(index != -1)
    {
      pbuff[i].next = cells[index];
      cells[index] = &pbuff[i];
    }
  }
  for(y=0;y<height;y++)
  {
    for(x=0;x<width;x++)
    {
      p.x = x;
      p.y = y;
      Nbest = 0;
      best1 = 100000000000;
      best2 = 200000000000;
      best3 = 300000000000;
      ix = (int) floor(p.x / maxdist);
      iy = (int) floor(p.y / maxdist);

      for(i=0;i<3;i++)
        for(ii=0;ii<3;ii++)
	{
	  for(cptr = cells[(iy+i)*Nx+ix+ii]; cptr; cptr=cptr->next)
	  {
            q.x = cptr->x;
            q.y = cptr->y;
            d = (*distfunc)(&p, &q);
            if(d < best1)
	    {
              bestpts[2] = bestpts[1];
              bestpts[1] = bestpts[0];
              bestpts[0] = q;
              best3 = best2;
              best2 = best1;
              best1 = d;
              Nbest++;
            }
            else if(d < best2)
	    {
              bestpts[2] = bestpts[1];
              bestpts[1] = q;
              best3 = best2;
              best2 = d; 
              Nbest++;
	    }
            else if(d < best3)
	    {
              bestpts[2] = q;
              best3 = d;
              Nbest++;
	    }
	  }
	}
      if(Nbest)
	out[y*width+x] = (unsigned char)((*noisefunc)(ptr, &p, bestpts, Nbest, maxdist) * 255);
      else
        out[y*width+x] = 0;
    }
  }

  free(pbuff);
  free(cells);
  return 0;

 error_exit:
  free(pbuff);
  free(cells);
  return -1;
} 
  
static int pointtocell(Point2 *pt, double maxdist, int width, int height)
{
  int Nx = (int) ceil(width/maxdist) + 2;
  int Ny = (int) ceil(height/maxdist) + 2;
  int ix = (int) floor(pt->x / maxdist);
  int iy = (int) floor(pt->y / maxdist);

  if(ix <-1 || ix > Nx -2 || iy <-1 || iy > Ny -2)
    return -1;

  return (iy+1)*Nx+ix+1;
}


#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>

#include "lodepng.h"
#include "worleynoise.h"

#define uniform() (rand() / (RAND_MAX + 1.0))

int savenoise(unsigned char *noise, int width, int height)
{
  unsigned char *rgba;
  int i;

  rgba = malloc(width * height * 4);
  if(!rgba)
    goto error_exit;
  for(i=0;i<width*height;i++)
  {
    rgba[i*4] = 0;
    rgba[i*4+1] = 0;
    rgba[i*4+2] = 0;
    rgba[i*4+3] = noise[i];
  }
  lodepng_encode32_file("worleynoise.png", rgba, width, height);
  free(rgba);
  return 0;
 error_exit:
  free(rgba);
  return -1;
}

double canberra(Point2 *p, Point2 *q)
{
  return (fabs(p->x-q->x) + fabs(p->y-q->y))/(fabs(p->x) + fabs(p->y) + fabs(q->x) + fabs(q->y) +0.001);
}

double manhattan(Point2 *p, Point2 *q)
{
  return fabs(p->x-q->x) + fabs(p->y - q->y);
}
double euclid(Point2 *p, Point2 *q)
{
  return (p->x-q->x)*(p->x-q->x) + (p->y-q->y)*(p->y-q->y);
}

double chebyshev(Point2 *p, Point2 *q)
{ 
  double dx = fabs(p->x - q->x);
  double dy = fabs(p->y - q->y);
  return dx > dy ? dx : dy;
}

double minowsky3(Point2 *p, Point2 *q)
{
  double dx = pow(fabs(p->x - q->x), 3.3);
  double dy = pow(fabs(p->y - q->y), 3.3);

  return pow(dx+dy, 1/3.3);
}

double noise1(void *ptr, Point2 *p, Point2 *q, int Nq, double maxdist)
{
  
  double answer = 0.0;
  if(Nq > 0)
    answer  = 1.0 - sqrt(euclid(p, q))/maxdist;
  if(answer < 0)
    answer = 0.0;
  return answer;
}

double noise2(void *ptr, Point2 *p, Point2 *q, int Nq, double maxdist)
{
  
  double answer = 0.0;
  if(Nq >= 2)
    answer  = 1.0 - manhattan(p, &q[0])/maxdist;
  if(answer < 0)
    answer = 0.0;
  return answer;
}

double noisev(void *ptr, Point2 *p, Point2 *q, int Nq, double maxdist)
{
  double da, db;
  if(Nq >= 2)
  {
    da = canberra(p, &q[0]);
    db = canberra(p, &q[1]);
    if(db - da < 3.0)
      return 1.0 - (db - da)/3.0;
  }
  return 0.0;
}

int main(void)
{
  unsigned char *noise = malloc(2560 * 2560);
  Point2 pts[10000];
  int Npts =  10000;
  int i;
  clock_t tick, tock;

  for(i=0;i<Npts;i++)
  {
      pts[i].x = uniform() * 2700 - 25;
      pts[i].y = uniform() * 2700 - 25;
  }
  
  tick = clock();
  worleynoise(noise, 2560, 2560, pts, Npts, 40.0, canberra, noisev, 0);
  tock = clock();
  printf("time %g\n", ((double)(tock - tick))/CLOCKS_PER_SEC);   
  savenoise(noise, 2560, 2560);

  return 0;
}

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

#90599

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Tuesday, July 19, 2016 at 3:33:22 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> >> Is there any actual evidence (such as watching me write a simple
>> >> non-trivial program in Lisp) that could convince you that you are
>> >> wrong?
>> 
>> Can you at least say that you won't answer this question?  Obviously you
>> don't owe me an answer, but I' like to know for sure that there's no
>> point in asking again.
>> 
> Ok, apologies for the length of this post.

No need, really -- long posts are often good.  The problem here is not
the length but the fact that it does not answer my question.  It does
not answer my meta-question either (as to whether you will ever answer
it) except in so far as it adds more evidence that you won't.

Of course you cut the other question, *and* both claims to which my
questions relate.  Was that meant to make your posted code appear
relevant to the casual reader?  Shall I re-instate them or are you just
going to plough on saying new stuff until everyone forgets what you said
before?

<snip code>

Interesting program.

-- 
Ben.

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

#90619

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Is there any actual evidence (such as watching me write a simple
> non-trivial program in Lisp) that could convince you that you are wrong?

There is literally nothing in the world that can convince Malcolm that
he is wrong about anything.  It's his defining characteristic.

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

#90646

I must appologize.  I didn't pay attention enough and answered the wrong
post (I tend to read all messages available and then write my answers) and
that changed the meaning of my answer, making me apparently disaggreeing on
a point on which I've myself made and I'm still agreeing.  I don't think
trying to remake the point I intended to make would be worthwhile now.

Yours,

--
Jean-Marc

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

#90551

On Monday, July 18, 2016 at 8:46:07 PM UTC+1, Jean-Marc Bourguet wrote:
> 
> The interest of lisp has nothing to do with the notation -- the sexp one
> was first destinated to be an temporary one, but it fills its purpose well
> enough that it has never been displaced although there were several
> variants which used infix and a position of parenthesis that you'd find
> more familiar.
> 
A mathematician told me that it turns out that the fundamental basis
of mathematics is the notation used to describe the operations.
Not something I understand deeply, but I think I can see how
that s true. 

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

#90836

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Monday, July 18, 2016 at 8:46:07 PM UTC+1, Jean-Marc Bourguet wrote:
> > 
> > The interest of lisp has nothing to do with the notation -- the sexp one
> > was first destinated to be an temporary one, but it fills its purpose well
> > enough that it has never been displaced although there were several
> > variants which used infix and a position of parenthesis that you'd find
> > more familiar.
> > 
> A mathematician told me that it turns out that the fundamental basis
> of mathematics is the notation used to describe the operations.

Ah.

That must explain why the Greeks, and the Romans, and the Eqyptians,
none of whom had the + and = signs or the superscript 2, never
discovered Pythagoras' theorem.

Richard

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

#90837

On Saturday, July 23, 2016 at 10:24:31 AM UTC+1, Richard Bos wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> 
> > On Monday, July 18, 2016 at 8:46:07 PM UTC+1, Jean-Marc Bourguet wrote:
> > > 
> > > The interest of lisp has nothing to do with the notation -- the sexp one
> > > was first destinated to be an temporary one, but it fills its purpose well
> > > enough that it has never been displaced although there were several
> > > variants which used infix and a position of parenthesis that you'd find
> > > more familiar.
> > > 
> > A mathematician told me that it turns out that the fundamental basis
> > of mathematics is the notation used to describe the operations.
> 
> Ah.
> 
> That must explain why the Greeks, and the Romans, and the Eqyptians,
> none of whom had the + and = signs or the superscript 2, never
> discovered Pythagoras' theorem.
> 
I'm not a mathematician so I don't understand fully what my friend
intended by that. But you don't either.

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

#90539

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

> Le 18/07/2016 à 17:48, Ben Bacarisse a écrit :
>> You should probably pick up a book about Lisp before you start saying
>> that the above has anything but the most superficial similarity to a
>> Lisp form.
>
> (Verb arguments-list)
>
> "arguments-list" --> (Verb arguments) | scalar
>
> add(a,divide(add(b,4),5)))
>
> 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)

> 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.

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).

-- 
Ben.

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

#90542

Le 18/07/2016 à 23:36, Ben Bacarisse a écrit :
> Exactly like it except for the variable number of arguments and the
> mixed types with the permitted types being different too.

Yes, and that is a big problem. At run time, you have to check that the 
passed parameters make sense:

(+ 123 "apples" "oranges")

does not work in lisp either. This checking at run time is the principal 
reason the speed of lisp is quite low, even when compiling it.

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.

That was one of the reasons I liked C. raw speed!

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

#90559

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

> Le 18/07/2016 à 23:36, Ben Bacarisse a écrit :
>> Exactly like it except for the variable number of arguments and the
>> mixed types with the permitted types being different too.
>
> Yes, and that is a big problem.

The question was not if it was a problem or not, but simply if the C
expression was "exactly the same" as the Lisp form.  It look as if you
now agree that the two are different -- different enough for one to have
a big problem.

<snip>
-- 
Ben.

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

#90680

jacobnavia <jacob@jacob.remcomp.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.

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

#90682

On Wednesday, July 20, 2016 at 1:49:11 PM UTC-5, gwowen wrote:
> ... says the man who implemented an entire container library using void*
> pointers and essentially no type checking.

On many platforms, all data pointers have the same representation;
nice implementations for such platforms allow a void** to be used to
manipulate any of them without regard for the target data type, but
reliable support for such things seems to have become unfashionable.
LISP used to apply type checking to ensure that use of an improper type
wouldn't allow execution to continue with erroneous behavior.  Modern C
compilers use their type systems to find "optimizations" that will cause
erroneous behavior.

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

#90685

supercat@casperkitty.com writes:
> On Wednesday, July 20, 2016 at 1:49:11 PM UTC-5, gwowen wrote:
>> ... says the man who implemented an entire container library using void*
>> pointers and essentially no type checking.
>
> On many platforms, all data pointers have the same representation;
> nice implementations for such platforms allow a void** to be used to
> manipulate any of them without regard for the target data type, but
> reliable support for such things seems to have become unfashionable.

On all platforms, a value of any pointer-to-object type can be
converted to void* and back again without loss of information.
(Independently of that, such conversions can be done implicitly.)
I haven't studied jacob's container library, but I expect that
it takes advantage of that without making any assumptions about
pointer representation.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#90695

On Wednesday, July 20, 2016 at 2:32:44 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > On many platforms, all data pointers have the same representation;
> > nice implementations for such platforms allow a void** to be used to
> > manipulate any of them without regard for the target data type, but
> > reliable support for such things seems to have become unfashionable.
> 
> On all platforms, a value of any pointer-to-object type can be
> converted to void* and back again without loss of information.
> (Independently of that, such conversions can be done implicitly.)
> I haven't studied jacob's container library, but I expect that
> it takes advantage of that without making any assumptions about
> pointer representation.

In dialects where all data pointers have the same representation
regardless of type, and where code is allowed to take the address of
a pointer of any type, cast it to void**, and pass it to a function
which accepts that type, realloc-style functions can be called much
more conveniently than in dialects which don't allow such usage.

Otherwise, I suspect the use of void* likely stems from the fact that
while it would make sense to have a `fooNode` hold a `fooNode *next`
and `barNode` hold a `barNode *next`, type aliasing issues will break
code that wants to be able to traverse linked lists of either type
unless all such code uses the same type for the "next node" link; the
only type which is guaranteed to work is `void*`.

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

#90686

supercat@casperkitty.com writes:

> On Wednesday, July 20, 2016 at 1:49:11 PM UTC-5, gwowen wrote:
>> ... says the man who implemented an entire container library using void*
>> pointers and essentially no type checking.
>
> On many platforms, all data pointers have the same representation;
> nice implementations for such platforms allow a void** to be used to
> manipulate any of them without regard for the target data type, but
> reliable support for such things seems to have become unfashionable.

???

> LISP used to apply type checking to ensure that use of an improper type
> wouldn't allow execution to continue with erroneous behavior.  Modern C
> compilers use their type systems to find "optimizations" that will cause
> erroneous behavior.

???

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

#90692

On Wednesday, July 20, 2016 at 2:49:11 PM UTC-4, gwowen wrote:
> 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.

I think that the CCL does have some options, but not sure how much value
it's worth to rig some approximation of "type" checking into it.

One possibility is to instrument the container interface with a macro
that stringizes the data type and store that locally.  Would work for
monolithic containers (like arrays) with their own managed data structures,
but be more cumbersome for distributed containers with independently
allocated nodes like trees or linked lists.

In my mind, it would look something like this.  When you create an array,
your macro interface would take a type, and you'd pass it to the layer
underneath like so.

#define array_new( type, size ) \
  array_alloc_under_the_hood( sizeof (type), (size), #type )

struct array_type*
array_alloc_under_the_hood( size_t sz, size_t n, const char* typename );

Your 'struct array_type' would manage everything using void*, but also
have a string representing the type.  It would be a little clunky since
it wouldn't be able to distinguish between typedefs for the same type.

If you're willing to type check access of an element from a container
when specifying the type, one could again use a macro, perform a string
comparison at runtime that the specified type matches the stored type
identifier in the container and have some modicum of type checking.
Figuring out an easy to use interface to handle a type mismatch at
runtime seems to me to be difficult.  One could in a debug environment
just throw an assert and alert the developer of the mismatch.  Kaz has
an exception library that might be feasible to handle runtime type
mismatches.

If you had a typeid extension, you can do something similar with a
potentially lower runtime cost for "type" checking for containers than
using strings, and in theory it might get around the typedef issue.  At
the very least, you could use 'sizeof' for a very rough "type" check by
comparing that the type sizes are at least the same.  If you have to, one
could hash the type string to assign unique values to each type (provided
you workaround duplicate hash values appearing for different typenames).

Not certain how feasible it would be for CCL, but I think there's potential
that a container library that manages void* pointers could implement some
kind of "type" checking with additional runtime cost.  Would probably
want some kind of compile time #define to enable/disable the checking since
it would likely introduce a non-insignificant runtime cost.

Best regards,
John D.

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

#90697

Le 20/07/2016 à 20:49, Gareth Owen a écrit :
> jacobnavia <jacob@jacob.remcomp.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.

But the code is there. Before spreading FUD please take the time to 
learn what you are talking about

Thanks

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

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

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

csiph-web