Hi, Il 07/11/19 19:32, Benoit ha scritto: > But it seems strange to specify that an operator of signature "scalar x > vector -> vector" is either left- or right-associative. Since vector is > not a subtype of scalar, I should not have to specify that, and "a . b . > s" can only be read as "a . ( b . s )". If I had typed "infix . lassoc > precedence=2;" above, would this have triggered an error? (Another > example is inner products, since "scalar" is not a subtype of > "vector".) Or would this require a too complex parser?
I think that in general it is assumed that parsing is done before type checking, so you cannot use type information to choose between different parses. If you decide to mix the two phases everything becomes much more complex, which is probably not a good idea in MM0. In C and C++, instead, this happens: in the line a * b; you cannot say whether * is a multiplication or a pointer declaration unless you know if a is a type or a variable. This notoriously requires C and C++ parser to be quite complex. In C++, in some circumstances, you have to explicitly specify that a name is a type with the keyword "typename" when the parser is not able to infer it (typically when dealing with templates and names depending on a template, because it is not possible to know whether a name depending on a template is a variable or a type until the template is instantiated; but this happens after parsing, and it might happens none or many times, so the parser cannot rely on it, and the programmer has to be explicit). In you example, you definitely want "." to be right associative, so that a . b . s = a . (b . s) as you say. You also want * to be higher precedence, because you probably want a * b . s = (a * b) . s. As for the associativity of *, it is probably not very important, because * is a field product, therefore associative. I'd say that in this case the more predictable thing is to make it left associative. So, in the end, I would declare infixr . prec = 1 infixl * prec = 2 As I said, I don't think that relying on types would be a good idea, unless you really like complicating your life with parsers (I don't: the only programming language I have designed so far, called "G", uses RPN to avoid parsing expressions, and in some sense this is one of its selling points), or if you have strong reasons for doing it because you want to support some other strange construct. HTH, Giovanni. -- Giovanni Mascellani <[email protected]> Postdoc researcher - Université Libre de Bruxelles -- You received this message because you are subscribed to the Google Groups "Metamath" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/metamath/7ef2a968-59d0-a57a-6f61-ac0a580699fe%40gmail.com.
signature.asc
Description: OpenPGP digital signature
