--- Log opened Fri Jun 16 00:00:14 2017 |
00:00 | <&McMartin> | But going with that feels like I'm just sticking with what I know, while grinding out the umpteen-case parse-expr switch feels like I'm doing unnecessary work. |
00:01 | <&McMartin> | So, I open the question to the gutchecks of those who spend more time in this language space: how would you handle something like this? |
00:01 | <&ToxicFrog> | paging Pi to the channel |
00:09 | | Turaiel is now known as Turaiel[Offline] |
00:20 | <&McMartin> | I think there's a solid half-dozen regulars who fit the bill, actually |
00:42 | | Vorntastic [Vorn@Nightstar-3slm3k.sub-174-199-0.myvzw.com] has quit [[NS] Quit: Bye] |
01:06 | | himi [sjjf@Nightstar-dm0.2ni.203.150.IP] has joined #code |
01:07 | | mode/#code [+o himi] by ChanServ |
02:01 | | celticminstrel [celticminst@Nightstar-jb792f.dsl.bell.ca] has joined #code |
02:01 | | mode/#code [+o celticminstrel] by ChanServ |
02:43 | | Turaiel[Offline] is now known as Turaiel |
03:55 | <@Azash> | I disagree about the Feynman algorithm, even if it might not have been meant as serious advice |
03:56 | <~Vornicus> | it wasn't really |
03:56 | <@Azash> | Based on own experience and anecdotal evidence, the more efficient and effective way to do it is to forget about the problem |
03:56 | <@Azash> | You'll take a shower three days later and suddenly stumble on the perfect solution |
03:56 | <@Azash> | >> |
03:56 | <~Vornicus> | But seriously, this "if it isn't on stackoverflow it can't be done" bs is bs |
03:57 | < Mahal> | I concur re: sleeping on it for a bit. Often a very successful approach |
03:57 | <@Azash> | Well, I don't think that was quite how Erik meant it |
03:59 | <@Azash> | Like most things the issue is not how to implement but how to be aware of a solution, and his intent was probably more that if it's not on SO, then there's not a lot of easily available ways to see how to solve the problem |
03:59 | <@Azash> | To exacerbate it a bit |
04:00 | <@Azash> | Generally it helps to just put together a horrible clunky maximum force solution and come back and look at it every couple of days and fix any glaring inefficiencies |
04:00 | <@Azash> | If you're not on a schedule |
04:01 | | * Azash remembers having an out-of-the-blue epiphany at work on how to produce a far more efficient WoD dice analytics tool |
04:02 | < Mahal> | discussion with some dev friends around appropriately sizing resource to assign to a project. |
04:03 | < Mahal> | mcpanzors > how big is the project |
04:03 | < Mahal> | kukoshaku > it's a mid-size project |
04:03 | < Mahal> | mcpanzors > an elephant is tiny compared to the ss queen mary |
04:03 | < Mahal> | kukoshaku > on a scale of Parakeet to Elephant .... We're talkin' Labrador-ish? |
04:03 | < Mahal> | kukoshaku > but this is a poorly trained Lab... |
04:03 | < Mahal> | mcpanzors > and is it going to be maintained properly? |
04:03 | < Mahal> | kukoshaku > ok, so the Lab is limping and smells funny too >.> |
04:05 | <@Azash> | Estimates are the worst |
05:08 | | celticminstrel [celticminst@Nightstar-jb792f.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
05:16 | <@Pi> | McMartin: Interesting question, but probably needs more details! |
05:17 | <@Pi> | Are you already working in terms of ADTs and pattern matching? |
05:17 | <@Pi> | How are they structured? |
05:17 | <@Pi> | Is this for the evaluation function? |
05:18 | <@Pi> | Or more parsing and validation? |
05:18 | <@Pi> | What's an example of the kind of code you find unnecessary, or repetitive? |
05:21 | <&McMartin> | In principle, I can be tabula rasa here, but I am using ADTs. |
05:21 | <&McMartin> | Goal is parsing. |
05:21 | <&McMartin> | Sample clause that looks very similar to many other clauses: |
05:21 | | Turaiel is now known as Turaiel[Offline] |
05:21 | <&McMartin> | Some(Token::Open) => { |
05:21 | <&McMartin> | let mut args = try!(parse_stmt_arglist(line, 2, Some(4))); |
05:21 | <&McMartin> | let mut iter = args.drain(..); |
05:21 | <&McMartin> | let arg1 = iter.next().unwrap(); |
05:21 | <&McMartin> | let arg2 = iter.next().unwrap(); |
05:21 | <&McMartin> | let arg3 = iter.next(); |
05:21 | <&McMartin> | let arg4 = iter.next(); |
05:22 | <&McMartin> | Ok(Stmt::Open(arg1, arg2, arg3, arg4)) |
05:22 | <&McMartin> | }, |
05:22 | <&McMartin> | parse_stmt_arglist is the master expression parser that ends up producing a thing that looks "Lispy" by my definition. |
05:22 | <&McMartin> | It's the bits after it where I pile them into a specific alternative's constructor that seems repetitive. |
05:23 | <&McMartin> | If that's about right, I can imagine this being a solid place for Rust's macro system. |
05:23 | <@Pi> | Ah, so that looks like token stream parsing code? |
05:23 | <&McMartin> | Yes indeed. |
05:24 | <@Pi> | My first thought is that I would much rather be using parser combinators. |
05:24 | <@Pi> | :) |
05:25 | <@Pi> | It will probably make this whole class is code simpler and less repetitive. |
05:25 | <@Pi> | Is that something you've looked at? |
05:25 | <&McMartin> | And I hope you'll understand if I treat that as dodging the question |
05:25 | <&McMartin> | Not for Rust specifically. |
05:25 | <@Pi> | (class of code, even) |
05:25 | <&McMartin> | I've used Parsec, and I'm well-familiar with the previous generation of parser generators as well. |
05:26 | <@Pi> | I'm not sure how it's dodging the question? It's what I'd look at next, at least? |
05:27 | <&McMartin> | It's dodging the question because my question is "I am attempting to understand the philosophy behind Technology XYZ, by attacking this problem it's famous for being good at, but which it is being frustratingly bad at" |
05:27 | <&McMartin> | The answer "actually, don't use technology XYZ" dodges that design question. |
05:28 | <&McMartin> | I'm not suffering from a dire lack of BASIC parser here. I'm suffering from insufficient command of pattern-matching/ADT design sense. |
05:29 | <@Pi> | Well… your question was "how would you handle something like this?", and my answer to that is certainly parser combinators. |
05:30 | <@Pi> | Parser combinators are how you would construct said pattern matching and translation to your ADTs, in a way that's hopefully simpler and less repetitive? |
05:30 | <&McMartin> | Simpler, absolutely; less repetitive... well, I guess I'll see. |
05:31 | <&McMartin> | It's hard to beat the dynamic for less repetitive~ |
05:32 | <@Pi> | I'm not sure what you mean with "basic parsing"; combinators area certainly not limited to just simpler lexing, say. They're just as good for grammar and structure. |
05:32 | <&McMartin> | I mean parsing the language BASIC. |
05:33 | <@Pi> | Ah, oki! :) |
05:33 | <&McMartin> | (That particular code snipped being for a statement like OPEN 15,8,15,"N0:LABEL,1A") |
05:34 | <@Pi> | Well, I'm not sure how Rust's parser combinator libraries look, but my gut feel is that the sample you have above should be a one-liner. |
05:34 | <&McMartin> | Could be. |
05:35 | <&McMartin> | The one I'm seeing is called "nom" and it looks like it's not as mature as Parsec... |
05:35 | <&McMartin> | ... but some of that may be ugliness from macros + curry-hostile syntax. |
05:37 | <@Pi> | My most recent parser combinator use was in Python, parsing an unstructured token stream to namedtuples as a poor person's ADT, and that was full of dozen of one liners doing the equivalent of the above. |
05:39 | <&McMartin> | Yeah. |
05:39 | <@Pi> | All of them with the pattern to match as a parser combinator on the left, and the ADT constructor to invoke on the right. |
05:39 | <&McMartin> | The Scheme code I'm adapting from just had this as one entry in a parse table. |
05:39 | <@Pi> | Without manually unpacking and repacking stuff all the time. |
05:40 | <&McMartin> | (arglist-stmt '(open) 'open "OPEN" 2 4) |
05:41 | <&McMartin> | This .ini file parser looks a lot less one-liney than I'd like. https://github.com/Geal/nom/blob/master/tests/ini.rs |
05:43 | <&McMartin> | I think that does move it out of the "useful exercise" area for me, though. |
06:07 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
06:10 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
07:23 | | himi [sjjf@Nightstar-dm0.2ni.203.150.IP] has quit [Ping timeout: 121 seconds] |
07:36 | | Kindamoody[zZz] is now known as Kindamoody |
08:19 | <&McMartin> | lol: http://csdb.dk/release/?id=156798 |
08:38 | <@abudhabi> | Hahahaha. |
09:15 | <@gnolam> | Heh |
09:50 | | Kindamoody is now known as Kindamoody|afk |
10:06 | < sshine> | <JX7P:#proglangdesign> unrelated, but I had a weird dream last night and it involved algorithm w |
10:21 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has joined #code |
10:21 | | mode/#code [+o himi] by ChanServ |
11:50 | | You're now known as TheWatcher[d00m] |
12:51 | | You're now known as TheWatcher |
13:16 | | Vornotron is now known as Vornicus |
13:16 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
13:20 | | RXP [rjvotqfx@Nightstar-h4gf20.internetdsl.tpnet.pl] has joined #code |
13:21 | | RXP [rjvotqfx@Nightstar-h4gf20.internetdsl.tpnet.pl] has quit [G-Lined: naughty spammer! (ID: AKXDMB1X29)] |
13:50 | | celticminstrel [celticminst@Nightstar-jb792f.dsl.bell.ca] has joined #code |
13:50 | | mode/#code [+o celticminstrel] by ChanServ |
13:52 | | celticminstrel [celticminst@Nightstar-jb792f.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
21:24 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has quit [[NS] Quit: bbl] |
21:39 | | Alek [Alek@Nightstar-7or629.il.comcast.net] has joined #code |
21:39 | | mode/#code [+o Alek] by ChanServ |
21:49 | | Vorntastic [Vorn@Nightstar-retbrs.sub-174-199-22.myvzw.com] has joined #code |
22:13 | | Kindamoody|afk is now known as Kindamoody |
22:42 | | Kindamoody is now known as Kindamoody[zZz] |
23:58 | | Vorntastic [Vorn@Nightstar-retbrs.sub-174-199-22.myvzw.com] has quit [[NS] Quit: Bye] |
--- Log closed Sat Jun 17 00:00:15 2017 |