5 ms·

I write a unit testing framework in every new language I learn. I find it's a great workout because making it usable for yourself is immediately assessable, an

I write a unit testing framework in every new language I learn. I find it's a great workout because making it usable for yourself is immediately assessable, and it often forces you into deeper areas of the language, including reflection and meta-programming.

rodrigoavie 14y ago
That's nice.
turingbook 14y ago
Hope to see the frameworks on the Web.
eru 14y ago
You might want to have a look at QuickCheck. Trying to port it's techniques to other languages will also give you some insight (and will result in valuable tools).
- omaranto 14y ago
  And make you miss the ability to overload functions just on return type. Same thing happens if you use Haskell's regex library or try t port monads to another language.
  - eru 14y ago
    Indeed. Overloading on return type is one of the few things that you can't do in dynamic languages by design (and in most statically typed ones, neither, but that's an accident).
    - omaranto 14y ago
      Perl is dynamic and does allow return value overloading via the wantarray function.
      - eru 14y ago
        Thanks. I will have to think a bit harder, and see whether I can rescue my statement in modified form.
        klibertp 14y ago
        Please do! It's very interesting; I'm not good enough in PLT to try and find out the answer for myself (in such a short amount of free time I have lately) but I'm very curious if it's true that you cannot have overloading on return type in unityped languages by principle.
        omaranto 14y ago
        This is not hard to understand: under usual semantics for function calls it is clearly impossible to do return type overloading in a dynamically typed language. But, as I pointed out above, it is perfectly practical to cheat and provide an indication of the desired return type as an extra hidden argument to every function call (this is what Perl does with wantarray: it is a "builtin function" but the effect is really that of an extra boolean parameter to every function call that specifies whether the result should be an array or not).
        eru 14y ago
        And you can generalize from wantarray's Boolean to a more general parameter indicating required return type. It gets harder and harder though, to provide information about more and more distant parts of the program in a dynamically typed (or untyped) environment. From what I've heard, Racket's contract system is another interesting attempt to provide something that's typically done in a static setting---the benefits of dependent typing---in a dynamic one.
        klibertp 14y ago
        Ok, this much I understand, but I wouldn't call this overloading on return type... It's - clearly - overloading on input type, either implicit (wantarray - I checked the docs, it seems to be a variable set automaticaly depending on context by the interpreter) or explicit, but input type nevertheless. So, the short answer is - as I thought previously - that no, you can't have implicit dispatch on return type in dynamically typed language. Contracts are probably getting close, but you still need a version of apply that will get expected return type and a bunch of functions to introspect (or a macro that would do the same, but let's not wander there, as lispy macro systems are equivalent with static type systems anyway).

rodrigoavie 14y ago

That's nice.

turingbook 14y ago

Hope to see the frameworks on the Web.

eru 14y ago

You might want to have a look at QuickCheck. Trying to port it's techniques to other languages will also give you some insight (and will result in valuable tools).

omaranto 14y ago
And make you miss the ability to overload functions just on return type. Same thing happens if you use Haskell's regex library or try t port monads to another language.
- eru 14y ago
  Indeed. Overloading on return type is one of the few things that you can't do in dynamic languages by design (and in most statically typed ones, neither, but that's an accident).
  - omaranto 14y ago
    Perl is dynamic and does allow return value overloading via the wantarray function.
    - eru 14y ago
      Thanks. I will have to think a bit harder, and see whether I can rescue my statement in modified form.
      - klibertp 14y ago
        Please do! It's very interesting; I'm not good enough in PLT to try and find out the answer for myself (in such a short amount of free time I have lately) but I'm very curious if it's true that you cannot have overloading on return type in unityped languages by principle.
        omaranto 14y ago
        This is not hard to understand: under usual semantics for function calls it is clearly impossible to do return type overloading in a dynamically typed language. But, as I pointed out above, it is perfectly practical to cheat and provide an indication of the desired return type as an extra hidden argument to every function call (this is what Perl does with wantarray: it is a "builtin function" but the effect is really that of an extra boolean parameter to every function call that specifies whether the result should be an array or not).
        eru 14y ago
        And you can generalize from wantarray's Boolean to a more general parameter indicating required return type. It gets harder and harder though, to provide information about more and more distant parts of the program in a dynamically typed (or untyped) environment. From what I've heard, Racket's contract system is another interesting attempt to provide something that's typically done in a static setting---the benefits of dependent typing---in a dynamic one.
        klibertp 14y ago
        Ok, this much I understand, but I wouldn't call this overloading on return type... It's - clearly - overloading on input type, either implicit (wantarray - I checked the docs, it seems to be a variable set automaticaly depending on context by the interpreter) or explicit, but input type nevertheless. So, the short answer is - as I thought previously - that no, you can't have implicit dispatch on return type in dynamically typed language. Contracts are probably getting close, but you still need a version of apply that will get expected return type and a bunch of functions to introspect (or a macro that would do the same, but let's not wander there, as lispy macro systems are equivalent with static type systems anyway).