Newest at the top
| 2024-05-13 15:56:54 +0200 | dezalator | (~dezalator@77-254-94-95.dynamic.inetia.pl) (Remote host closed the connection) |
| 2024-05-13 15:54:51 +0200 | dezalator | (~dezalator@77-254-94-95.dynamic.inetia.pl) |
| 2024-05-13 15:54:22 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2024-05-13 15:52:49 +0200 | dezaaltor | (~dezaaltor@77-254-94-95.dynamic.inetia.pl) (Remote host closed the connection) |
| 2024-05-13 15:52:34 +0200 | syscall1 | (~syscall@2401:4900:16a3:3e97:3b3e:7956:62a8:2bba) (Client Quit) |
| 2024-05-13 15:52:31 +0200 | dezaaltor | (~dezaaltor@77-254-94-95.dynamic.inetia.pl) |
| 2024-05-13 15:51:11 +0200 | <ski> | (there are papers about doing this, for intuitionistic, resp. linear (rather than ordered) logic, in order to capture "island constraints" in "coordination" in natural language) |
| 2024-05-13 15:50:52 +0200 | syscall1 | (~syscall@2401:4900:16a3:3e97:3b3e:7956:62a8:2bba) |
| 2024-05-13 15:50:42 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-05-13 15:50:36 +0200 | <tomsmeding> | even though realistically a parser will have to do something like that |
| 2024-05-13 15:50:32 +0200 | <ski> | mauke : anyway, another way to do it in a grammar, is to use Definite Clause Grammar, with ordered logic, using implicational grammar categories |
| 2024-05-13 15:50:23 +0200 | <tomsmeding> | I don't think about this as "parse a token sequence for f, then reinterpret that token sequence using the infixr statement found later" |
| 2024-05-13 15:49:56 +0200 | <tomsmeding> | define an operator (*) with level 6, right-associative; then parse f as usual |
| 2024-05-13 15:49:26 +0200 | euleritian | (~euleritia@dynamic-176-003-078-122.176.3.pool.telefonica.de) |
| 2024-05-13 15:48:53 +0200 | <lambdabot> | 3 |
| 2024-05-13 15:48:52 +0200 | <ski> | > let f x y z = x * y * z where (*) = (-); infixr 6 * in f 2 3 4 |
| 2024-05-13 15:48:49 +0200 | ystael | (~ystael@user/ystael) |
| 2024-05-13 15:48:43 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-05-13 15:46:56 +0200 | <tomsmeding> | my brain prefers to generate grammar rules at compile time, 'infix{,l,r}' statements being the way to do so |
| 2024-05-13 15:46:31 +0200 | <ski> | well, it's either that, or generating grammar rules at run-time, or something like that |
| 2024-05-13 15:46:12 +0200 | <tomsmeding> | baking the fact that it does into the syntax that the human needs to process fields weird to me |
| 2024-05-13 15:45:57 +0200 | <tomsmeding> | but as a human I prefer to pretend that it doesn't |
| 2024-05-13 15:45:47 +0200 | <tomsmeding> | I mean, GHC already does precedence and associativity in a later pass anyway |
| 2024-05-13 15:45:37 +0200 | <tomsmeding> | right |
| 2024-05-13 15:45:32 +0200 | <ski> | (then taking precedence and associativity into account in a later pass. or, if you prefer hardcoding that into the grammar, that should be doable) |
| 2024-05-13 15:45:27 +0200 | <tomsmeding> | :p |
| 2024-05-13 15:45:25 +0200 | <tomsmeding> | ski: that's a lexing grammar, not a parsing grammar |
| 2024-05-13 15:45:15 +0200 | <mauke> | can I get that in BNF? |
| 2024-05-13 15:45:08 +0200 | <tomsmeding> | or rather, if we are to generalise E beyond the current definition, which is an expression at precedence level as expected on the LHS of 'op' |
| 2024-05-13 15:44:49 +0200 | sandbag | (~syscall@user/sandbag) (Ping timeout: 268 seconds) |
| 2024-05-13 15:44:48 +0200 | <ski> | mauke : parenthesized sequence of atomic expressions, interleaved by operators, optional operator at start, and at end |
| 2024-05-13 15:44:28 +0200 | <tomsmeding> | my intuition would say that E should just be a top-level expression; this yields (2 + 3) * _ |
| 2024-05-13 15:44:09 +0200 | <tomsmeding> | what would the grammar for E be, indeed |
| 2024-05-13 15:43:54 +0200 | <mauke> | ski: how would you write that rule in a grammar? |
| 2024-05-13 15:43:48 +0200 | <tomsmeding> | there is -- this is special syntax for a section, which is (E op) |
| 2024-05-13 15:43:30 +0200 | <ski> | `*' binds tigher than `+', there's no reason, if allowing `(2 + 3 *)', to sidestep that |
| 2024-05-13 15:43:06 +0200 | <tomsmeding> | I think that's a good reason to require this to be explicitly written down how you want it to be |
| 2024-05-13 15:42:50 +0200 | <ski> | same precedence rules as usual, just the circumstances in which they can be applied has been extended (as opposed to interpreting it as `((2 + 3) *)', which would just be weird) |
| 2024-05-13 15:42:48 +0200 | <tomsmeding> | so our intuitions don't agree |
| 2024-05-13 15:42:41 +0200 | <tomsmeding> | I would personally expect the normal section behaviour to take precedence, i.e. my second option |
| 2024-05-13 15:41:59 +0200 | <ski> | "do the precedence rules take" -- yes, which would be the point |
| 2024-05-13 15:41:51 +0200 | <tomsmeding> | and does everyone agree on where it is |
| 2024-05-13 15:41:41 +0200 | <tomsmeding> | where in the precedence hierarchy is "taking a section"? |
| 2024-05-13 15:41:34 +0200 | <tomsmeding> | for (2 + 3 *), do the precedence rules take, well, precedence (yielding 2 + (3 * _)), or does the fact that it's a section take precedence (yielding (2 + 3) * _)? |
| 2024-05-13 15:41:33 +0200 | <ski> | (i have many times written `(f . g .)', only to have to change that to `((f . g) .)' alt. `(f .) . (g .)') |
| 2024-05-13 15:40:59 +0200 | <tomsmeding> | no, because that's a syntactically valid arithmetic expression where the normal precedence rules apply |
| 2024-05-13 15:40:39 +0200 | <ski> | it's as ambiguous as `2 + 3 * x' meaning either `(2 + 3) * x' or `2 + (3 * x)' |
| 2024-05-13 15:40:33 +0200 | <mauke> | proto is actually a 5-tuple |
| 2024-05-13 15:40:07 +0200 | <tomsmeding> | it's probably better disallowed |
| 2024-05-13 15:40:02 +0200 | <tomsmeding> | meh, it's ambiguous whether that would be (2 + 3) * _ or 2 + (3 * _) |