101–110 of 110 posts
Earlier quoted context omitted.
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.
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).
Earlier quoted context omitted.
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).
Perl is dynamic and does allow return value overloading via the wantarray function.
Earlier quoted context omitted.
Sticking to a philosophy like a zealot makes it a religion. Keeping it as a philosophy means it encourages a certain approach, not that it makes it an absolute unbreakable rule, plus it would only results in bikeshed/flamewar arguments. as PEP20 says: Special cases aren't special enough to break the rules. Although practicality beats purity.
I said "somewhat" for a reason, but I think there are just too many special cases to keep calling them exceptions. I use awk and sed, pipe things into bzip2, but I more often use tar with a z or j option to compress stuff an in a pipeline. We also do not have separate tools for parsing python/ruby/perl and executing it. If code reuse using pipes were successful, wouldn't we have a separate 'exec' tool that is backend…
Earlier quoted context omitted.
Perl is dynamic and does allow return value overloading via the wantarray function.
Thanks. I will have to think a bit harder, and see whether I can rescue my statement in modified form.
I learned programming in QBasic by experimenting with graphics, games and fractals. I honestly think that plotting per-pixel graphics is a much more fun and rewarding way to learn programming, than a cat program. It's only a shame Linux has no "mode 13h" screen and a PSET function in the C language :)
Earlier quoted context omitted.
Thanks. I will have to think a bit harder, and see whether I can rescue my statement in modified form.
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.
Earlier quoted context omitted.
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.
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…
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.
Earlier quoted context omitted.
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.
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…
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).
tl;dr - this does work to a point, but won't necessarily teach you idiomatic and community practices that come with experience, but it is surprisingly sticky I had the great pleasure, year ago in my undergrad Operating Systems class, for the class assignment to be "write an OS in Java"...which of course was handed out to a group of students who had never seen Java. By the end of the semester we had written the core g…
My standard "learn a new language" project usually is a calculator... touches many aspects but I have grown bored of it. A phrase extrator is simple but can be much more complex, might try it next language!