lpaste_ 2017-03-04 06:45:58
geekosaur pasted "No title" at http://lpaste.net/353214
oPn7 2017-03-04 06:48:01
geekosaur: yeah i did that and • Couldn't match type 'SX.ExitCode' with '()'
geekosaur 2017-03-04 06:48:29
:t system
lambdabot 2017-03-04 06:48:31
error: Variable not in scope: system
geekosaur 2017-03-04 06:48:40
:t System.Process.system
lambdabot 2017-03-04 06:48:43
String -> IO GHC.IO.Exception.ExitCode
geekosaur 2017-03-04 06:48:55
mrr. right, same problem with a simpler type
geekosaur 2017-03-04 06:49:18
so add ">> return ()" to the end of that if you don't care whether it succeeds or not, otherwise handle the ExitCode
geekosaur 2017-03-04 06:50:21
if you're not doing anything else after that, I would actually suggest: SP.system "..." >>= exitWith
geekosaur 2017-03-04 06:50:35
so the Haskell program relays the result of the build to whatever invoked it
geekosaur 2017-03-04 06:51:09
er, probaby need to qualify that
geekosaur 2017-03-04 06:51:18
SP.system ... >>= SX.exitWith
oPn7 2017-03-04 06:52:39
the "..." part the thing i need to know actually :D if it works will message "Built is successfull etc.."
MarcelineVQ 2017-03-04 06:58:31
but little did the townsfolk know that the superhero known only as ertesx was actually ertes all along
geekosaur 2017-03-04 06:59:25
oPn7, the ... part is the nix-whatever you had there
geekosaur 2017-03-04 06:59:42
do I also have to copy-paste what you have already written as well?
ertes 2017-03-04 06:59:42
great… thanks a lot for blowing my cover…
geekosaur 2017-03-04 07:00:07
I feel like we are not speaking the same language somehow, you are oddly precise in the palces you should not be and imprecise where you need to be
oPn7 2017-03-04 07:00:42
yeah yeah gotcha
oPn7 2017-03-04 07:01:26
it cant know whether nix-build .. is done its job or not. i am idiot sorry :D
oPn7 2017-03-04 07:03:07
geekosaur: what this means ">>=" or ">>" ?
geekosaur 2017-03-04 07:03:36
the short version is that's what "do" notation turns into
Myrl-saki 2017-03-04 07:04:12
Is there a Parsec where failing is local?
geekosaur 2017-03-04 07:04:21
when you have something like IO ExitCode, you can;t use it directly because it is something that must be executed by the runtime to at some point produce an ExitCode
Myrl-saki 2017-03-04 07:04:34
Something like attoparsec, except not on Bytestrings and Text.
geekosaur 2017-03-04 07:04:40
>>= is how you add something to be done whenever the ExitCode becomes available
geekosaur 2017-03-04 07:05:09
>> is the version that ignores the result, and is used when the result is IO () because there;s nothing useful to do with a received ()
geekosaur 2017-03-04 07:05:27
but you can use it to "ignore" any IO result
Myrl-saki 2017-03-04 07:05:58
By that, I mean I don't have to use `try`.
Myrl-saki 2017-03-04 07:06:11
(That, or convince me why `try`.)
oPn7 2017-03-04 07:06:52
geekosaur: okey thank you, i got it
tommd 2017-03-04 07:06:58
In liquid Haskell I've reflected a function {-@ reflect func @-} which is a case/pattern match on a user data type. Now liquid is complaining about Unbound Symbols `is_{constructor}`.
tommd 2017-03-04 07:07:06
Any liquid guru's here who have seen this?
geekosaur 2017-03-04 07:09:29
Myrl-saki, the point of try is not fail. the point of try is that backtracking is *expensive*
geekosaur 2017-03-04 07:09:56
so it does not backtrack, if a parser parses something and then fails the part it parsed is still consumed. you use try to tell it explicitly when to backtrack
geekosaur 2017-03-04 07:10:15
and where to backtrack to
geekosaur 2017-03-04 07:10:45
to limit the cost of backtracking
thatguy 2017-03-04 07:11:15
if I am writing some kind of simulation which mostly is: iterate stepSimulation initialstate, should I then just chunk together the whole "world" state into one data structure which stepSimulation then works on?
Myrl-saki 2017-03-04 07:11:45
geekosaur: Right.
tsahyt 2017-03-04 07:11:53
Myrl-saki: attoparsec just has implicit try
Myrl-saki 2017-03-04 07:12:01
tsahyt: I know, and I like that.
Myrl-saki 2017-03-04 07:12:13
But I don't want to work with only ByteStrings and Lists.
Myrl-saki 2017-03-04 07:12:15
Err
tsahyt 2017-03-04 07:12:15
it can and will backtrack arbitrarily, and if you're not careful this can lead to some major performance problems
Myrl-saki 2017-03-04 07:12:16
Text*
Myrl-saki 2017-03-04 07:12:43
geekosaur: Isn't there a better way such as identifying common token prefixes?
geekosaur 2017-03-04 07:13:07
how should it do that without pre-parsing your Haskell code?
Myrl-saki 2017-03-04 07:13:14
geekosaur: Right.
Myrl-saki 2017-03-04 07:13:31
geekosaur: That's the programmer's job.
geekosaur 2017-03-04 07:13:34
perhaps you want to use happy instead of parser combinators
rly 2017-03-04 07:13:45
thatguy: how high performance does this simulation have to be?
geekosaur 2017-03-04 07:14:13
but yes, in parser combinators that is the programmer's job, but few want to do that much work
geekosaur 2017-03-04 07:14:34
but you can;t write simple combinator code and expect runtime to have inspected all possible code paths and built prefix tables
Myrl-saki 2017-03-04 07:14:48
geekosaur: I guess it's a difference in perspective. I find identifying which part to add `try` more tiring and ugly.
tsahyt 2017-03-04 07:15:08
Just having try added implicitly everywhere is hardly more satisfying imo
Myrl-saki 2017-03-04 07:15:23
tsahyt: It's less ugly though. :P
geekosaur 2017-03-04 07:15:34
I don;t find adding try where needed a problem; it's usually fairly obvious where it si needed
thatguy 2017-03-04 07:15:34
rly: its just a hobby project so it doesn't have to compare with C code but I'd like to learn how to do it right in the long run
tsahyt 2017-03-04 07:15:39
a <||> b = try a <|> b
tsahyt 2017-03-04 07:15:49
now you don't have try littered everywhere
tsahyt 2017-03-04 07:15:53
at least not obviously
Myrl-saki 2017-03-04 07:15:56
tsahyt: True. xD
Myrl-saki 2017-03-04 07:16:15
geekosaur: I guess I have to rephrase my question to something the docs don't show.
Myrl-saki 2017-03-04 07:16:31
geekosaur: Where (in real code) does not adding try benefit the programmer?
geekosaur 2017-03-04 07:16:37
...although I admit I figured out parsers (including writing my own parser generators) some time back so I don;t have to think much about it :)
geekosaur 2017-03-04 07:17:01
performance, reduced memory requirements
thatguy 2017-03-04 07:17:11
rly: so I don't need to get the last bit of optimization out of the code but I'd like to think about performance nevertheless
Myrl-saki 2017-03-04 07:17:31
WHoops, I still horribly phrased that.
geekosaur 2017-03-04 07:17:33
granted not too much of either unless your parser is really lopsided, but.
Myrl-saki 2017-03-04 07:17:41
geekosaur: Where is backtracking not required?
rly 2017-03-04 07:18:19
thatguy: GHC will never get you *very* good performance, regardless of what microbenchmarks show.
Myrl-saki 2017-03-04 07:18:21
I find myself requiring backtracking for almost anything.
geekosaur 2017-03-04 07:18:22
anywhere there's only one valid parse, anywhere you are parsing only a single token as pass/fail
monochrom 2017-03-04 07:18:31
When you have an unambiguous grammar. Or an ambiguous grammar but you have a secret tie-breaker.
Myrl-saki 2017-03-04 07:18:42
geekosaur: Ohhh
geekosaur 2017-03-04 07:18:52
(although you must bve careful witht he latter because usually the token type is Char)
thatguy 2017-03-04 07:19:15
rly: is that because it is functional or because of the langauge design?
Myrl-saki 2017-03-04 07:19:25
geekosaur: I forgot the performance implications of `try` on a single token. Thanks.
geekosaur 2017-03-04 07:19:42
you can simplify this with a 2-level parser, one level is Char tokens an produces lexemes, the second level handles lexeme parsing and can avoid backtracking
rly 2017-03-04 07:19:44
thatguy: for real programs, you need to understand the specific run-time system and how it interacts with your program.
thatguy 2017-03-04 07:20:19
rly: yes I was thinking about if some multi-paradigm language like Ocaml may be better suited for me
rly 2017-03-04 07:20:21
thatguy: the language itself induces some slowness.
Myrl-saki 2017-03-04 07:20:26
geekosaur: Right. Not really a fan of that though.
geekosaur 2017-03-04 07:20:27
(the lexeme generator can often avoid try because it has simpler pass/fail conditions, the actual parser can avoid it because it is more often handling single lexeme tokens)
rly 2017-03-04 07:20:40
thatguy: the value of Haskell is that the semantics are quite clear for concurrency/parallelism primitives.
rly 2017-03-04 07:21:19
thatguy: but in GHC there are also some exceptions to this, which exist because of "performance".
rly 2017-03-04 07:22:04
thatguy: Haskell is supposed to be a Sufficiently Smart Compiler language.
rly 2017-03-04 07:22:17
thatguy: OCaml's design is to have a really stupid compiler.
thatguy 2017-03-04 07:22:24
rly: so if I want a general purpose language and am mostly interested in numerical simulations where I do think about performance, would you say that some multi-paradigm language like ocaml may be better suited?
rly 2017-03-04 07:22:43
thatguy: I think you can use Haskell, but you should just use it as a compiler then.
thatguy 2017-03-04 07:23:04
rly: do you recommend any other functional language which maybe is not sooo strict about state and is a bit clearer about what which code does?
hpc 2017-03-04 07:23:06
you could do something silly like use haskell to generate fortran ;)
rly 2017-03-04 07:23:06
thatguy: this is a bit what the domain specific language hype was about a few years ago.
rly 2017-03-04 07:23:20
hpc: why would that be silly?
rly 2017-03-04 07:24:10
thatguy: I think you want to have a slow implementation in Haskell, and then another backend which compiles for example to Fortran (or C++, or..).
rly 2017-03-04 07:24:37
thatguy: FFTW works like this.
monochrom 2017-03-04 07:24:47
Ironically, generating Fortran is less silly than generating C.
Sornaensis 2017-03-04 07:24:58
that's how scipy works
rly 2017-03-04 07:25:09
thatguy: it exploits OCaml to do various smart things, but it never actually uses the OCaml run-time system.
monochrom 2017-03-04 07:25:10
Did you know that mature Fortran compilers are more optimizing than mature C compilers?
Sornaensis 2017-03-04 07:25:11
you write python and it emits C++
monochrom 2017-03-04 07:25:45
Age of Fortran notwithstanding, there is also C's own issue of too many semantic gotchas forcing optimizers to be really paranoid.
thatguy 2017-03-04 07:25:46
Sornaensis: I was using numpy/scipy for my stuff before learning haskell indeed
rly 2017-03-04 07:25:47
thatguy: having said that, Haskell is fine for the first version of your simulation, or whatever.
rly 2017-03-04 07:26:25
thatguy: if at some point it turns out that you want to do *huge* things and you are running a few hundred node cluster, then you might want to look in these things.
Sornaensis 2017-03-04 07:27:49
what's wrong with cloud haskell
rly 2017-03-04 07:28:02
Sornaensis: nobody uses it?
rly 2017-03-04 07:28:12
Sornaensis: by "nobody", I mean "almost nobody".
rly 2017-03-04 07:28:27
Sornaensis: it was just written as a "look, we can do Erlang too".
Sornaensis 2017-03-04 07:28:49
that didn't really answer my question
geekosaur 2017-03-04 07:29:00
your question isn;t really answerable
thatguy 2017-03-04 07:29:37
rly: ok thanks for the insight
rly 2017-03-04 07:29:56
Sornaensis: the latest "news" was over a year ago.
thatguy 2017-03-04 07:30:16
that helped a lot but now I am thinking if haskell is the right language to dig further into
rly 2017-03-04 07:30:23
Sornaensis: this might mean it's already God's personal best code and nothing can be improved, or nobody cares about it.
geekosaur 2017-03-04 07:30:28
that said, cloud haskell depends on a feature of ghc that is still evolving (stable names)
rly 2017-03-04 07:30:43
That was quick.
geekosaur 2017-03-04 07:30:52
so a pause in development can mean they're waiting on changes upstream
rly 2017-03-04 07:31:01
A business wouldn't like to be dependent on a single implementation of a language.
monochrom 2017-03-04 07:31:14
I think both can happen. Usually, nobody cares about God's personal best code.
thatguy 2017-03-04 07:31:33
yeah well I did the whole tutorial cis 194 and loved it but as soon as I want to apply it to my problems (mostly numerical stuff) I get the feeling that I would like to have some state at least
geekosaur 2017-03-04 07:31:52
rly, where's the second impl of perl5? python? (ok, there's a few but they're all worse) php?
rly 2017-03-04 07:32:01
thatguy: there are IORefs in Haskell.
rly 2017-03-04 07:32:24
thatguy: all the features are there, but imperative algorithms often look more ugly in Haskell.
rly 2017-03-04 07:32:35
(which is to be expected)
thatguy 2017-03-04 07:32:57
but am I just to new to haskell or is numerical (mathematics) mostly very imperative?
thatguy 2017-03-04 07:33:24
its nearly always that you have some state which changes or some solution which you imperatively make better etc
rly 2017-03-04 07:33:47
thatguy: for the part where it matters (FPU behaviour), Haskell is also not pure.
rly 2017-03-04 07:34:55
I wonder whether anyone ever has demonstrated superior Haskell performance for a real numerical simulation (i.e., something used in climate models, for example).
rly 2017-03-04 07:35:17
I'd expect to have heard about it, if that had happened.
monochrom 2017-03-04 07:35:18
To a large extent, the "multitude" of Python implementations is no better than Haskell's situation of "we do have jhc, ajhc, nhc, and hugs".
rly 2017-03-04 07:35:27
monochrom: I disagree on that point.
rly 2017-03-04 07:35:42
monochrom: Python2.X has viable implementations.
rly 2017-03-04 07:36:03
monochrom: in Haskell, there is Haskell 98 in what can best be described as toy implementations.
thatguy 2017-03-04 07:36:37
monochrom: I don't understand what you mean by that
thatguy 2017-03-04 07:36:54
rly: do you use haskell for climate numerics?
rly 2017-03-04 07:37:05
thatguy: there are some full program optimization compilers for Haskell.
rly 2017-03-04 07:37:22
thatguy: they are even more niche (of course) than using Haskell in the first place.
rly 2017-03-04 07:37:26
thatguy: no
rly 2017-03-04 07:37:52
thatguy: I have used Haskell for non-trivial things, which completely destroyed GHC.
rly 2017-03-04 07:38:00
thatguy: not the same domain as yours.
thatguy 2017-03-04 07:38:11
so you are not actively using haskell anymore?
rly 2017-03-04 07:38:32
thatguy: no, I sometimes write some scripts in it, but no "real work".
thatguy 2017-03-04 07:38:45
so what do you use now if I may ask?
rly 2017-03-04 07:39:01
thatguy: I don't want to endorse other things I also don't like :)
rly 2017-03-04 07:39:21
thatguy: IMHO, the world is a complete mess.
rly 2017-03-04 07:39:47
thatguy: we don't even have production file systems which have been verified to be free of bugs.
thatguy 2017-03-04 07:39:52
:D
cocreature 2017-03-04 07:40:21
well, formal verification is a _lot_ of work
rly 2017-03-04 07:40:21
We do have academic file systems with that property, though, but that happened in the past 5 years or so.
rly 2017-03-04 07:40:46
cocreature: I think it's less work than having a "bug tracking system" and "debugging random clients".
thatguy 2017-03-04 07:40:53
ok I think I'll just try to implement my simulation in haskell for now
rly 2017-03-04 07:40:58
cocreature: take for example "ZFS".
rly 2017-03-04 07:41:11
cocreature: it was designed a *long* time ago, and it still doesn't work.
cocreature 2017-03-04 07:41:14
rly: as someone working on formal verification, I disagree :)
thatguy 2017-03-04 07:41:26
but did I get it right that if you want to be performant on such bigger projects you cannot stick to functional languages but will have to return to C/C++ or something else lowlevel imperative?
rly 2017-03-04 07:41:35
cocreature: what do you do? Coq/Agda?
cocreature 2017-03-04 07:41:48
even if you formally verify your file system, you are probably making incorrect assumptions in your formal model and your file system is still buggy
rly 2017-03-04 07:42:02
cocreature: wrong assumptions can be fixed.
ertes 2017-03-04 07:42:08
Myrl-saki: http://blog.ezyang.com/2014/05/parsec-try-a-or-b-considered-harmful/
rly 2017-03-04 07:42:09
cocreature: at least it would get better over time.
rly 2017-03-04 07:42:26
cocreature: with our current development method, there is no way to know whether progress is being made.
cocreature 2017-03-04 07:42:38
well good luck writing your formally verified file system
rly 2017-03-04 07:43:10
cocreature: you don't want to say specifically what tooling you use?
rly 2017-03-04 07:43:27
cocreature: do you work on it commercially? Intel?
cocreature 2017-03-04 07:43:34
rly: we prove the equivalence of C code using smt solvers
cocreature 2017-03-04 07:43:42
not commercially, academia
ertes 2017-03-04 07:43:50
Myrl-saki: auto-backtracking is needlessly expensive and in parsers for human languages makes error reporting almost useless
rly 2017-03-04 07:43:59
cocreature: right, and that approach was already dead when I was in university.
cocreature 2017-03-04 07:44:07
lol
cocreature 2017-03-04 07:44:16
sry I have no interest in continuing that conversation
rly 2017-03-04 07:44:32
cocreature: unfortunate.
