FEEL Grammar: How to refer to context entries specified by a string literal grammar rule? - grammar

A context entry & key are defined by the following grammar (cf DMN v1.2, page 111, Section 10.3.1.2)
60. context entry = key , ":", expression;
61. key = name | string literal;
Consider the following instance of a context object
{ "12" : "hello" }
How do I access "hello" from such an object?
Could this be an issue in the grammar? Not sure if this kind of accession is valid.

Accordingly to DMN specification, as "12" cannot be transformed into a legal name I concur with you, cannot be accessed with the dot operator.
But you can use the built-in function get value() as for the spec:
If key1 is not a legal name or for whatever reason one wishes to treat
the key as a string, the following syntax is allowed: get value(m,
"key1").
For example:
get value({ "12" : "hello" }, "12")
this is valid FEEL and would result in "hello".
I see no issue in the grammar.
I believe the only way to access this entry value is by using the built-in function.

Related

What happens under the hood when we define a type alias with a type variable in Elm

Suppose we define a type alias say Message as:
type alias Message a =
{ code : String
, body : a
}
And later define a function readMessage as:
readMessage : Message () -> String
readMessage message =
...
The above example is from Elm tutorial and book says:
This function takes Message with an empty body. This is not the same
as any value, just an empty one.
Can someone please elaborate what exactly happens in above scenario and how compiler handles it.
Unless you really want to see the internal compiler representation of that, I think what's important here is the difference between any value and empty value.
Message a is a parametrized type with 1 parameter. You can read it as a template, e.g. wherever lowercase a appears in the definition of the Message it will be substituted with the concrete type (String, Int, etc).
So this is how function should look like if we want it to take a Message with String body:
readMessage : Message String -> String
readMessage message =
What happens here is that the type of body field is no longer an a but a String (a is substituted with String):
{ code : String
, body : String
}
The value of nothing (aka void or unit) in Elm is encoded as (). That's why a Message with empty body value looks like this:
{ code : String
, body : ()
}
But when we simply don't care about the body value we can just take a Message with any value:
readMessage : Message a -> String
readMessage message =
The lowercase a can be any lowercase string, we can make it more readable like this:
readMessage : Message any -> String
readMessage message =
But then we cannot really read message body, because we don't know the type of it (so we don't know how to read it).
Hope that helps.
The type Message () is an alias for the following record:
{ code : String
, body : ()
}
where the () type denotes a tuple without any items (also known as null tuple). There is only one value of such type and it is also written ().
Now, when we want to omit some field in a record, we cannot just not specify it – that would make the compiler rightly mad, see also The Billion Dollar Mistake. We need to tell the compiler that the value can be omitted.
One way we could do it is to use the Maybe type but if we made a list of messages that would allow us to include the body in some messages and omit it in others. This might not be what we want.
The alternative is to parametrize the Message type as you are doing in the question. This will allow us to have a messages with String bodies when reading the message, and with a different body type when we are not interested in the body.
In this case, we need to consider what the body type should be. While we could use an empty Strings for messages with omitted bodies, they would be easily confused with messages with empty bodies. We could also use Bool but then we would need to decide if we want to use True or False for the omitted value. Finally, we can use the null tuple; since it only has one possible value it is ideal for us.
There is actually one more possibility: we could create a type alias MessageWithoutBody = { code: String }. This is cleaner in some cases (especially when you need to omit more fields) but can be more verbose as you need to duplicate all the fields you want to keep.

Position of `#` label in Kotlin when denoting receiver with `this`

I am a newbie in Kotlin. I am curious about the difference of labeled this in Kotlin with prefix # or postfix #.
I have just seen a code which writes SignInActivity#this, which seems to work exactly same as this#SignInActivity.
Are these two exactly the same thing? If not, what is the difference between the two?
I was trying to do some research on *#this form, but I couldn't find any reference on it. All I could find was this official doc which demonstrates this#*. It will be nice if anybody could share me with the correct reference I should go to.
SignInActivity# this is just another expression for this, with the functionality of defining an unnecessary label called SignInActivity(which has nothing to do with actual class name) for this.
According to Kotlin grammar documentation:
labelReference (used by atomicExpression, jump)
: "#" ++ LabelName
;
labelDefinition (used by prefixUnaryOperation, annotatedLambda)
: LabelName ++ "#"
;
hello# is just a label with the name "hello" (for Returns and Jumps) ,
whereas #hello is a reference for the labeled loop or block.
These expressions combined can be used as below:
loop# for (i in 1..100) {
for (j in 1..100) {
if (...) break#loop //jump to loop#
}
}
SignInActivity#this means SignInActivity.this (Java)
this#SignInActivity means - using the SignInActivity context instead a local context (usually is in closures).

Smalltalk - Is it possible to add a string to a String instance via a method?

Smalltalk - Is it possible to add a string to a String instance via a method?
Essentially I'd like something along the lines of:
renderThisOn: aString
aString append: 'whatever text I want'
Essentially I'd like a String instance (ByteString, etc) to behave like the "html" object in Seaside. I pass it on as an argument to multiple methods, each adding some information to it.
From a practical viewpoint the answer would be no, it is not possible to change the size of a String. You can modify the characters of the String though:
a := 'abc'.
a at: 2 put: $x.
a = 'axc' "true"
Therefore, when you concatenate two strings you get a third one, while the others two remain unchanged
s := 'abc'.
t := 'def'.
u := s , t.
s = 'abc'. "true"
t = 'def'. "true"
Having said this, there is actually a way to do grow (or shrink) a String. The idea is to use become: (or becomeForward:). This message will replace all references to the receiver with references to the argument. In your case:
s := 'abc'.
t := 'def'.
assoc := s -> 3 "referene to s"
s become: s , t.
s = 'abcdef'. "true"
assoc key == s "true"
The reason why I started my answer by saying that you cannot change the string's size is because in the vast majority of cases the use of become: is overkilling and the recommended practice is to review the code and eliminate the need for modifying the structure of an object.
String literals in Smalltalk are immutable objects.
It is possible different ways:
Pass instance of WriteStream
renderThisOn: aWriteStream
aWriteStream nextPutAll: 'whatever text I want'
You can create own class wrapper around String and pass its instance:
renderThisOn: aStringWrapper
aStringWrapper append: 'whatever text I want'
Streams are more preferable, because streams are faster than string concatenation
comma method:
|a|
a := 'abc'.
a,'def'
ctrl+p and get 'abcdef'
Depending on how you want to use it, a string holder can achieve what you need. The simplest might be to pass an array with the first and only element being the string you want to alter in different methods. The array won't change but the one and only element will change as you place different strings there. More complex would be to create a specialised string holder class, with a field that holds the string which changes. You can then implement the common string methods on that holder, to redirect to the current actual string.

NullPointerException with ANTLR text attribute

I have a problem that I've been stuck on for a while and I would appreciate some help if possible.
I have a few rules in an ANTLR tree grammar:
block
: compoundstatement
| ^(VAR declarations) compoundstatement
;
declarations
: (^(t=type idlist))+
;
idlist
: IDENTIFIER+
;
type
: REAL
| i=INTEGER
;
I have written a Java class VarTable that I will insert all of my variables into as they are declared at the beginning of my source file. The table will also hold their variable types (ie real or integer). I'll also be able to use this variable table to check for undeclared variables or duplicate declarations etc.
So basically I want to be able to send the variable type down from the 'declarations' rule to the 'idlist' rule and then loop through every identifier in the idlist rule, adding them to my variable table one by one.
The major problem I'm getting is that I get a NullPointerException when I try and access the 'text' attribute if the $t variable in the 'declarations' rule (This is one one which refers to the type).
And yet if I try and access the 'text' attribute of the $i variable in the 'type' rule, there's no problem.
I have looked at the place in the Java file where the NullPointerException is being generated and it still makes no sense to me.
Is it a problem with the fact that there could be multiple types because the rule is
(^(typeidlist))+
??
I have the same issue when I get down to the idlist rule, becasue I'm unsure how I can write an action that will allow me to loop through all of the IDENTIFIER Tokens found.
Grateful for any help or comments.
Cheers
You can't reference the attributes from production rules like you tried inside tree grammars, only in parser (or combined) grammars (they're different objects!). Note that INTEGER is not a production rule, just a "simple" token (terminal). That's why you can invoke its .text attribute.
So, if you want to get a hold the text of the type rule in your tree grammar and print it in your declarations rule, your could do something like this:
tree grammar T;
...
declarations
: (^(t=type idlist {System.out.println($t.returnValue);}))+
;
...
type returns [String returnValue]
: i=INTEGER {returnValue = "[" + $i.text + "]";}
;
...
But if you really want to do it without specifying a return object, you could do something like this:
declarations
: (^(t=type idlist {System.out.println($t.start.getText());}))+
;
Note that type returns an instance of a TreeRuleReturnScope which has an attribute called start which in its turn is a CommonTree instance. You could then call getText() on that CommonTree instance.

Can WCF accept JSON encoded using single quotes and non-quoted identifiers?

Is there a way that I can instruct WCF to accept JSON that is formatted using either single quotes (as opposed to double quotes):
{
'foo': 'bar'
}
Or using non-quoted identifiers like so:
{
foo: 'bar'
}
As it is, it seems like JSON will only be accepted if it is formatted like so:
{
"foo": "bar"
}
Using either of the first two example results in a 400 (bad request).
The first two examples are invalid JSON texts.
http://www.ietf.org/rfc/rfc4627.txt
object = begin-object [ member *( value-separator member ) ]
end-object
member = string name-separator value
string = quotation-mark *char quotation-mark
quotation-mark = %x22 ; "
DataContractJsonSerializer always writes strict JSON.
At various points during deserialization (generally missing end tags for arrays or objects, or improper escaping, or improperly formatted numbers), it will accept incorrect, non-strict JSON.
However, I can tell you definitively that this is not one of those cases. DataContractJsonSerializer always requires double-quoted strings for JSON.
Hope this helps!