notes-computer-jasper-jasperTypeNotes2

interestingly, Curtis Guy Yarvin of Nock and Hoon and Urbit fame came to the same conclusion that i did w/r/t the difficulty of backwards inference in Haskell et al's type inference: http://www.urbit.org/2013/11/19/urbit-is-easy-ch10.html

also, the Golang folks came to a similar conclusion regarding everything-is-an-interface, although i wish to pursue that even further than they.

--

python's built-in types: http://docs.python.org/3/library/stdtypes.html

see also http://docs.python.org/3/library/types.html#standard-interpreter-types

rpython's types: http://doc.pypy.org/en/latest/rtyper.html

--

idea from Hoon: "The general principle is that name resolution across a fork works if, and only if, the names resolve to the same axis on both branches." i.e. that's somewhat similar to saying that if you have a value whose type is a (structural) union type, you can access a part of the structure iff the structure in the structure tree 'above' that part is identical in all types in the union

--

GTD/todo.txt @contexts vs. +tags; there is only one @context at a time (modal), used for filtering todo items to a sublist apropos to this context

relevant to type systems?

--

As Joel, I and a number of

As Joel, I and a number of others discussed on #haskell, part of the problem is that haskell's type system is poor at typing the kinds of things he was doing. For example, given n message types and m entities accepting o combinations of message types, there is no good solution for typing this accurately while retaining pattern-matching even with GHC's extensions - it can be done, but at the cost of much unboxing and reboxing and a type syntax that requires an indirection (or a good coding convention) to figure out which message types're actually accepted. By Philippa Cowderoy at Tue, 2006-01-24 01:44

I'd like to hear more about
login or register to post comments

I'd like to hear more about this - I don't really understand the issue with static typing, particularly since Haskell infers types. What was wrong with the general "data Event = ..." approach, with one constructor for each event type sent? It seems like an Erlang tagged tuple directly corresponds to a Haskell algebraic type (the tag atom is the constructor, and then the other elements are the arguments). Does Joel go into this any more in-depth anywhere? By Jonathan Tang at Tue, 2006-01-24 03:28

What's wrong is that it
login or register to post comments

What's wrong is that it gains you little more than dynamic typing does. You know you've got an event, but you've no clue if it's one of the ones you handle. By Philippa Cowderoy at Tue, 2006-01-24 15:03

login or register to post comments

--

...

I second your point about the robustness of the resulting Haskell code. I said in some other post that if it builds then it's probably right. My pet peeve, though, is that Haskell seduces you into coding for clarity and beauty. Haskell seduces you into coding the natural way. The natural way is concise since you can let type inference do the work, use lists, etc.

Then reality kicks in and you realize that the code is not running fast enough or consumes gobs of memory or spends 70% of its time collecting garbage. That's when you start putting strictness annotations all over the place unrolling your lets into cases and so on. It gets ugly.

Now, there are masters out there like Oleg Kiselev (Zipper OS) or Simon Marlow who probably don't have any trouble at all writing code that's both concise, beautiful and fast. I'm not one of them, not with Haskell. I find that doing things the natural way in Erlang hides no surprises and runs reasonably fast. Same thing about Scheme as I just set out to prove. By Joel Reymont at Tue, 2006-01-24 01:47

login or register to post comments

--

conjuctions and atomic negations only? or negations only in dataflow?

in more detail, we may want to restrict the logical operations that can be used to create new types out of combining existing types to make type inference tractable. Ie we could permit the creation of a type that says "X is of type A iff X is not of type B" but also permit "X is of type D iff X is of type B and X is also of type C" and also "X is of type E if X is of type B, or if X is of type C". But without further constraints elsewhere, that would make inference intractable in the general case.

so, some obvious constraints in this area are:

or, as noted above, we could leave this unconstrained and put constraints elsewhere

---

todo read:

http://www.q-lang.io/

---

don't make these mistakes with generics and their implementation:

http://nomothetis.svbtle.com/smashing-swift

three issues:

---

related to the previous:

"

noobermin 1 day ago

link

Just to point out, the last two sound like it's due to the current implementation (compiler) being new, so it isn't so upsetting at all.

Now, not supporting functors is odd, though.

reply

...

And yes, we should expect it as "normal" for new languages, because it is what people have come to expect to have available - although some implementations leave a lot to be desired.

If we consider how C# implements Functors for example, we see that it requires special language support, where the compiler essentially pattern matches over your code, looking for a method named "Select", with a specific signature taking a generic type and a func. This implementation completely misses the point that Functors themselves, while useful, are not special - they are a specialization of a more general concept we have - typeclasses and higher-kinded polymorphism. C# also adds the ability to create Monads, Foldable, Comonads etc, using similar patterns - but you can't create your own typeclasses, and are left to the language designers to add a desired feature.

The decision to add them onto C# like this was made not without knowledge of this, but out of consideration of working with the existing language, which was designed without their consideration, hence, why they're a pretty ugly design compared to the simplicity of Haskell's implementation.

[1]:http://www.cs.tufts.edu/comp/150GIT/archive/mark-jones/fpca9... [2]:http://research.microsoft.com/en-us/um/people/simonpj/papers...

reply "

---

hoon has a good idea:

orthogonal odor and size (generalize the addition of orthogonal size to type attributes)

(but in addition to the ortho 'size', having the 'odor' for atoms plus also structural typing sounds good)

--

the hoon tutorial explains typing as being motivated as a way to access nodes in by name instead of number