> in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach;

I wrote a compile-time test framework in 7 lines of Gambit Scheme code https://github.com/billsix/bug/blob/master/README.md

Clojure has implementations of CSP, Minikanren and pattern matching all done with macros. I'm not sure how you can call these toy examples

You make an interesting point about types, but

> (2) in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach

I've seen and built tons of exotic stuff with macros. On Lisp builds a Prolog compiler if you want a specific example.

Your point about types makes me curious about LINQ. Brings to mind Julia's generated functions.

>for example .NET’s LINQ cannot be expressed in LISP, not unless you add a static type system

Doesn't that imply that Lisp, sans-static typing, is not Turing-Complete? Surely that is not the case.

Of course not. You could always implement C# (static types and all) and LINQ atop Lisp, or indeed any other turing complete language.[1]

The point of static type systems isn't that they add power -- it's that they take power away. Thus empowering the programmer to reason in a restricted subset of "all the possible things".

[1] I'm ignoring the detail of there actually being a way to interface with the actual physical hardware, but I think we can assume that in any remotely practical TC language.

A Turing machine is Turing-complete.

Good luck expressing LINQ syntax, or Lisp syntax, or even Basic-80 syntax on it.

Syntax is important, it's a tool of thought.

I understood the post to which I replied to be arguing that LINQ could not be expressed in Lisp, not that Lisp doesn't have the correct syntax.

Surely you can write LINQ in any Turing-complete language.

I guess the question you are begging is: how far can Lisp-LINQ go from the syntax, semantics, and ergonomics of C#'s LINQ before you stop calling it LINQ?

Turing completeness doesn't describe expressivity of source code, as far as I understand it - it describes the ability to produce a desired outcome. So yes, you can perform the same operations LINQ allows, in Lisp or any other Turing-complete language. But can you do it while giving the programmer the same (or a similar enough) experience? From the .NET docs:

> Language-integrated query allows query expressions to benefit from the rich metadata, compile-time syntax checking, static typing and IntelliSense that was previously available only to imperative code. Language-integrated query also allows a single general purpose declarative query facility to be applied to all in-memory information, not just information from external sources.

Now, to be fair, I'm not sure you can express all that in Haskell either. And it could be reasonable to argue that a few of those benefits (e.g. intellisense) just _haven't_ been done for Lisp, not necessarily that they _can't_ be done.

Syntax is different from abstraction. The problem in doing those things in turing machines and assembly is the low level of programming. Otherwise their syntax is pretty simple: commands and operands.

https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis

It's lambda complete. Which has been famously proven to be the same as turing complete.

Also type checking is basically more or less putting restrictions on your code. If there is a language that doesn't have the syntax to compute certain things, how would restricting that language via type checking suddenly cause it to be able to compute everything and be turing complete? Makes no sense. To make a language change from not turing complete to turing complete you have to expand.. not restrict ... but expand it's computational ability. Again Type checking serves to restrict.

Type checking is essentially just pre runtime special syntax for:

  define add (x,y)
      if type(x) != 'int' or type(y) != 'int':
           throw TypeError
      return x+2

or in a lisp like functional language:

   (define (int) (x) 
      (if (equal? type(x) 'int') (x) (error 'Type Error'))

   (define add (x y))
      (+ int(x) int(y)))

It's not a big deal. I'm not sure what LINQ is, but you don't have to add a type checking system to a language to do type checking if you know what I mean.

He doesn't know what he's talking about.

Type checking is much more than that. It is not the same as throwing exceptions when types don't match; it is about proving that a type checked program will never produce type errors.

You're right. I wanted to illustrate that type checking shouldn't be a factor in the the parents context as you can use code to explicitly type check or prove it.

> .NET’s LINQ cannot be expressed in LISP

That's an extraordinary claim. Do you have extraordinary evidence to back it up?

The advantage of LINQ in my eyes is that it allows you to build an expression tree that you can wait to evaluate until a result is actually needed.

Then the provider can decide how it wants to do it, based on the types and operations involved. A SQL DB based provider can’t safely push any work to the database if it doesn’t know the structure or types of the objects and properties in the expression tree. It would have to return whole tables and perform all evaluation in the app where types could be handled dynamically.

I think something like typed racket or clojure may support it, but many lisps would not.

Common Lisp has a way better OO type system than C#. It has to be queried at run-time, granted, but that doesn't stop something like LINQ from working.

This may be true - I've not used Common Lisp, only Racket.

> The advantage of LINQ in my eyes is that it allows you to build an expression tree that you can wait to evaluate until a result is actually needed.

Isn't that the exact definition of the "unquote" and "unquote-splicing" operators inside a quasiquote?

Honestly asking since I'm not past the "makes my head hurt" stage of scheme macros, probably doesn't help that the quasiquote macro is buggy in my minischeme sandbox.

It's been a while, and I've only really used Racket extensively, but "unquote" and "unquote-splicing" operate at macro expansion time, not run time. So unless you're using a typed lisp like Typed Racket, the macro won't have enough information to (for example) know that something is a number vs a string - the kind of distinction that's important for efficient and correct SQL query generation.

I wonder how much better Scheme with its static typing extensions fare im this regard.

IDEs? You mean emacs?

Also see Dr. Racket.