<micahjohnston_>
ec: also i can finaly musicproduce
<micahjohnston_>
becas producing room with keyboard and stuff is accessible with laptop
eligrey has quit [Quit: Leaving]
duckinator has quit [Quit: Nickname collision due to Services enforced nickname change, your nick was overruled]
<devyn>
23:13:09 -!- duckinator [nick@botters/staff/duckinator] has quit [Quit: Nickname collision due to Services enforced nickname change, your nick was overruled]
<devyn>
wat
duckinator has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
chris-tina has joined #elliottcable
PragCypher has joined #elliottcable
PragCypher has quit [Quit: Leaving]
chris-tina has quit [Quit: Ex-Chat]
niggler has quit [Ping timeout: 256 seconds]
niggler has joined #elliottcable
PragCypher has joined #elliottcable
alexgordon has joined #elliottcable
chris-tina has joined #elliottcable
eligrey has joined #elliottcable
niggler has quit [Quit: Computer has gone to sleep.]
<alexgordon>
the way I want to do it is to find the types of all the assignments
<alexgordon>
then fold them
<alexgordon>
to get a single unified type
<alexgordon>
so I guess that could be an error
<micahjohnston_>
yeah ok
<alexgordon>
or a [T]
<micahjohnston_>
if two assignments are incompatible
<micahjohnston_>
or just make it supertype including both, if possible
<alexgordon>
I mean you could still use say length() on them
<alexgordon>
but I'd be inclined to disallow it
<alexgordon>
dunno, difficult
<alexgordon>
want to avoid boxing anything
<alexgordon>
micahjohnston_: there's no bottom / object type, so you definitely can't have a variable that's both (say) String and Int
<alexgordon>
er, would that be *top type?
<alexgordon>
yeah that's what I meant
<alexgordon>
I think I'd be inclined to disallow unifying [Int] and [String] because then you introduce performance problems. All your Ints and Strings have to be boxed into an Any type, then unboxed when you want to get them out. Plus it's just not very useful
<alexgordon>
but
<alexgordon>
another issue is combining say [3.14, 2.71] and [1, 2, 3]
<alexgordon>
[Real] and [Int]
<alexgordon>
because [1, 2, 3] will be stored as Ints
<alexgordon>
so it has to suddenly be converted to Reals
<alexgordon>
so in say
<alexgordon>
var foo = [1, 2, 3]
<alexgordon>
if foo's type is deduced to be [Real]
<alexgordon>
you have to have a coercion
<alexgordon>
var foo = __coerce<List<Real>>([1, 2, 3])
<alexgordon>
which is a bit silly
<alexgordon>
because it would make more sense to just have [1.0, 2.0, 3.0]
<alexgordon>
micahjohnston_: so what is the type of [] ? is it some special type? is it just [T]?
* alexgordon
asks ghc
<alexgordon>
[] :: [a]
<micahjohnston_>
well it's easier in ghc
<micahjohnston_>
because of the way dataflow can happen
<micahjohnston_>
oh yeah just plain old []
<alexgordon>
in haskell it would be
<alexgordon>
blah True = []
<alexgordon>
blah False = [1, 2, 3]
<micahjohnston_>
blah :: Boolean -> [Int]
<alexgordon>
or Num t
<micahjohnston_>
yeah
<alexgordon>
so haskell's type inference sees [a] and [Int] and says "that's an [Int]"
<alexgordon>
which I find a little weird
<alexgordon>
because a [a] isn't necessarily an [Int]
<alexgordon>
guess it depends on the context of a
<micahjohnston_>
well it's like
<micahjohnston_>
blah can evaluate to all of these things
<micahjohnston_>
and so they are consistent because one is an empty list of ints and one is a full list of ints
<alexgordon>
man type inference is Hard
<micahjohnston_>
not weird
<micahjohnston_>
[] is an [a] if there's no further info
<alexgordon>
micahjohnston_: that's not what I find weird though
<alexgordon>
it's that [a] • [Int] → [Int]
<micahjohnston_>
well it's not that
<micahjohnston_>
it's
<micahjohnston_>
[] :: [a] if it's just a [] sitting there
<alexgordon>
as far as pattern matching goes, in blah
<micahjohnston_>
but if it's the result of a function that can also evaluate to [1, 2, 3]
<alexgordon>
blah True is [a]
<alexgordon>
blah False is [Int]
<micahjohnston_>
no, blah True is [1, 2, 3]
<micahjohnston_>
wait
<micahjohnston_>
[Int]
<micahjohnston_>
because Haskell considers all the cases together
<micahjohnston_>
because blah is one value
<alexgordon>
talking about the individual cases
<micahjohnston_>
blah is a function with a single type
<micahjohnston_>
it's
<micahjohnston_>
you cannot talk about them in isolation
<micahjohnston_>
blah is a function, Boolean -> [Int]
<alexgordon>
ok what I mean is
<alexgordon>
if blah False didn't exist
<alexgordon>
blah True would be [a]
<alexgordon>
like if you just had
<alexgordon>
blah True = []
<micahjohnston_>
that's a nonsensical way to put it
<micahjohnston_>
"blah False didn't exist"
<alexgordon>
it would be [a]
<micahjohnston_>
it's not like
<micahjohnston_>
that case exists
<micahjohnston_>
if you take that line away
<alexgordon>
lol
<purr>
lol
<micahjohnston_>
then you no longer have any information showing that blah results in [Ints}
<alexgordon>
but that's how it works, it generates constraints
<micahjohnston_>
you could still write blah :: Boolean -> [Int]
<micahjohnston_>
but it would also warn you
<micahjohnston_>
that not all cases of datatype are handled
<alexgordon>
yeah but without an explicit declaration it would be Boolean → [a]
<micahjohnston_>
well sure
<micahjohnston_>
but you're thinking about it like the cases of the pattern matching are separate things
<micahjohnston_>
when the compiler desugars them to a case..of statement
<alexgordon>
but there's a constraint for each case...
<micahjohnston_>
no there isn't
<micahjohnston_>
they all *have* to be the same type
<micahjohnston_>
it gets desugared to
<alexgordon>
somewhere in ghc there's a function that goes "okay so the first line is [a] and the second line is [Int], therefore the whole function is [Int]"
<micahjohnston_>
blah = \ a -> case a of { True -> asld;fjasd;lfjasdlf;
<micahjohnston_>
so it's best to think of it in that way
<micahjohnston_>
the different cases are not separate things
<micahjohnston_>
they're different possible dataflow branches
<alexgordon>
but they are different, in that they inhabit different places in the source file
<micahjohnston_>
but yeah i guess you're right that in ghc there's a part that says well this part only has enough information to see that it's a [SOMETHING] and then this part is [Int]
<micahjohnston_>
but I don't think you can even put another decl between them
<micahjohnston_>
like
<alexgordon>
and so the ghc type inference algorithm sees a function with two cases
<micahjohnston_>
blah True = asdf
<micahjohnston_>
foo ASDF = asfegg
<micahjohnston_>
blah False = asdfh
<micahjohnston_>
pretty sure that's an error
<micahjohnston_>
no, the type inference algorithm sees a case statement
<alexgordon>
ok but this is a silly thing to argue
<micahjohnston_>
fairly sure
<micahjohnston_>
it would see it as
<micahjohnston_>
a dataflow branch
<alexgordon>
micahjohnston_: it sees a case statement with two branches...