| --- Log opened Mon Mar 26 00:00:01 2018 |
| 00:00 | <&[R]> | Make has an interesting default rule for %.sh |
| 00:01 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
| 00:01 | | mode/#code [+o Alek] by ChanServ |
| 00:04 | | Kizor_ [moryok@Nightstar-e0a4sm.utu.fi] has joined #code |
| 00:04 | | Netsplit Golgafrincham.Nightstar.Net <-> Deepthought.Nightstar.Net quits: Vorntastic, Kizor, @PinkFreud, @Syloq, @[R], @celticminstrel |
| 00:05 | | Netsplit over, joins: @Syloq, @PinkFreud |
| 00:07 | | celticminstrel [celticminst@Nightstar-m1ak9t.dsl.bell.ca] has joined #code |
| 00:07 | | mode/#code [+o celticminstrel] by ChanServ |
| 00:08 | | [R] [rstamer@Nightstar-d7h8ki.org] has joined #code |
| 00:08 | | mode/#code [+ao [R] [R]] by ChanServ |
| 00:15 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 00:49 | | Kizor_ is now known as Kizor |
| 01:05 | | Degi [Degi@Nightstar-ibr0nm.dyn.telefonica.de] has quit [Connection closed] |
| 01:19 | | himi [sjjf@Nightstar-1drtbs.anu.edu.au] has joined #code |
| 01:19 | | mode/#code [+o himi] by ChanServ |
| 03:25 | <&[R]> | McMartin: do you hand generate your object file lists in your makefiles? |
| 03:27 | < McMartin> | Depends on the project |
| 03:27 | < McMartin> | For the stuff on Bumbershoot I usually have, like, a dozen targets that share a bunch of, but not all, their objects. |
| 03:27 | < McMartin> | And instead of trying to parse out a squillion libraries and do it all at link time I just name them by hand. |
| 03:28 | < McMartin> | Otherwise, yeah, you play patsubst games and use wildcards. |
| 03:29 | <&[R]> | Ah |
| 03:29 | <&[R]> | Thanks |
| 03:29 | < McMartin> | But honestly, I've been burned more times than I'd like to admit by having directory sweepers decide that some scratch files should be part of the final product. |
| 03:30 | <&[R]> | Yeah, probably a good point to do makefile recursion at that point (where there's another makefile in the subdirectory) |
| 03:31 | <&[R]> | :) |
| 03:34 | < McMartin> | One of the sort of atavistic impulses I'm indulging on Bumbershoot is the idea that absolutely everything about a system should be happening solely by my command. |
| 03:48 | <&[R]> | Yeah |
| 03:49 | <&[R]> | I find anything that is sufficiently "smart" ends up being a massive pain to debug |
| 03:49 | <&[R]> | Gradle being a great example there |
| 04:13 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 04:13 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 04:49 | | * McMartin rips through the first ten actual problems on the Erlang track in Exercism. |
| 05:08 | | Vornlicious [Vorn@Nightstar-ul3svm.sub-174-210-2.myvzw.com] has joined #code |
| 05:08 | | Derakon is now known as Derakon[AFK] |
| 05:09 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 05:09 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 05:11 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 05:12 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 07:04 | | himi [sjjf@Nightstar-1drtbs.anu.edu.au] has quit [Ping timeout: 121 seconds] |
| 07:29 | | celticminstrel [celticminst@Nightstar-m1ak9t.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 09:21 | | Degi [Degi@Nightstar-ibr0nm.dyn.telefonica.de] has joined #code |
| 09:56 | | Degi [Degi@Nightstar-ibr0nm.dyn.telefonica.de] has quit [Connection closed] |
| 09:58 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has joined #code |
| 09:58 | | mode/#code [+o himi] by ChanServ |
| 11:16 | | Kindamoody[zZz] is now known as Kindamoody |
| 11:48 | | Kindamoody is now known as Kindamoody|afk |
| 14:42 | <&jeroud> | McMartin: Why Erlang? |
| 14:43 | <&jeroud> | Also, we should start a #code team or whatever. |
| 14:45 | <&jeroud> | (For writing new programs, Elixir has a bunch of advantages and basically no disadvantages.) |
| 14:46 | <&jeroud> | (But if you need to modify existing Erlang programs, it doesn't help much.) |
| 14:52 | < Vornlicious> | I should learn go so I can improve Rikki and aim it at Python |
| 14:56 | <&jeroud> | There's a Go exercism track!~ |
| 15:10 | | Degi [Degi@Nightstar-ibr0nm.dyn.telefonica.de] has joined #code |
| 16:18 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has quit [Connection closed] |
| 16:23 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has joined #code |
| 16:23 | | mode/#code [+ao VirusJTG VirusJTG] by ChanServ |
| 16:56 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 17:02 | | Kindamoody|afk is now known as Kindamoody |
| 17:08 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 17:08 | | mode/#code [+o mac] by ChanServ |
| 17:11 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 17:27 | < McMartin> | jeroud: Historical perspective, mostly, and because realistically I'm more likely to need to modify Erlang than solve a problem ex nihilo in the space. |
| 17:28 | < McMartin> | The one significant comment on any problem so far was half-wron though. This is not a terribly useful community, just a possibly handy exercise book for the non-distributed parts of OTP. |
| 17:30 | <~Vornicus> | Which is part of why I always made sure to give very detailed commentary |
| 17:30 | < McMartin> | I didn't even say any of *my* problems |
| 17:32 | < McMartin> | There were also a few things I was hoping to pick up by example, but nobody does them, so, welp. |
| 17:40 | <&jerith> | McMartin: That's why I think a #code team would be useful. |
| 17:41 | <&jerith> | I think the community's too small in the less popular languages. |
| 17:41 | <&jerith> | FWIW, I found Elixir much better than Erlang for learning how to do this stuff right. |
| 17:42 | <&jerith> | Most of my Erlang code back in the day was manual receive loops and stuff, because OTP was the weird thing that wasn't very well documented but that everyone said I should use. |
| 17:43 | <~Vornicus> | I was the only major commenter on goddamn *python* |
| 17:44 | <&jerith> | Two days into writing my first Elixir code I was slinging Supervisors and GenServers around all over the place. :-) |
| 17:45 | <&jerith> | Anyway, Erlang's not bad once you get past the mediocre documentation and godawful syntax. |
| 17:45 | <&jerith> | (The latter is what broke me, because I ended up devoting more energy to syntactic correctness than to writing my programs.) |
| 17:53 | <&jerith> | But if you're exercisming in Erlang, I'm happy to follow along and offer what commentary I can. |
| 18:14 | <&jerith> | There, created a team for this channel and invited Vornicus and McMartin. |
| 18:17 | <&jerith> | McMartin: If you give me a couple of days, I can probably catch up with you on the Erlang track. |
| 18:18 | <&jerith> | Let me know if there's anything in particular you'd like me to look at or comment on. |
| 18:18 | <&jerith> | Otherwise I'll just point out whatever looks like it might be helpful to point out. |
| 18:19 | <&jerith> | (Bearing in mind that I'm not an expert in Erlang style and idiom, but do understand the semantics of the language quite well.) |
| 18:33 | < McMartin> | Sure |
| 18:33 | < McMartin> | I still haven't figured out how much what I'm doing is hilarious jank and how much is "no, it's just that the Erlang core is a dynamic ML written by Prolog guys" |
| 18:34 | < McMartin> | I'm particularly bemused by Erlang's if construct. |
| 18:35 | < McMartin> | I think my big questions at the moment are really: |
| 18:36 | < McMartin> | - What can I learn from OTP about how to organize concurrent code |
| 18:36 | < McMartin> | - How does BEAM provide guarantees strong enough to let Erlang programs run with the necessary reliability |
| 18:36 | < McMartin> | - How thin a wrapper around BEAM is Erlang, and how thin a wrapper around Erlang is Elixir |
| 18:37 | < McMartin> | I can make up answers to #2 but they're answers I just made up and might have real answers. |
| 18:37 | < McMartin> | (The made-up answer is "If BEAM segfaults or something, that's an Erlang node going down and the distributed Erlang runtime just deals with that like it deals with all other faults" |
| 18:37 | < McMartin> | ) |
| 18:38 | <&jerith> | The made-up answer is essentially correct. |
| 18:39 | < McMartin> | If so then that question becomes "How can I use this to get thrown out of parties thrown by my academic grand-uncle" |
| 18:40 | <&jerith> | There are a few ways to crash BEAM. |
| 18:42 | <&jerith> | The inside-Erlang ways are mostly exhausting the atom table (so don't dynamically create atoms in an unounded way, they live forever and there's a limit on the table size) or running out of memory (which is pretty difficult unless you have a bunch of slow-moving processes passing large inaries around or something). |
| 18:43 | <&jerith> | Of course, you can link in non-Erlang code and that can happily segfault. |
| 18:44 | | * McMartin nods |
| 18:45 | <&jerith> | BEAM is essentially Erlang semantics turned into bytecode. The bulk of the divergences are implementation detail. |
| 18:46 | <&jerith> | For example, the spec says "processes must be isolated", BEAM does that by giving each process its own heap and then having a separately-GCed large binary store as an optimisation. |
| 18:50 | <&jerith> | Erlang doesn't make any of the concurrency-related problems go away (except for shared memory corruption, because it doesn't really give you shared memory), but it does give you a sensible foundation to build on. |
| 18:51 | <&jerith> | More to the point, though, the concurrency stuff is there because it was the only way to get fault isolation right. |
| 18:52 | < McMartin> | Right, but that means they've faced a bunch fo things head-on and so the design philosophy documentation is something I expect to benefit from |
| 18:53 | <&jerith> | https://www.youtube.com/watch?v=_PLCqBm8vQU is about the best high-level overview I've found. |
| 18:53 | < McMartin> | Cool, thanks. |
| 18:54 | <&jerith> | I've recently found that conference talks are a really good way to pick up high level concepts, although I still go back to text docs for all the detail stuff. |
| 18:56 | <&jerith> | Looking at the lone "leap" solution with a comment on it, I'm reminded that `and`/`or` are not short-circuit, while `andalso`/`orelse` are. |
| 18:57 | < McMartin> | Yeah |
| 18:58 | < McMartin> | And, uh, since I was vague about it: the part of `if` that bemused me was that its conditions were subject to the same conditions as match-clause guards, which in particular means that if you want to, say, test the result value of some function, you have to explicitly bind it to a variable first. |
| 18:59 | <&jerith> | That's not a thing I remember, but I typically don't use conditionals much in functional languages with pattern matching. |
| 18:59 | <&jerith> | Elixir's `if` has sensible semantics, though. |
| 18:59 | < McMartin> | I deliberately varied my style across problems to try to cover the basic expression space. |
| 19:00 | < McMartin> | "Bob" in particular was one where if made a lot more sense as a construct, because you were testing a great many unrelated properties in an extremely strict order. |
| 19:00 | <&jerith> | Do you have a formatter that lines stuff up in "leap", or did you do that by hand? |
| 19:01 | < McMartin> | Depends on whether I was using emacs or vim at the time. |
| 19:02 | < McMartin> | Emacs Erlang mode is extremely opinionated, but I wasn't a total fan of its opinions. |
| 19:02 | < McMartin> | Horizontal spacing I normally do by hand; it's a habit I picked up from ML. |
| 19:03 | | * McMartin checks his own solution |
| 19:03 | < McMartin> | Yeah, that was by hand. |
| 19:04 | < McMartin> | And actually that's a habit I've had for a very long time; I first used it when organizing code that did a bunch of bitshifting and bitmasking in C. |
| 19:04 | <&jerith> | I am learning to sujugate my preferences to the preferences of my tools. :-( |
| 19:04 | < McMartin> | Whether I do that or not depends on the precise toolchain, for me. |
| 19:04 | <&jerith> | (But only where the tool implements a *very* strong community convention.) |
| 19:05 | <&jerith> | (So `go fmt` and `mix format`.) |
| 19:05 | < McMartin> | Yeah, go fmt is the only place where I rely entirely on machine formatting. |
| 19:05 | <&jerith> | I see you went for body-recursion rather than tail-recursion in "accumulate". |
| 19:05 | < McMartin> | Though my C is generally very strict |
| 19:06 | < McMartin> | (Likewise C++ and ObjC for the few additional conventions they add) |
| 19:06 | < McMartin> | ObjC actually has a convention not-unlike what I did in Leap, where certain tokens are in fact "supposed" to be right-justified within a line to match previous lines. |
| 19:07 | < McMartin> | Xcode does that for you, so I just roll with that but it's an easy roll, as it were |
| 19:08 | < McMartin> | My attitude in the very early problems was very much "Please do not waste my time with this CS 3 dross" |
| 19:09 | < McMartin> | I do need to update my solution to Raindrops to account for the right part of the half-wrong comment I found. |
| 19:10 | <&jerith> | Yeah, I think those are mostly there as a warmup and to get the people learning the language with exercism comfortable with basic syntax and stuff before the real problems show up. |
| 19:10 | < McMartin> | Also I feel like for many of these things I should be preferring binaries to strings, but (a) I don't know if that's even true and (b) my system only has OTP 19 and it seems like a bunch of stuff surrounding these changed in OTP 20. |
| 19:11 | < McMartin> | In particular, string:trim does not exist on my system, to my considerable regret. |
| 19:11 | <&jerith> | OTP 20 has a lot of Elixir support in it. |
| 19:12 | < McMartin> | Taking a quick look at various bits of Elixir code: are modules produced by Erlang and Elixir more or less identical? |
| 19:13 | <&jerith> | IIRC, `string.strip` is the old version. |
| 19:13 | < McMartin> | Yep, and it's not remotely good enough, because it can only match as single character. |
| 19:13 | < McMartin> | ANAICT. |
| 19:14 | < McMartin> | So if you want to strip, say, all kinds of whitespace, you have to repeatedly iterate with different arguments until it fixpoints. |
| 19:14 | <&ToxicFrog> | strip vs. trim has tripped me up several times in several different languages >.< |
| 19:14 | < McMartin> | (Or, as I did, just filter out all whitespace entirely, because I didn't need to tokenize for that problem.) |
| 19:15 | < McMartin> | I'm kind of tempted to fire up the C track and pick fights |
| 19:15 | <&jerith> | If you don't provide `Character`, it seems `string:strip` will remove "blanks". |
| 19:15 | <&jerith> | Which I'm guessing is horizontal whitespace. |
| 19:15 | < McMartin> | Based on my test results on OTP 19, "blanks" means codepoint 32 |
| 19:16 | < McMartin> | It does not mean codepoint 13 or even codepoint 9. |
| 19:16 | <&jerith> | Ah. |
| 19:16 | < McMartin> | (Both of which are testcases) |
| 19:16 | <&jerith> | Anyway, Erlang's string handling has historically been bloody awful. |
| 19:17 | < McMartin> | Indeed |
| 19:17 | <&jerith> | Turns out telco switches don't really need that stuff much. |
| 19:17 | < McMartin> | But it's pretty OK with binary blobs! |
| 19:17 | <&jerith> | That's one of the major improvements Elixir makes. |
| 19:17 | < McMartin> | I live in a world with a lot of binary blobs; byte slices are rampant in the three Go programs of any size I've written. |
| 19:17 | <&jerith> | Elixir has "strings" (utf8-encoded binaries) and "charlists" (Erlang strings, which are lists of integer codepoints). |
| 19:18 | <&jerith> | Pattern matching binaries is <3 <3 <3. |
| 19:18 | | Vorntastic [Vorn@Nightstar-4old91.sub-97-46-130.myvzw.com] has joined #code |
| 19:18 | < McMartin> | That explains much of OTP 20's string module, which has "chardata" as a type that is mostly binaries of utf8-encoded stuff. |
| 19:19 | < McMartin> | So anyway, yeah, looking at the bad support for strings and the excellent support for binaries my response was to laugh in bitter recognition. |
| 19:19 | < McMartin> | And then start using charlists for everything with half-remembered Haskell. |
| 19:20 | < McMartin> | (It seems like the testcases are all using charlists anyway) |
| 19:20 | <&jerith> | On the otherhand, iolists (arbitrarily nested lists of integers and binaries) are awesome. |
| 19:20 | | Pandevornium [Vorn@Nightstar-mhc2rt.sub-174-210-8.myvzw.com] has joined #code |
| 19:20 | < McMartin> | Yeah. That's a thing I encountered some ways in and haven't yet wrapped my head fully around. |
| 19:20 | | Pandevornium [Vorn@Nightstar-mhc2rt.sub-174-210-8.myvzw.com] has quit [[NS] Quit: Bye] |
| 19:20 | | Pandevornium [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 19:20 | <&jerith> | It's basically an optimisation. |
| 19:20 | < McMartin> | They change the necessary cost of quite a few operations. |
| 19:21 | | Vornlicious [Vorn@Nightstar-ul3svm.sub-174-210-2.myvzw.com] has quit [Ping timeout: 121 seconds] |
| 19:21 | < McMartin> | But it seems like you have to flatten them in order for the test cases to accept them. |
| 19:22 | <&jerith> | All the I/O operations accept them, so you don't need to bother flattening or concatenating or whatever when you're building a thing to push at a socket or a file or somesuch. |
| 19:22 | < McMartin> | Yep |
| 19:22 | < McMartin> | That fact is what tripped up the commenter that made the half-wrong comment about Raindrop :) |
| 19:22 | <&jerith> | But you can't easily compare two iolists without flattening them into some form. |
| 19:22 | | Vorntastic [Vorn@Nightstar-4old91.sub-97-46-130.myvzw.com] has quit [Ping timeout: 121 seconds] |
| 19:23 | < McMartin> | But yeah, he was saying "build it up, reverse it, then flatten it, in general", and for this problem it was better to build it in reverse by appending. |
| 19:23 | < McMartin> | But my solution currently builds it forwards by appending which isn't as good. |
| 19:23 | < McMartin> | Since append is linear in the first argument. |
| 19:24 | <&jerith> | Ooh, Raindrops is the next problem once I finish this one. |
| 19:29 | <&jerith> | To get back to your earlier questions, Elixir compiles to the Erlang AST and then feeds that to the Erlang compiler to get bytecode. |
| 19:29 | <&jerith> | It does a bunch of stuff in its own compilation, thought. |
| 19:29 | <&jerith> | *though |
| 19:30 | <&jerith> | For starters, it expands macros. |
| 19:30 | <&jerith> | But it also does things like flatten out nested modules. |
| 19:31 | < McMartin> | Yeah. |
| 19:32 | < McMartin> | The thing that jumped out at me from our previous conversation is "it breaks out if conditions and turns them into prebound variables to match against". |
| 19:32 | <&jerith> | So `defmodule Foo.Bar do ... end` is equivalent to `defmodule Foo do defmodule Bar do ... end end` and they both emit two modules: 'Elixir.Foo' and 'Elixir.Bar'. |
| 19:34 | <&jerith> | I'm not actually sure how that works. |
| 19:35 | <&jerith> | Elixir has `if` which is the familiar `if`/`do`/`else`/`end` construct, but it also has `cond` which is what you'd expect from other functional languages. |
| 19:36 | <&jerith> | And Elixir's `case` is the same as Erlang's. |
| 19:36 | < McMartin> | Yeah, I haven't seen anything in my Erlang wanderings so far (admittedly more of a stroll around the yard than real wanderings) that suggests it even has a notion of nested modules |
| 19:36 | <&jerith> | It doesn't. One flat namespace. |
| 19:36 | < McMartin> | As of the familiar cond, Erlang's if is cond but you're only allowed to write conditions it can prove immediately have no side effects at the time of the evaluation. |
| 19:37 | < McMartin> | I am used to semi-functional languages's conds allowing side effects and enforcing an evaluation order on the cases |
| 19:37 | < McMartin> | Erlang's if appears to in fact enforce an evaluation order on the cases because otherwise recursive base cases wouldn't work, though, so I don't know wtf they wouldn't allow side effects there. |
| 19:37 | | * McMartin shrug |
| 19:37 | <&jerith> | Elixir has nested modules, but because they're basically syntactic sugar you don't get things like private submodules. |
| 19:38 | <&jerith> | Yeah, all sequenced pattern match constructs are ordered. |
| 19:39 | <&jerith> | Although I believe the compiler is allowed to compile them to something else as long as the behaviour remains unchanged. |
| 19:41 | < McMartin> | Right, so part of that is the restriction no-side-effects and in particular no-calls-to-normal-functions. |
| 19:41 | < McMartin> | That's a pretty bitter pill coming in from Scheme. |
| 19:42 | <&jerith> | That makes sense for guards, not so much for `if`/`cond`. |
| 19:42 | < McMartin> | (I notice Elixir has defguardp, which I assume enforces similar restrictions.) |
| 19:43 | < McMartin> | Right. Now, if you're in a position where you can *write* an if/cond you're in a position where you can prepend it with exactly those evaluations you want to evaluate, and nest as needed if you want to only pay the cost for later operations. |
| 19:43 | <&jerith> | defgaurd (and defguardp which is the same except unexported) it a much-needed way to write your own guard functions. |
| 19:43 | < McMartin> | ... a thing I should really do for some of my later problems that need to do deduplication is nesting my conditions to save conses or not do excessive filtering |
| 19:44 | <&jerith> | That's mostly a hack around insufficiently smart compilers, but it's not reasonable to build sufficiently smart ones. |
| 19:44 | < McMartin> | Yeah. It seems the idiomatic way to do guard functions in Erlang is by defining them as macros. |
| 19:45 | <&jerith> | Before defguard (which arrived in Elixir 1.6 this year) you either had to write complicated macros or just repeat your code. |
| 19:45 | <&jerith> | Elixir macros are very different from Erlang macros. |
| 19:46 | < McMartin> | I would expect this. |
| 19:59 | <&jerith> | There, I've submitted my Raindrops. |
| 20:00 | <&jerith> | It's a straight translation of my Elixir solution, although in Elixir I'm operating on binaries rather than charlists and <> is less frowned upon by the community than ++. |
| 20:00 | <&jerith> | And now it's time to head home. |
| 20:04 | <&jerith> | (I have some vague thoughts on your Raindrops, but not well formed enough to express at present.) |
| 20:04 | < McMartin> | That one is a bit, er, continuation-passing-style |
| 20:05 | < McMartin> | It's probably better handled as a program that's one function executing operations in sequence. |
| 20:09 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has joined #code |
| 21:04 | | Kizor [moryok@Nightstar-e0a4sm.utu.fi] has quit [Ping timeout: 121 seconds] |
| 21:05 | | Kizor [moryok@Nightstar-e0a4sm.utu.fi] has joined #code |
| 21:25 | <&jerith> | Yeah. The combination of each function performing a separate step and each function having to know which step comes next is what makes it feel a it awkward. |
| 21:25 | <&jerith> | *bit |
| 21:38 | | gnolam [quassel@Nightstar-sti997.cust.bahnhof.se] has joined #code |
| 21:38 | | mode/#code [+o gnolam] by ChanServ |
| 21:43 | < McMartin> | jerith: The part that rankles about a single function though is that I can't rebind, and I genuinely don't need or want those earlier binds. |
| 21:45 | <&jerith> | The typical Erlangism is to have `X0 = ...; X1 = ...; X2 = ...` and I don't much like it. |
| 21:47 | <&jerith> | A different solution is to have tagged "commands" and pass them to a single function that has a clause for each tag. |
| 21:47 | <&jerith> | `calc({add, X, Y}) -> X+Y; calc({mul, X, Y}) -> X*Y.` etc. |
| 21:48 | <&jerith> | Err, that's a different solution to a different problem. But it's still more or less applicable here. |
| 21:50 | <&jerith> | Instead of having separate functions that I call in a fixed sequence, I could have had `rain({pling, N}) when N rem 3 == 0 -> ...` etc. |
| 21:52 | <&jerith> | Or `rain(N, {Factor, Drop}) when N rem Factor == 0 -> Drop`, except I can't remember if having variables on both sides of the operator is legal. |
| 22:07 | | RchrdB [RchrdB@Nightstar-qe9.aug.187.81.IP] has quit [Ping timeout: 121 seconds] |
| 22:33 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
| 22:38 | < McMartin> | I thitnk it must be |
| 22:38 | < McMartin> | Otherwise you couldn't guard based on variables. |
| 23:19 | | gnolam [quassel@Nightstar-sti997.cust.bahnhof.se] has quit [[NS] Quit: Z?] |
| 23:37 | | mac [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has quit [[NS] Quit: Live Long and Prosper.] |
| 23:43 | | macdjord [macdjord@Nightstar-a1fj2k.mc.videotron.ca] has joined #code |
| 23:43 | | mode/#code [+o macdjord] by ChanServ |
| 23:50 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| --- Log closed Tue Mar 27 00:00:02 2018 |