4 ms·
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 pr
by kogir 8y ago
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.
- jaccarmac 8y agoCommon 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.
- kogir 8y agoThis may be true - I've not used Common Lisp, only Racket.
- deleted 8y ago[deleted]
- UncleEntity 8y ago> 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.
- kogir 8y agoIt'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.