Not Lisp again (2009)

Post by marcosdumay » Tue, May 02, 2017, 7:53 PM UTC

kazinator wrote: post #65

marcosdumay wrote: post #13

Earlier quoted context omitted.

To be fair, the one time I decided to do something biggish and kinda important in Lisp, I stopped at #3. Not exactly because "it does not have many libraries", but because "library for X, Y and Z are not there and I don't want to write them". Oddly, Haskell has a similar problem, but going through C code by the FFI does not feel like a problem. I don't think why it does in Lisp, it may be just a matter of better docu…

I'm working on FFI for TXR Lisp. Until this morning, it was in the stage of "collection of working API functions, written in C, exposed with Lisp bindings". I have almost everything I want working, including callbacks. There is a decently rich type system which supports pointers that annotate data passing directions for automatic malloc and free, and this works in both directions: out calls and callbacks (closures).…

Post by thoth » Tue, May 02, 2017, 7:55 PM UTC

mnarayan01 wrote: post #95

BoiledCabbage wrote: post #37

Earlier quoted context omitted.

It's been stated a number of times, but x.f(y, z) has just as many parens as (f x y z). And Haskell particularly comes with so many syntax quirks. There is a lot of cruft you need to learn to get to the underlying functional core of haskell. Lips you can get 100% of the cruft out within a few days / 1 week. And the rest is just understanding programming concepts. I don't use any LISP on a regular basis, but it still…

x + y * z has way fewer than (+ x (* y z)) though. I'm not arguing for one or the other, but e.g. infix operators do have upsides.

Post by brlewis » Tue, May 02, 2017, 8:00 PM UTC

Will_Parker wrote: post #83

brlewis wrote: post #73

Earlier quoted context omitted.

f(x + dx) does look more conventional than (f (+ x dx)), but (/ numerator denominator) looks more like the conventional fraction syntax than putting a / somewhere in the middle of a line.

I'll give you that but also, ask 100 random people what "3/4" means and what "(/ 3 4)" means.

Post by concede_pluto » Tue, May 02, 2017, 8:00 PM UTC

davexunit wrote: post #114

drdre2001 wrote: post #102

Earlier quoted context omitted.

How? Functions are first class in lisp.

Functional programming is but one of the many paradigms that you can use in Lisp, along with imperative, object-oriented, relational, etc. When you say a language is a functional language, you are saying that it is the paradigm supported, which is not the case here.

Post by smitherfield » Tue, May 02, 2017, 8:03 PM UTC

smitherfield wrote: post #127

AnimalMuppet wrote: post #46

Earlier quoted context omitted.

Well, in 1992 (IIRC), I did a numerical integration in C. For a "first class function", it just took a function pointer. That approach would have been available in C in 1983...

He is right, you could do something roughly equivalent in 1983-era C, albeit a fair amount clunkier due to the lack of partial application or (any kind of) type-checking: #define DX (double)0.0001 double f_prime(f, x) register double (*f)(); double x; { return ((*f)(x + DX) - (*f)(x)) / DX; } #define DERIV(F, X) f_prime((F), (double)(X)) double cube(x) double x; { return x * x * x; } #define DERIV_CUBE(X) DERIV(cube,…

  #include 

  double deriv(double (*f)(double), double x)
  {
          static const double dx = 1e-8;
          return (f(x + dx) - f(x)) / dx;
  }

  static double cube(double x)
  {
          return x * x * x;
  }

  double deriv_cube(double x)
  {
          return deriv(cube, x);
  }

  int main(void)
  {
          printf("%f\n%f\n%f\n", deriv_cube(2), deriv_cube(3), deriv_cube(4));
          return 0;
  }