LordBrain 2017-02-24 00:45:20
we have a hundred different kinds of strings...
merijn 2017-02-24 00:45:25
Magic hash only really appears in GHC internally
Tuplanolla 2017-02-24 00:45:27
Here's a good heuristic for beauty: if two language designers independently arrive at the same syntax, there has to be something intrinsically appealing about it.
LordBrain 2017-02-24 00:45:34
fair enough merijn
Tuplanolla 2017-02-24 00:45:53
It's similar to how good mathematics is "discovered", not "invented".
merijn 2017-02-24 00:45:57
As for different kinds of Strings, the alternative would be to have one and make things suck if it doesn't do what you want
phadej 2017-02-24 00:46:03
indeed
merijn 2017-02-24 00:46:14
I think ezyang's Backpack work will make things a lot better in terms of "strings"
LordBrain 2017-02-24 00:46:24
but for example, say we decided to take things really more toward the higher level, we might remove implementation details to the point where the programmer doesnt even know if its a linked list or a bytestring or what
merijn 2017-02-24 00:46:37
LordBrain: I also don't see the problem with a long list of imports? What's the alternative?
phadej 2017-02-24 00:46:44
LordBrain: but list of characters is different from the array of bytes!
LordBrain 2017-02-24 00:46:51
of course it is
phadej 2017-02-24 00:46:54
even semantically
LordBrain 2017-02-24 00:47:02
well...
halogenandtoast 2017-02-24 00:47:04
Bish: What language do you consider pretty?
phadej 2017-02-24 00:47:29
LordBrain: you cannot ask "textLength" from bytestring, without giving the encoding informaation too, for example
LordBrain 2017-02-24 00:47:37
but we don't need "string" to be hard coded to either.... the default could just be to use something that adapts, maybe even having some online tickies to figure out the best adaptation at run time
LordBrain 2017-02-24 00:48:02
i mean if that was our priority
LordBrain 2017-02-24 00:48:25
we could make things a lot prettier
merijn 2017-02-24 00:48:26
LordBrain: See my remark about Backpack
LordBrain 2017-02-24 00:49:17
well, i don't think haskell is ugly
LordBrain 2017-02-24 00:49:50
but i try to be fair to the negative feedback.. and understand why people might feel differentlyl than i do, when my impressoin was formed about an earlier haskell
LordBrain 2017-02-24 00:50:28
realisitically, it does feel like that priority has been put off in comparison to others
mlehmk 2017-02-24 00:50:48
list and bytestring are fundamentally different, it's on the level of developing, not just the level of how it is stored
LordBrain 2017-02-24 00:51:09
mlehmk, so, programming can be ambiguous until specified
LordBrain 2017-02-24 00:51:17
you can say, just use something here i don't care
LordBrain 2017-02-24 00:51:31
and then later, hard bake it as necessary
kuribas 2017-02-24 00:51:36
scheme is pretty
kuribas 2017-02-24 00:51:49
but I prefer static types...
mlehmk 2017-02-24 00:51:52
this is not what one wants, that's why one uses a list sometimes and bytestring at other times. It just depends
LordBrain 2017-02-24 00:51:56
yeah me too kungp
LordBrain 2017-02-24 00:51:59
kuribas,
LordBrain 2017-02-24 00:52:02
sorry tab complete
LordBrain 2017-02-24 00:52:21
huh?
LordBrain 2017-02-24 00:52:46
look, i'm just saying lets be aware of our priorities and such, we don't have to be in denial about it, we tend to put "pretty" lower than a lot of other concerns
mlehmk 2017-02-24 00:53:17
writing functions that create new strings from other strings, just use lists, as that's the thing that works nicely with the functional style
LordBrain 2017-02-24 00:53:25
and that has increased with time as we have increased our priorities on performance and practicality and yadda yadda
phadej 2017-02-24 00:53:30
Well, the "not breaking existing stuff" conflicts with "pretty" unfortunately a lot
mlehmk 2017-02-24 00:53:53
if you communicate with other apps/servers etc. use the bytestring, as they have an encoding and a byte representation useful to exchange plain byte buffers
LordBrain 2017-02-24 00:54:15
sigh
LordBrain 2017-02-24 00:54:24
i know this stuff mlehmk
mlehmk 2017-02-24 00:54:39
and that is the whole point in that thing
LordBrain 2017-02-24 00:54:55
i think my entire point went right over your head
mlehmk 2017-02-24 00:55:02
I have yet to find a language that makes no distinction between strings and a byte buffer
mlehmk 2017-02-24 00:55:10
well, C was one
LordBrain 2017-02-24 00:55:10
so????
LordBrain 2017-02-24 00:55:20
we would make distinction
mlehmk 2017-02-24 00:55:29
and we have
LordBrain 2017-02-24 00:55:30
its just htat string would be a complicated adapting-container
LordBrain 2017-02-24 00:55:42
and we'd have non-adapting when we want that too
LordBrain 2017-02-24 00:55:48
but for a lot of pruposes, we'd just go with the default
mlehmk 2017-02-24 00:56:02
and you just end up having two different types again
LordBrain 2017-02-24 00:56:15
yes, but in practice a lot of code gets cleaner
phadej 2017-02-24 00:56:24
I think this is wrong mentality. ByteString and say Text are entirely different concepts
LordBrain 2017-02-24 00:56:29
whatever
LordBrain 2017-02-24 00:56:44
i am not saying we throw away the fixed implementation types
mlehmk 2017-02-24 00:57:06
I think the code is cleaner if there's actually a distinction between strings and a byte representation in source
phadej 2017-02-24 00:57:10
even with backpack it would make sense to have abstraction "things with characters" and "things with bytes"
mlehmk 2017-02-24 00:57:19
as they are different things and handled differently
LordBrain 2017-02-24 00:57:20
yes
mlehmk 2017-02-24 00:57:55
although, one thing that might be possible is hide the implementation details of a list and store it as some utf-8 string internally
mlehmk 2017-02-24 00:58:29
though you still need the bytestring if you want to send/receive buffers
phadej 2017-02-24 00:58:31
but then there's textbuilder, bs-builder and DList String
LordBrain 2017-02-24 00:58:32
right, adapting-lists actually is superior to adapting-strings
phadej 2017-02-24 00:59:11
and those are different too
LordBrain 2017-02-24 00:59:16
god
LordBrain 2017-02-24 00:59:26
what about me says i am ignorant of the distinctions?
phadej 2017-02-24 01:00:11
but at some point (when it's a "real" program), you cannot be ignorant of the low-level details
phadej 2017-02-24 01:00:30
IMHO it's a beauty of haskell, thata you can write high level abstractions for quite low-level stuff
LordBrain 2017-02-24 01:00:34
well we always sacrafice prettiness at some point, but that doesnt mean give up entirely
LordBrain 2017-02-24 01:00:48
well yes
LordBrain 2017-02-24 01:00:54
we don't expect every program to be beautiful
phadej 2017-02-24 01:01:22
and FWIW, imho the string story is much more "beautiful" than numbers
LordBrain 2017-02-24 01:01:44
how would you make numbers prettier?
phadej 2017-02-24 01:01:45
at least we don't have "not so good" abstractions in base/prelude
phadej 2017-02-24 01:02:00
(for strings)
liste 2017-02-24 01:02:16
phadej: what's wrong with the numbers story?
liste 2017-02-24 01:02:23
numbers tower?
phadej 2017-02-24 01:02:28
liste: yes
liste 2017-02-24 01:02:49
or should it be "numbers tree" in this case :D
phadej 2017-02-24 01:02:56
DAG
phadej 2017-02-24 01:03:01
:)
LordBrain 2017-02-24 01:03:45
another thing that has uglied up a bit is our type sigs, as neil pointed out they would... when we generalized a lot of stuff in the prelude... so we have things like monoid m => m a, instead of just [a]
LordBrain 2017-02-24 01:04:14
minor, but still
phadej 2017-02-24 01:04:16
foldable?
LordBrain 2017-02-24 01:04:21
same yes
phadej 2017-02-24 01:04:32
your type signature is kind-incorrect
LordBrain 2017-02-24 01:04:33
well, foldable, my point was we have a type class
LordBrain 2017-02-24 01:04:42
i'm not writing code
LordBrain 2017-02-24 01:04:44
i'm talking, on irc
phadej 2017-02-24 01:05:02
... and half of people think foldable/traversable stuff is good thing
LordBrain 2017-02-24 01:05:09
oh i think its good too
LordBrain 2017-02-24 01:05:19
my point isn't "bad" about anything
phadej 2017-02-24 01:05:42
I don't follow
LordBrain 2017-02-24 01:06:14
phadej, to say we don't prioritize pretty as highly as other things is not the same thing as to say that we should do so
lyxia 2017-02-24 01:06:34
How do you define "pretty"
phadej 2017-02-24 01:06:47
well, uglier type-signatures <-> prettier in use-sites?
LordBrain 2017-02-24 01:07:07
well, thats a good question lyxia, you can't really get a hard metric on that, but one thing is fewer tokens
LordBrain 2017-02-24 01:07:14
as a general rule
LordBrain 2017-02-24 01:07:25
sometimes symbols are improvements over textual words
LordBrain 2017-02-24 01:07:31
other times its the other way around
phadej 2017-02-24 01:07:50
well, then my trade-off applies to it
LordBrain 2017-02-24 01:08:20
it didn't change the use site, maybe the import list
phadej 2017-02-24 01:08:23
more general type-signatures: more lexemes, but when you use them, you have less "adoption boilerplate"
phadej 2017-02-24 01:08:40
but if you use e.g. `Vector` ?
phadej 2017-02-24 01:09:32
if the [a] is the only container you ever use, then indeed the generalisation is net loss for you
LordBrain 2017-02-24 01:09:39
well, i am pointing out something i think is a discerning observation about the relative ranking of values and the evolution of ghc, you can disagree if you want, but i don't want to debate this utterly subjective judgment call.
phadej 2017-02-24 01:09:58
I agree on that, it's highly subjective
LordBrain 2017-02-24 01:11:34
it had to be this way too, imo, if they prioritized pretty over other stuff, nothing would ever get done
LordBrain 2017-02-24 01:12:21
people would bikeshed syntax forever
LordBrain 2017-02-24 01:12:53
but being aware of it is valuable i think, because it means you can consider how to clean it up
LordBrain 2017-02-24 01:13:11
without sacrificing other priorities
kuribas 2017-02-24 01:17:07
Why isn't any work being done on automatic simd vectorization for operations on numeric vectors?
merijn 2017-02-24 01:26:15
kuribas: There is some work on that
kuribas 2017-02-24 01:26:31
there is?
merijn 2017-02-24 01:26:41
kuribas: Recent GHCs have simd primitives and carter (and people in #numerical-haskell) are working on simd support too
kuribas 2017-02-24 01:26:50
ah, great
merijn 2017-02-24 01:27:00
kuribas: But that needs to crystalise before that can really be used by vector
kuribas 2017-02-24 01:27:13
merijn: simd only works for llvm, and only for a particular version.
kuribas 2017-02-24 01:27:29
merijn: so using simd in my project becomes somewhat of a hassle for users.
kuribas 2017-02-24 01:27:53
merijn: unless I write in C using the FFI
merijn 2017-02-24 01:27:53
kuribas: It becomes a hassle anyway, because using SIMD means compiling for a specific CPU architecture
merijn 2017-02-24 01:28:16
kuribas: Like, do your users support SSE? Which version? AVX? AVX2? etc.
kuribas 2017-02-24 01:28:34
merijn: true, but I think most modern desktops use x86 with SSE2 support.
merijn 2017-02-24 01:29:59
I think some people are making the LLVM backend less of a pain (i.e. generating bitcode resulting in GHC becoming portable to newer LLVM versions)
merijn 2017-02-24 01:30:07
Since it's currently tied to a specific one
kuribas 2017-02-24 01:30:28
right
kuribas 2017-02-24 01:31:12
merijn: a fractional instance for simd vectors would be very useful.
kuribas 2017-02-24 01:31:52
I guess currently the FFI is my best bet.
merijn 2017-02-24 01:32:30
kuribas: Yeah, I think so. Although this is also an area where minor knowledgeable contributions can be very helpful, since this doesn't/shouldn't require advanced knowledge of GHCs type system and things :)
kuribas 2017-02-24 01:33:18
merijn: you think adding more SIMD instructions to base would be appreciated?
piyush-kurur 2017-02-24 01:35:26
kuribas: as the developer of raaz I would appreciate having native SIMD in Haskell
merijn 2017-02-24 01:35:53
kuribas: I think things like SIMD primitives are very much something people would like to have, but something that, say, the Simon's aren't very focussed on doing
kuribas 2017-02-24 01:36:09
yeah, they have enough stuff to do...
merijn 2017-02-24 01:36:25
kuribas: So they remain "undone" until someone contributes them. See also the ability supply custom Cmm primitives which you might be able to leverage
merijn 2017-02-24 01:36:56
piyush-kurur: As I mentioned there is some SIMD in GHC already (maybe only when using llvm)
merijn 2017-02-24 01:37:09
piyush-kurur: Have a look at GHC.Prim: https://hackage.haskell.org/package/ghc-prim-0.4.0.0/candidate/docs/GHC-Prim.html
carter 2017-02-24 01:37:39
It's also work to fix the current simd design. I have ideas. But holly crap it's work I can sneak into day job
carter 2017-02-24 01:37:52
*can not
carter 2017-02-24 01:38:02
Also missing all the good stuff
carter 2017-02-24 01:38:07
And wrongly abstracted
kuribas 2017-02-24 01:38:13
There should be fund for this kind of stuff.
carter 2017-02-24 01:38:38
kuribas: that's not the bottle neck.
kuribas 2017-02-24 01:38:48
carter: what is?
carter 2017-02-24 01:39:31
More like the folks who know /want the better design directions are super busy ATM. And there's some huge sub tasks
carter 2017-02-24 01:39:44
In the mean time use c
carter 2017-02-24 01:39:53
For simd inner loops
piyush-kurur 2017-02-24 01:40:10
merijn: that is quite a bit in fact looking at it I would like to code chacha20 in haskell ;-)
merijn 2017-02-24 01:40:43
kuribas: Like I said, if you can contribute even some small amount of work, I think it'd be very welcome :)
kuribas 2017-02-24 01:40:51
merijn: right :)
carter 2017-02-24 01:41:35
Like help cleanup native code gen first
kuribas 2017-02-24 01:41:53
what's bad about it?
piyush-kurur 2017-02-24 01:42:07
merijn: do you know how to use llvm backend with stack
piyush-kurur 2017-02-24 01:42:14
I mean I want to try it out
carter 2017-02-24 01:42:16
Currently peephole optimizations are adhoc added to the asm pretty printer.
carter 2017-02-24 01:42:25
I mean idk take a look and dig in
merijn 2017-02-24 01:42:35
piyush-kurur: I don't know how to use stack, so no? ;)
piyush-kurur 2017-02-24 01:44:24
merijn: is it the case that the SIMD is supported only with llvm
piyush-kurur 2017-02-24 01:44:25
>
piyush-kurur 2017-02-24 01:44:26
?
kuribas 2017-02-24 01:44:42
carter: I am reading about optimizing assembly language, it's pretty complicated.
merijn 2017-02-24 01:44:58
piyush-kurur: I don't know, tbh. Ask carter, he's the expert ;)
kuribas 2017-02-24 01:45:03
piyush-kurur: yes
