I am having trouble finding out whether Closure supports JSDoc array syntax such as string[].
I don't see it documented on https://github.com/google/closure-compiler/wiki/Types-in-the-Closure-Type-System#user-content-the-javascript-type-language . However, JSDoc supports it, and it has been around a while, so I'm surprised Closure wouldn't support it also.
(JSdoc implies it is not supported in Closure per https://jsdoc.app/tags-type.html , and mentions this in its catharsis type parser: https://github.com/hegemonic/catharsis , but I didn't know if this could be outdated info.)
If it is supported, I'd also like to know whether the optional = can be added immediately after it (without surrounding the previous expression in parentheses).
(As a bonus, I'd like to know whether the Record Type can have optional keys in Closure as through {key?: number}.)
JSDocs and Closure Compiler have their differences. Use the Closure documentation for details.
The type of an array of strings in closure is Array<string>.
Related
SELECT xText.query (' let $planes := /planes/plane
return <results>
{
for $x in $planes
where $x/year >= 1970
order by ($x/year)[1]
return ($x/make, $x/model,$x/year )
}
</results>
')
FROM planes
In this code, what is the purpose of [1] in line order by ($x/year)[1]
I have tried to execute this code without using [1] behind order by clause. Then this error has occurred.
XQuery [planes.xtext.query()]: 'order by' requires a singleton (or empty sequence), found operand of type 'xtd:untypedAtomic*'
XQuery 1.0 defined an option called "static type checking": if this option is in force, you need to write queries in such a way that the compiler can tell in advance ("statically") that the result will not be a type error. The operand of "order by" needs to be a singleton, and with static type checking in force, the compiler needs to be able to verify that it will be a singleton, which is why the [1] has been added. It would have been better to write exactly-one($x/year) because this doesn't only keep the compiler happy, it also demands a run-time check that $x/year is actually a singleton.
Very few XQuery vendors chose to implement static type checking, for very good reasons in my view: it makes queries harder to write, and it actually encourages you to write things like this example that do LESS checking than a system without this "feature".
In fact, as far as I know the only mainstream (non-academic) implementation that does static type checking is Microsoft's SQL Server.
Static type checking should not be confused with optimistic type checking where the compiler tells you about things that are bound to fail, but defers checking until run-time for things that might or might not be correct.
Actually the above is a bit of a guess. It's also possible that some <plane> elements have more than one child called <year>, and that you want to sort on the first of these. That would justify the [1] even on products that don't do static type checking.
The [1] is a predicate that is selecting the first item in the sequence. It is equivalent to the expression [position() = 1]. A predicate in XPath acts kind of like a WHERE clause in SQL. The filter is applied, and anything that returns true is selected, the things that return false are not.
When you don't apply the predicate, you get the error. That error is saying that the order by expects a single item, or nothing (an empty sequence).
At least one of the plane has multiple year, so the predicate ensures that only the first one is used for the order by expression.
From the examples given for the THE function (http://clhs.lisp.se/Body/s_the.htm) when i change the following form
(the (values integer float) (truncate 3.2 2))
to
(the (values integer integer) (truncate 3.2 2))
I still don't get any compiler warnings, whereas (the integer 1.2) gives
;Compiler warnings :
; In an anonymous lambda form at position 0: Type declarations violated in (THE INTEGER 1.2)
Can some one explain why the above doesn't produce warnings? I test these on CCL.
You have misunderstood what the does. The specification tells you in so many words:
the specifies that the values returned by form are of the types specified by value-type. The consequences are undefined if any result is not of the declared type.
(My emphasis.)
In other words, what the does is to allow you to say to the compiler 'I undertake that these things have these types and you may compile appropriate code for that, with no checks needed; if that's not true then I fully accept that you may need to set my hair on fire and gouge out my one remaining eye'.
Now, famously, CMUCL and its derivatives such as SBCL take a rather different approach to type checking. From the SBCL manual:
The SBCL compiler treats type declarations differently from most other Lisp compilers. Under default compilation policy the compiler doesn’t blindly believe type declarations, but considers them assertions about the program that should be checked: all type declarations that have not been proven to always hold are asserted at runtime.
Thus the system treats the as an assertion about types which, if it is not already known to be true, must be checked. This is, I think, conformant, since 'unspecified consequences' can obviously include 'raising an exception in a nice way' (personally I prefer eye-gouging compilers but that's just me).
But if you want to write portable code, you should not assume that the does this. Rather you need either to accept the risks that it does not, or use some form like check-type or assert with a type check as the thing you are asserting.
With the following snippet I cannot retrieve gString from a map:
def contents = "contents"
def gString = "$contents"
def map = [(gString): true]
assert map.size() == 1 // Passes
assert gString.hashCode() == map.keySet().first().hashCode() // Passes, same hash code
assert map[gString] // Fails
How on earth is that possible?
Assertion message clearly shows that there's something seriously wrong with Groovy:
assert map[gString] // Fails
| ||
| |contents
| null
[contents:true]
It's not the same question as Why groovy does not see some values in dictionary?
First answer there suggests:
You're adding GString instances as keys in your map, then searching for them using String instances.
In this question I clearly add GString and try to retrieve GString.
Also neither Why are there different behaviors for the ways of addressing GString keys in maps? nor Groovy different results on using equals() and == on a GStringImpl have an answer for me. I do not mutate anything and I do not mix String with GString.
tl;dr: You seem to have discovered a bug in Groovy's runtime argument overloading evaluation.
Answer:
map[gString] is evaluated as map.getAt(gString) at runtime straightforwardly via Groovy's operator overloading mechanism. So far, so good, but now is where everything starts to go awry. The Java LinkedHashMap class does not have a getAt method anywhere in it's type hierarchy, so Groovy must use dynamically associated mixin methods instead (Actually that statement is sort of reversed. Groovy uses mixin methods before using the declared methods in the class hierarchy.)
So, to make a long story short, Groovy resolves map.getAt(gString) to use the category method DefaultGroovyMethods.getAt(). Easy-peasy, right? Except that this method has a large number of different argument overloads, several of which might apply, especially when you take Groovy's default argument coercion into account.
Unfortunately, instead of choosing DefaultGroovyMethods.getAt(Map<K,V>,K), which would seem to be a perfect match, Groovy chooses DefaultGroovyMethods.getAt(Object,String), which coerces the GString key argument into a String. Since the actual key is in fact a GString, the method ultimately fails to find the value.
To me the real killer is that if the argument overload resolution is performed directly from code (instead of after the operator resolution and the category method selection), then Groovy makes the right overload choice! That is to say, if you replace this expression:
map[gString]
with this expression:
DefaultGroovyMethods.getAt(map,gString)
then the argument overloading is resolved correctly, and the correct value is found and returned.
There's nothing wrong with Groovy. A GString is not a String. It is mutable and as such should never be used as a key in a map (like any other mutable object in Java).
Learn more about this in the docs: http://docs.groovy-lang.org/latest/html/documentation/index.html#_gstring_and_string_hashcodes
With the following snippet I cannot retrieve gString from a map:
def contents = "contents"
def gString = "$contents"
def map = [(gString): true]
assert map.size() == 1 // Passes
assert gString.hashCode() == map.keySet().first().hashCode() // Passes, same hash code
assert gString.is(map.keySet().first()) // Passes, exactly the same object
assert map[gString] // Fails
How is that possible?
What's interesting here is that map.get(map.keySet()[0]) works fine while map.get[map.keySet()[0]] does not.
Assertion message clearly shows that there's something wrong:
assert map[gString] // Fails
| ||
| |contents
| null
[contents:true]
It's not the same question as Why groovy does not see some values in dictionary?
First answer there suggests:
You're adding GString instances as keys in your map, then searching for them using String instances.
In this question I clearly add GString and try to retrieve GString.
Also neither Why are there different behaviors for the ways of addressing GString keys in maps? nor Groovy different results on using equals() and == on a GStringImpl have an answer for me. I do not mutate anything and I do not mix String with GString. Groovy documentation is not helpful as well.
tl;dr: You seem to have discovered a bug in Groovy's runtime argument overloading evaluation.
Answer:
map[gString] is evaluated as map.getAt(gString) at runtime straightforwardly via Groovy's operator overloading mechanism. So far, so good, but now is where everything starts to go awry. The Java LinkedHashMap class does not have a getAt method anywhere in it's type hierarchy, so Groovy must use dynamically associated mixin methods instead (Actually that statement is sort of reversed. Groovy uses mixin methods before using the declared methods in the class hierarchy.)
So, to make a long story short, Groovy resolves map.getAt(gString) to use the category method DefaultGroovyMethods.getAt(). Easy-peasy, right? Except that this method has a large number of different argument overloads, several of which might apply, especially when you take Groovy's default argument coercion into account.
Unfortunately, instead of choosing DefaultGroovyMethods.getAt(Map<K,V>,K), which would seem to be a perfect match, Groovy chooses DefaultGroovyMethods.getAt(Object,String), which coerces the GString key argument into a String. Since the actual key is in fact a GString, the method ultimately fails to find the value.
To me the real killer is that if the argument overload resolution is performed directly from code (instead of after the operator resolution and the category method selection), then Groovy makes the right overload choice! That is to say, if you replace this expression:
map[gString]
with this expression:
DefaultGroovyMethods.getAt(map,gString)
then the argument overloading is resolved correctly, and the correct value is found and returned.
Support for generics (currently only Vector.<*>, and called 'postfix type parameters' by Adobe) was added in Flash Player 10, but the only AVM2 documentation does not describe how these objects are accessed.
Specifically, I noticed a new opcode (0x53) and a new multiname kind (0x1D) that seem relevant, but their usage is not documented.
NB: This question was created with the answer already known as it is more easily found here than on my blog or the Adobe Bug DB.
The reverse engineering work I did on this did not include declaring your own generic types, though it's very likely possible.
References to the declaring (parameterless) generic type (Vector) are made through a regular qualified name (though any multiname should do).
References to a typed generic type (Vector.<int> as opposed to Vector.<>) are made by a new multiname kind (0x1D), which I call GenericName. GenericName has a format like so:
[Kind] [TypeDefinition] [ParamCount] [Param1] [Param2] [ParamN]
Where:
[TypeDefinition] is a U30 into the multiname table
[ParamCount] is a U8 (U30?) of how many type parameters there are
[ParamX] is a U30 into the multiname table.
Obviously generics are not generally supported yet, so ParamCount will always be 1 (for Vector.<*>).
The other interesting thing is how instances of the class are created. A new opcode was added in Flash 10 (0x53), which I will call MakeGenericType. MakeGenericType is declared with the following stack:
TypeDefinition, ParameterType1, ParameterTypeN -> GenericType
It also has one parameter, a U8 (U30?) specifying how many parameters are on the stack. You will generally see MakeGenericType being used like this:
GetLex [TypeDefinitionMultiname]
GetLex [ParameterTypeMultiname]
MakeGeneric [ParamCount]
Coerce [GenericNameMultiname]
Construct [ConstructorParamCount]
So if you had the following...
GetLex __AS3__.vec::Vector
GetLex int
MakeGeneric 1
Coerce __AS3__.vec::Vector.<int>
Construct 0
You would now have an instance of Vector.<int>