201–210 of 256 posts
Earlier quoted context omitted.
JS, too, right? Forget "large" standard library, there really isn't any standard library at all
You don't need a standard library to win if you don't have any competitors (in the browser). :) Fitness for purpose is relative to the other options.
Earlier quoted context omitted.
Just sticking with the pure types there's currently no generic stream model that works well. No stream fusion system fuses all cases (even in theory) and they also fail to fuse the cases they're supposed to handle too often in practice. I haven't looked at pipes, but I'm guessing it doesn't all fuse away either.
You're right, I believe Haskell's fusion framework could be greatly improved (although it is the best production solution I'm aware of). However, how would you go about solving this? I don't think there's any generalized solution to the problem of creating no-overhead iteration from higher-level iterative combinators.
Given that we're in a rust thread... are you familiar with rust's iterator fusion [0]? Basically there are three components: iterators (something like a source), iterator adapters (where all manipulations happen), and consumers (something like a sink). LLVM will compile all the iterator adapters into a single manipulation such that the underlying stream/vector/whatever only goes through it once.
I personally like it much better than Haskell's. With rust the fusion is guaranteed to happen, although it makes the types a little verbose and tricky to work with, but with, e.g., Haskell's Text's stream fusion I was never really sure that it was working, or if I could do something to prevent it. It seems like in Haskell it's more of a behind the scenes optimization that you hope kicks in, rather than designed into the types. Or do I misunderstand? I only dabbled in Haskell.
Earlier quoted context omitted.
Being able to compile stuff on CP/M wasn't much help if you wanted to develop MS-DOS applications. I first used C in 1983 on MS-DOS, I didn't use UNIX until a couple of years later. I bought Turbo Pascal 1.0 when it was released but already had a C compiler at that point.
My first contact with MS-DOS was with version 3.x on a PC 1512, until then I was on Z80 systems. So I got to see the language world in a different way, given the local choice of languages as I mentioned. EDIT: Reformulated the answer
Earlier quoted context omitted.
My first contact with MS-DOS was with version 3.x on a PC 1512, until then I was on Z80 systems. So I got to see the language world in a different way, given the local choice of languages as I mentioned. EDIT: Reformulated the answer
You seem to be suggesting that geography made a difference to which languages were available.
We only got to buy the compilers that were available on the computer local store, not always 100% original or find some magazine and order international via post.
BBS access was only available to a few fortunate capable of paying the high connection rates and the modem in first place.
We got to do with what was available to us and could afford to pay.
Some of my first Assemblers were taken from the Input magazines and typed in, because there was nothing else.
Earlier quoted context omitted.
You seem to be suggesting that geography made a difference to which languages were available.
Of course it made a difference. We only got to buy the compilers that were available on the computer local store, not always 100% original or find some magazine and order international via post. BBS access was only available to a few fortunate capable of paying the high connection rates and the modem in first place. We got to do with what was available to us and could afford to pay. Some of my first Assemblers were t…
It wasn't any harder to buy stuff in Western Europe in the early 80s than it was in the US.
Earlier quoted context omitted.
Everybody I have ever seen do CLI applications in Go will recommend heavily against it.
The package you mentioned has about 200 imports. Compare that with the standard package. https://godoc.org/?q=Flag
Earlier quoted context omitted.
Lua's lack of a stdlib is also a curse. I can't imagine how many incompatible versions of string.trim and OOP libraries are out there in the wild right now... Things have been getting better lately because of Luarocks but its still an uphill battle.
String trim is just: foo:gsub("%s*$", "") or foo:gsub("^%s*", "") The standard idiom for OOP in Lua is a one-liner: return setmetatable(self, mt) where mt.__index has all the methods. How you assign to mt.__index can vary across modules according to style, but that's a _purely_ asethetic issue. The mechanics are identical. Using a module to accomplish it creates a useless dependency. There are many criticisms one cou…
See, its not that simple :) http://lua-users.org/wiki/StringTrim
Anyway, I wasn't trying to say bad things about Lua with my examples. Its just that if you go to any large Lua project out there there is a very good chance you will find some "utils" module in there with yet another reimplementation of a lot of these common functions. Ideally we should have people reusing more stuff from Luarocks than they are right now.
Earlier quoted context omitted.
Just sticking with the pure types there's currently no generic stream model that works well. No stream fusion system fuses all cases (even in theory) and they also fail to fuse the cases they're supposed to handle too often in practice. I haven't looked at pipes, but I'm guessing it doesn't all fuse away either.
You're right, I believe Haskell's fusion framework could be greatly improved (although it is the best production solution I'm aware of). However, how would you go about solving this? I don't think there's any generalized solution to the problem of creating no-overhead iteration from higher-level iterative combinators.
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
And they work! It's not stream fusion, but the composed functions being applied to whatever container or stream of values are applied per-value, so (map (comp xf1 xf2)) applied to [1 2 3] applies (xf2 (xf1 1)), (xf2 (xf1 2)), and so on, with similar allocation savings to stream fusion.
Earlier quoted context omitted.
> You wanna play the dependent type theory card? Type families as provided in Haskell are incompatible with univalence. Hi. As someone that knows type theory and knows homotopy type theory and also knows Haskell well I would pose the following question to you: what purpose on god's green earth would be served by introducing univalence directly to haskell? (Oh, and furthermore, you realize that fundeps have precisely…
> what purpose on god's green earth would be served by introducing univalence directly to haskell? Generally, when I want to reason about tricky data structures, what I do is: (0) Define a set-isomorphic auxiliary type that's easier to analyze, and whose operations are easier to implement, but have worse asymptotic performance. (1) Prove that transporting the operations on the auxiliary type along the isomorphism yie…
No, you don't. Univalence is the axiom that transporting operations across such equivalences _always_ works. If you're doing equational reasoning directly it doesn't arise.
Furthermore, all you need to do is to establish that the _type operations_ regarding one type respect the equivalence to the other type as an additional step.
As you say "a monoid is a type plus two operations" -- so fine, we can treat the monoid And as the type bool and the dictionary of operations on it, and all this still works out.
Earlier quoted context omitted.
> Parametricity is too good to give up. With the minor exception of reference cells (`IORef`, `STRef`, etc.), if two types are isomorphic, applying the same type constructor to them should yield isomorphic types. You know that's not what parametricity means, right? Like, at all? Here's a challenge. `foo :: forall a. a -> a` Now, by parametricity that should have only one inhabitant (upto iso). Use your claimed break…
> Now, by parametricity that should have only one inhabitant (upto iso). I can count at least three: `undefined`, `const undefined` and `id`. > Use your claimed break in parametricity from type families and provide me two distinct inhabitants. Does this count? Here Oleg constructs an inhabitant of False using just some means to case-analyze types (GADTs or type families): http://okmij.org/ftp/Haskell/impredicativity-…
that said, constructing an inhabitant of false a _different_ way (when we can already write "someFalse = someFalse") is not particularly interesting, and again doesn't speak to parametricity in any direct way.