4 ms·

Common Lisp can return multiple values from functions. Thus it returns two values from a hash-table lookup: CL-USER 45 > (gethash 'foo (make-hash-table))

by lispm 12y ago

Common Lisp can return multiple values from functions. Thus it returns two values from a hash-table lookup: CL-USER 45 > (gethash 'foo (make-hash-table)) NIL NIL The first value is the stored value in the hash table. If there is no key, the first value is NIL. The second value indicates whether the key is present in the hash table.

rntz 12y ago
I list Common Lisp & its behavior in Appendix C at the end of the article. Multiple-return-value is definitely better than just returning NIL, but I still dislike it; it doesn't actively prevent you from confusing NIL with absence, so "the obvious way to do it" can still be the wrong way. A good CL programmer won't fall into this trap, but the article is in large part about how some languages/interfaces default you into good programming by requiring you to distinguish success from failure, and others don't. Another way of seeing the same thing is: Type-theoretically speaking, MRV is using a product type (two values) to emulate a sum type (one value of two possible forms); why not just use a sum type?
- tel 12y ago
  The optimistic type theoretician says that since dependent products are sums then it's perfectly fine to use a product to emulate a sum... except since the dependence in the projections isn't reflected in the type system it's totally up to the programmer to ensure that the providence is maintained.
derefr 12y ago
And in Erlang: 1> X = #{"a" => 1}. #{"a" => 1} 2> maps:find("a", X). {ok,1} 3> maps:find("x", X). error Constructing and destructuring tuples is cheap in the Erlang VM, so Erlang uses them where other languages would use types. Further, in idiomatic Erlang, you don’t bother with a branch for each case of the option type; you just do the following: {ok, Val} = maps:find("a", X). Effectively, that's a type assertion: if maps:find/1 responds with error instead of {ok, _}, that’s a process crash.

by lispm 12y ago

rntz 12y ago

I list Common Lisp & its behavior in Appendix C at the end of the article. Multiple-return-value is definitely better than just returning NIL, but I still dislike it; it doesn't actively prevent you from confusing NIL with absence, so "the obvious way to do it" can still be the wrong way. A good CL programmer won't fall into this trap, but the article is in large part about how some languages/interfaces default you into good programming by requiring you to distinguish success from failure, and others don't. Another way of seeing the same thing is: Type-theoretically speaking, MRV is using a product type (two values) to emulate a sum type (one value of two possible forms); why not just use a sum type?

tel 12y ago
The optimistic type theoretician says that since dependent products are sums then it's perfectly fine to use a product to emulate a sum... except since the dependence in the projections isn't reflected in the type system it's totally up to the programmer to ensure that the providence is maintained.

derefr 12y ago

And in Erlang: 1> X = #{"a" => 1}. #{"a" => 1} 2> maps:find("a", X). {ok,1} 3> maps:find("x", X). error Constructing and destructuring tuples is cheap in the Erlang VM, so Erlang uses them where other languages would use types. Further, in idiomatic Erlang, you don’t bother with a branch for each case of the option type; you just do the following: {ok, Val} = maps:find("a", X). Effectively, that's a type assertion: if maps:find/1 responds with error instead of {ok, _}, that’s a process crash.