51–58 of 58 posts
Depends on the Lisp in question, I guess. I don't know how it is in Scheme, but in both Common Lisp and Emacs Lisp CAR and CDR have well-defined behavior when used on an empty list: they return NIL, which in both Lisps is equivalent to an empty list.
This paper on "Object Algebras": https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf is a great example of using ideas from functional programming and category theory to improve on the visitor pattern, such that the expresson problem can be solved. The value of such mathematics is that it enables us to formalise some of these patterns and generalise them.
> such that the expresson problem can be solved. I'll add this paper to my reading list (because this is very much something I'm interested in), but in the meantime could you explain what you mean by "solving" the expression problem? My understanding has been that EP is more of a lens through which to evaluate the usefulness of solutions along the objects-or-functions spectrum, rather than an actual problem to be sol…
"The expression problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)."
With a sufficiently expressive language, the expression problem can be solved, sometimes in multiple ways. However, the solutions often involve boilerplate, trickery or advanced type system features. A proposed solution to the expression problem may be impractical, but that is subjective and really a separate discussion.
I guess you could view the problem as a sort of lens with which to evaluate a language. E.g. Can this language solve the expression problem and what does the best solution look like?
While we're on this subject, if we were to keep extending the syntax, is this what introProduct would have to look like? data Coproduct a b where InjL :: a -> Coproduct a b InjR :: b -> Coproduct a b elimCoproduct :: (a -> c) -> (b -> c) -> Coproduct a b -> c elimCoproduct f g (InjL x) = f x elimCoproduct f g (InjR y) = g y codata Product a b where ProjL :: Product a b -> a ProjR :: Product a b -> b introProduct :: (…
Exactly! Maybe you've seen them before but what you just wrote are so-called "copatterns". See: https://www.cs.mcgill.ca/~bpientka/papers/unnesting-copatter... https://doi.org/10.1017/S0956796819000182 https://agda.readthedocs.io/en/latest/language/copatterns.ht... Agda even has extra sugar on top for postfix projectors: you could write `myPair .ProjL` (as expression and as copattern). Syntax for pattern-matching ano…
I'm still fuzzy but it seems like this can be directly translated into an underlying term rewriting system and would just work almost unmodified and all we've done is opened a second route for type checking terms based on orthogonal conditions? I'll have a look at the nested copatters paper as that probably answers my question. Thank for the resources. They seem much clearer than my search results. I wonder why people don't start explaining codata with records instead of coNats and coLists. The latter was confusing.
" (...) - In an OO language, you can add a new case by creating another subclass and implementing the methods. But, if you want to add a new function to a datatype, you have to add it to the superclass and implement it on all the existing subclasses, which means modifying a lot of files and recompiling most of the program. - In a FP language you can add a new function to an existing datatype just by adding a function…
> Why did it take us so long to recognise this? It didn't take us long. Schemers did multiple dispatch at least 40 years ago. SICP explains how to do it. (Arguably, both R and Julia are Lisp dialects under the hood, just disguised behind a more arcane syntax. Which goes to show that 'practioners' take Lisp seriously exactly as long as they don't know it's Lisp.)
I have a friend who is like this, looked at some Rust code, saw closures with bars instead of parentheses and practically disregarded it on the spot. Took a lot of convincing that they wouldn’t notice after 15 minutes of actually using the language, and what do you know, I was right.
" (...) - In an OO language, you can add a new case by creating another subclass and implementing the methods. But, if you want to add a new function to a datatype, you have to add it to the superclass and implement it on all the existing subclasses, which means modifying a lot of files and recompiling most of the program. - In a FP language you can add a new function to an existing datatype just by adding a function…
Common Lisp Object System had multiple dispatch for ages. Some other religions do not like it.
Earlier quoted context omitted.
> such that the expresson problem can be solved. I'll add this paper to my reading list (because this is very much something I'm interested in), but in the meantime could you explain what you mean by "solving" the expression problem? My understanding has been that EP is more of a lens through which to evaluate the usefulness of solutions along the objects-or-functions spectrum, rather than an actual problem to be sol…
The "expression problem" from Wikipedia (quoting Phil Wadler): "The expression problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)." With a sufficiently expressive language, the expression problem can be solved, som…
Earlier quoted context omitted.
> such that the expresson problem can be solved. I'll add this paper to my reading list (because this is very much something I'm interested in), but in the meantime could you explain what you mean by "solving" the expression problem? My understanding has been that EP is more of a lens through which to evaluate the usefulness of solutions along the objects-or-functions spectrum, rather than an actual problem to be sol…
The "expression problem" from Wikipedia (quoting Phil Wadler): "The expression problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)." With a sufficiently expressive language, the expression problem can be solved, som…