I'm studying attribute grammar, and when I talk about the semantic rule of each syntax rule, the words actual value and expected value come up. But I don't know in what situation to use actual or expected.
For example, when there is a creation rule like
<assign> → <id> = <expr>
<id> → A|B|C
<expr> → <id> + <expr> | <id> * <expr> |( <expr>)| <id>
syntax rule: <assign> → <id> = <expr>
semantic rule: <expr>.expected_type ← <id>.actual_type
syntax rule: <expr> → <id>
semantic rule: <expr>.actual_type ← <id>.actual_type
At first, I thought it was actual_value if it was on the left side of the production rule, and expected_value if it was on the right side, but it was confirmed that this is different for each production rule. What exactly are actual_value and expected_value and when to use each
They are just names.
When you write an attribute grammar, you need to give the attributes names, just like when you write a program, you need to give your variables names.
So whoever wrote that grammar thought that those particular identifiers would make sense to whoever was reading the code.
In fact, that is rarely the case, which is why it's important to comment your code. Whoever wrote that grammar should have done that.
Anyway, we can guess what they meant (although I'm not convinced that it's the best solution). The actual_type of an expression is presumably the type of the value produced by that expression. So if the expression is an id, the type of the expression is precisely the declared type of the variable that id represents. (More interesting would be to see how they set the actual type of an expression which requires conversions, like 2 + 3.5.)
If variables have declared types, then an assignment to a variable might involve a conversion. (For example, if x has a floating point type and i has an integer type, x = i + 2 requires the compiler to issue an instruction which changes the integer value computed from i+2 into a floating point value.) Whoever wrote that attribute grammar thought it would make sense to record the required conversion as the expected_type of the expression; in other words, the type of the value which the assignment needs.
Related
I have a grammar where I recently added syntax for a constant OSC address --- it looks like this
OSCAddressConstant: ('/' ('A' .. 'Z' | 'a' .. 'z' | '0' .. '9' | '_')+)+;
Typical examples might be
/a/b/c
/Handle/SetValue
/1/Volume/Page3
Unfortunately, I discovered rather quickly that simple expressions with division: e.g.
foo = 20/10
now fail with type errors because the parser thinks that the /10 is an OSC address and so we get "integer" "Divide" "OSCAddressConstant"
What is the recommended (and hopefully) simplest way to disambiguate these other than changing the actual syntax of the OSC address, which would be a pity.
Thanks in advance
(NB - I saw a similar question about ambiguity between division and regular expression syntax but I did not understand the solution - there was a reference to the use of #member but it was unclear what to do with it - I've not seen that before and other questions about #member seem to have gone unanswered)
That OSCAddressConstant rule is rather a higher level rule, like a complex identifier, possibly qualified. Such higher level constructs should go into the parser, not the lexer.
Just like you would define a qualified identifier as:
ID: [a-zA-Z][a-zA-Z0-9]*;
DOT: '.';
qualified: ID (DOT ID)?;
you can define your OSC address as:
EID: [a-zA-Z0-9_]+;
DIV: '/';
oscAddressConstant: (DIV EID)+;
The only drawback with this approach is: when you usually ignore whitespaces this syntax will allow constructs like: / abc / 12. But if that's something you do not want handle whitespaces in the semantic phase and throw an error then.
Are there definite rules regarding naming of entities in Haskell? (by entities I mean functions, term level variables, data constructors, type variables, type constructors, typeclasses, modules; not sure if I left something out here) For example
<interactive>:1:13: error:
Not in scope: type constructor or class ‘Zed’
Perhaps you meant type variable ‘zed’ (line 1)
I know that in type signatures concrete types must be uppercase. So is it assuming that Zed is a concrete type, and because this type isn't defined (isn't in scope), we get an error?
Are there any other actual rules on naming stuff in Haskell?
As was pointed out by M. Aroosi in a comment, your errors don't match your example – you seem to have written f :: zed -> Zed : f = undefined instead, with a : instead of a ;. If you use a ; you will get one of two results. If Zed is undefined, you'll get an error telling you so:
Prelude> f :: zed -> Zed ; f = undefined
<interactive>:2:13: error:
Not in scope: type constructor or class ‘Zed’
Perhaps you meant type variable ‘zed’ (line 2)
If Zed is defined, everything will work:
Prelude> data Zed = TheZed
Prelude> f :: zed -> Zed ; f = undefined
Prelude>
The general rule for Haskell names is:
At the type level:
Type names start with an uppercase letter.
Type variables start with a lowercase letter.
At the term level:
Constructor names start with an uppercase letter if they're ordinary names.
Constructor infix operators start with a :.
Variable names start with a lowercase letter if they're ordinary names.
Variable infix operators start with anything but a :.
There are some further wrinkles (e.g., you can't use , in names; you can't have a name that's only -s and 2 or more character long), but that covers 95% of it.
You are using the REPL (Ghci). If you try to use a type signature in the REPL, you need to use :{ .....\n ..... \n ..... :} kind of multiline input. Then you can do the type signature of the function along with implementation(s) of that type signature. Its not very practical - 1 typo and you have to do it all over again. (Julia language REPL does a much better job with that, btw.).
And yes, there are style guides and types need to start with an uppercase. Usually the compiler warns/errors you.
Since you seem to start out, I suggest you use a source file for your experiments because as soon as you end up with multiple line constructs, the REPL kind of sucks. And it is really easy to use a file for your code. See :load :cd :reload etc. for your GHCI commands which support you doing that.
I came across this error message in another question and I would like to know what is the meaning of the $: part of the signature, please?
Cannot resolve caller index(Str: Str, Any); none of these signatures match:
(Str:D $: Cool:D $needle, *%_)
(Str:D $: Str:D $needle, *%_)
(Str:D $: Cool:D $needle, Cool:D $pos, *%_)
(Str:D $: Str:D $needle, Int:D $pos, *%_)
The $: is two distinct unrelated tokens, a $ and a :, that have been smooshed together.
The $ represents a single item1 aka a scalar2.
The single item / scalar hasn't been given a name, so there's no way to reference it. And there's already enough of a parameter (the Str:D) to let you and the compiler know that this parameter is a scalar (a single string). Either way, the $ is redundant and Elizabeth has made a related change.
The : is a special parameter separator. (The usual parameter separator is a comma ,.)
It may only be used immediately after the first parameter of a method or standalone signature. It may not be used in the signature of a routine that is not a method.
If used as a parameter separator after the first parameter in a signature, it marks that parameter as corresponding to a method's "invocant".
(If not used, the invocant parameter is implicit.)
The corresponding invocant argument will arrive anyway, and be aliased to self, whether or not the signature explicitly lists an invocant parameter. But if the invocant parameter is explicitly specified, it's possible to give it an additional/alternate name and/or explicitly constrain its type.
Crazy over-the-top footnotes for added entertainment. If they confuse you, just forget you ever read them.
1 A single item refers to data that is naturally a single thing, like the number 42, OR data that is naturally a composite thing (like an array) that is being treated like it's a single thing (like an array). (Did you see what I did there?) I like to point out the mnemonic that a $ symbol is like an S (for single) overlaid with an I (for item), or vice-versa. To me this represents the idea of emphasizing the single item nature of any data, hiding any plural aspect even if it's actually an array or other composite data item.
2 "scalar" is a traditional computing term. Wikipedia's Scalar disambiguation page lists "Variable (computing), or scalar, an atomic quantity that can hold only one value at a time" as a definition. Also, a single item aka scalar (all lowercase) is often/usually a Scalar (uppercase S), a special case of a single item that's a Single Item container that contains a Single Item (which can be composite data being treated as a single thing).
The : mark the first argument as an invocant.
my $word = "bananarama";
say $word.index( "r", 0 );
In this case, it indicates the invocant is going to be treated as an scalar, since it's constrained by a single $
I'm trying to make a Haskell datatype a bit like a python dictionary, a ruby hash or a javascript object, in which a string is linked to a value, like so:
data Entry t = Entry String t
type Dictionary t = [Entry t]
The above code works fine. However, I would like a slightly nicer constructor, so I tried defining it like this:
data Entry t = String ~> t
This failed. I tried this:
data Entry t = [Char] ~> t
Again, it failed. I know that ~ has special meaning in Haskell, and GHCi still permits the operator ~>, but I still tried one other way:
data Entry t = [Char] & t
And yet another failure due to parse error. I find this confusing because, for some inexplicable reason, this works:
data Entry t = String :> t
Does this mean that there are certain rules for what characters may occur in infix type constructors, or is it a cast of misinterpretation. I'm not a newbie in Haskell, and I'm aware that it would be more idiomatic to use the first constructor, but this one's stumping me, and it seems to be an important part of Haskell that I'm missing.
Any operator that starts with a colon : is a type constructor or a data constructor, with the exception of (->). If you want the tilde, you could use :~>, but you're not going to get away with using something that doesn't start with a colon. Source
How can i use AND operation on jape grammar?. I just want to check whether a sentence contain 'organisation','jobtitle','person' all together in any order. How it possible? There is '|'(OR) operation allowed but i didnt see any documentation about AND operation.
There isn't an "and" operator like that as such but you could do it with a set of contains checks:
Rule: OrgTitlePer
({Sentence contains {Organization},
Sentence contains {JobTitle},
Sentence contains {Person}}):sent
-->
:sent.Interesting = {}
When you have several constraints within the same set of braces that involve the same annotation type on the left (Sentence in this case) then all the constraints must be satisfied simultaneously by the same annotation.