Lisp challenge

Lisp macros can do anything, they say. But can they do typeclasses?
For the purpose of feasibility study, I'll simplify the challenge, of course. It will go like this:

Implement the form mappend such that

(mappend 2 3)

expands to

(+ 2 3)

and

(mappend "arst" "neio")

expands to

(concatenate 'string "arst" "neio")

(the above code is in Common Lisp, but you're free to use any Lisp and substitute the corresponding forms from that Lisp).

The expansion must happen no later than compile-time, with no runtime overhead.

Feel free to use Typed Racket, Shen, Arc, Clojure or any other Lisp.

Easily!
(defmacro mappend (a b)
(cond
((and (eql (infer-type a) 'integer) (eql (infer-type b) 'integer)) `(+ ,a ,b))
((and (eql (infer-type a) 'string) (eql (infer-type b) 'string)) `(concatenate 'string ,a ,b))
(t (error "syntax error"))))

The expansion must happen no later than compile-time, with no runtime overhead.

Haskell can't even do that. It's all about runtime overhead.

>>3
Haskell typeclass methods are usually dispatched at compile-time. Basically each instance is a dictionary of functions and once the compiler infers the type, it knows which dictionary to substitute the method from.

>>4
Most of Haskell is usually dispatched at compile time. But virtually none of it is guaranteed, and many things must happen at runtime. That's not a terrible thing, but the constraints of this challenge have nothing to do with implementing typeclasses, especially not with regards to Haskell.

Incidentally, I can do it in Io, which is a language that does nearly everything it can at runtime, yet it meets the criteria:

Io> Sequence setSlot("+", method(x, self .. x))
==> method(…)
Io> 1 + 1
==> 2
Io> "foo" + "bar"
==> foobar

There is no expansion, and no cost at all additional to that of calling + on Numbers originally. To get an additional expansion you'd have to call doString on something, or manually construct the call yourself. You can do the same thing in the same way in JS, Smalltalk, Self, CLOS and probably even Obj-C. It's not even dynamic dispatch, strictly speaking, it's just extremely late binding. (See: Alan Kay, Smalltalk + anything descendent from it.)

This isn't a typeclass in any meaningful way but, again, it meets the criteria (with the exception of being a mere descendent and not "a Lisp" proper.)

>>1
How are you meant to do it with no runtime overhead when it's a dynamically typed language? That makes no sense. I mean, sure, in dialects like Clojure you can use type hints which (I'm assuming) would cause it to be expanded at compile time, but that's dependent on the context in which the macro is being used.

>>6
Not all Lisps are "dynamically typed", thank goodness.

(define-syntax mappend
(λ (stx)
(syntax-case stx ()
((_ 2 3) #'(+ 2 3))
((_ a b) (let ((x (syntax->datum #'a))
(y (syntax->datum #'b)))
(and (string? x)
(string? y)
(string=? x "arst")
(string=? y "neio")))
#'(string-concatenate a b)))))

Your ill-defined challenges are the best argument against formal verification I have seen so far, Haskell-kun.

Wouldn't a “proper” ^{(read: handles more than literals)} implementation of this require type inference? After all, evaluating the arguments during compile-time defeats the intended purpose of makeshift type classes.

>>7
The ones that are actually get used for things are.

Jesus Christ.
Lisp has to be the ugliest language I've seen since Brainfuck.

>>10
I know you're trolling. It's very pretty in fact. Elegant looking and logical.

>>11
Yeah, you deluded yourself so far that you think >>8's code looks pretty or elegant.

>>12
Yeah, you're an autist with other mental issues as well and too stupid to go out and fulfil your dreams of quality computing and so you go on here and rant about how all languages suck and lisp is the worst because its the language that all the cool kids on here like.

>>13
I didn't say it was the worst. Just that it's pretty ugly.

>>14
your moms ugly faggot

>>2
The function COMMON-LISP-USER::INFER-TYPE is undefined.
[Condition of type UNDEFINED-FUNCTION]

>>8

evaluating the arguments during compile-time defeats the intended purpose of makeshift type classes.

In practice you'll have to explicitly supply type signature. I.e. invoke (mappend a b) as (mappend (the string a) (the string b))

That is why statically typed languages are always harder to learn and more involved than dynamically typed ones. Otherwise Java wouldn't have lost to JavaScript.

>>1
Let's one up your challenge and have it perform the calculation at compile-time. After all, in Lisp, if we know the types of expressions at compile-time, they're literal expressions.

(defmacro mappend (a b)
(cond
((stringp a)
(cond ((stringp b)
(concatenate 'string a b))
(t (error "Types do not match!"))))
((integerp a)
(cond ((integerp b)
(+ a b))
(t (error "Types do not match!"))))
(t (error "Unsupported type(s)."))))

CL-USER> (macroexpand '(mappend 2 2))
4
T
CL-USER> (macroexpand '(mappend "a" "B"))
"aB"
T
CL-USER>

An optimizing compiler could infer the type of the arguments to mappend at compile time and perform the dispatch at compile time.

(defmethod mappend ((x number) (y number))
(+ x y))

(defmethod mappend ((x string) (y string))
(concatenate 'string x y))

(print (mappend 2 3))
(print (mappend "2" "3"))

>>2
Bullshit, CL doesn't have "infer-type".

>>17
No you won't, provided your language has type-inference (which Java-shit doesn't, as well as Scala-shit and in fact any OOP-shit).

>>20
You could write one, though, sort of. You'd need to pass in a hook to the variable's location in the source code, rather than the symbol itself though. This would be a good library.

_{(stopping the dubsfaggot from dubsbumping)}