The dart docs list of operators includes >>>, it is also in the Dart 2.2 Language Spec. However, it's not included in the list of overridable operators, this answer from 2012 says that it doesn't (or didn't) exist, and dartpad rejects 3 >>> 1. Is this just a mistake in the docs, or does the operator do something I can't figure out?
Short answer: not yet (as of July 2019)
Here's the master tracking issue: https://github.com/dart-lang/sdk/issues/30886
Related
I've been using the picture string '#.##" in XSLT 1.0 code for many years to format numbers with decimals if they have a fractional part, and not displaying decimals if there is no fractional part.
Saxon 6.5.5.
format-number(123.456,'#.##’) 123.46
format-number(123.000,'#.##’) 123
But when using XSLT 2.0 or 3.0, I'm getting different behavior.
Saxon 9.9.1.5J
format-number(123.456,'#.##’) 123.46
format-number(123.000,'#.##’) 123.0
I haven't been able to figure out why the last case has the fractional part. https://www.w3.org/TR/xslt20/#dt-picture-string states:
The minimum-fractional-part-size is set to the number of
zero-digit-sign characters found in the fractional part of the
sub-picture.
https://www.w3.org/TR/xpath-functions-30/#syntax-of-picture-string states:
The minimum-fractional-part-size is set to the number of
decimal-digit-family characters found in the fractional part of the
sub-picture.
And with no zero-digit-sign and no decimal-digit-family characters, the fractional size should be zero, like it is in the XSLT 1.0 case.
Am I missing something?
Saxon is applying the rule:
If (after making the above adjustments) the minimum-integer-part-size
and the minimum-fractional-part-size are both zero, then the
minimum-fractional-part-size is set to 1 (one).
The XSLT 1.0 spec for format-number() was defined by reference to the JDK 1.1 specification, which was a bad mistake because (a) it was always grossly underspecified in the JDK, and (b) that version of the JDK specification is now almost impossible to get hold of. So we spent many happy hours writing a new spec from scratch that tried to reproduce the JDK spec in cases where it was clear and unbuggy, but filled in the gaps. We took into account the way that different XSLT 1.0 vendors had interpreted the spec, but didn't regard any existing implementations (or the JDK) as definitive.
Your test case is similar to test case numberformat228 at https://github.com/w3c/qt3tests/blob/master/fn/format-number.xml, and the notes for this test case refer to bug 29164. The bug entry at https://www.w3.org/Bugs/Public/show_bug.cgi?id=29164 reveals that the rule cited above was a fairly late addition/change to the spec (Sept 2015 - long after XPath 2.0).
The discussion in the bug entry suggests that the primary consideration was to prevent zero being formatted as an empty string. Perhaps, with hindsight, we should have treated that case specially.
This is a description of the dart documentation
But
void main() {
print(3 >>> 1);
}
Unable to compile, got an error
Error: Expected an identifier, but got '>'.
The documentation is ahead of its time.
I assume the table comes from https://www.dartlang.org/guides/language/language-tour#operators
Dart removed the >>> operator in 2012 when it changed its integer type to arbitrary precision integers (except when compiled to JavaScript). There is no longer a >>> operator in Dart, and there haven't been for several years.
In Dart 2.0, Dart changed its integer type to 64-bit integers (still except when compiled to JavaScript). We plan to reintroduce the >>> operator, and have added it to the language specification, we it has not been implemented by all platforms yet, so it is not available.
The document here was just a little too optimistic about when we release that operator. It won't be in Dart 2.3, as was initially planned.
For all I know a signpropagating right shift operator in Dart is a >> b and not >>>. I don't think >>> exists. Either your source is incorrect or they have a mistake in their docs.
I thought I read somewhere that Z3 has some option for returning the model with the "least" value eg given something like
x >= 2
Z3 would return 2. I could swear that I saw some reference to this recently, but I am unable to find it now. Can anyone confirm this?
No, Z3 does not produce 'least' models. However, a separate branch of Z3 that adds optimization features is being developed at the moment (the branch is called `opt'), and perhaps will later be integrated into Z3 proper. A tutorial for the current optimization features is available here: Z3Opt Guide
Reading sources of Array2D module, I've stumbled upon this interesting construct in implementation of many core functions, for example:
[<CompiledName("Get")>]
let get (array: 'T[,]) (n:int) (m:int) = (# "ldelem.multi 2 !0" type ('T) array n m : 'T #)
I can only assume that this is the syntax to inline CIL and is used here obviously to gain performance benefits. However, when I've tried to use this syntax in my program, I get an error:
warning FS0042: This construct is deprecated: it is only for use in the F# library
What exactly is this? Is there any detailed documentation?
I think that this has 2 purposes:
These functions compile down to exactly 1 CIL instruction which has to be encoded somewhere, so encoding at the source seems best.
It allows for some extra trickery with defining polymorphic Add functions in a high performance way which is hard with the F# type system.
You can actually use this but you have to specify the --compiling-fslib (undocumented) and --standalone flags in your code.
I've found some details in usenet archives: http://osdir.com/ml/lang.fsharp.general/2008-01/msg00009.html
Embedded IL in F# codes. Is this feature officially supported
Not really. The 99.9% purpose of this feature is for operations defined
in FSharp.Core.dll (called fslib.dll in 1.9.2.9 and before).
Historically it has been useful to allow end-users to embed IL in order
to access .NET IL functionality not accessible by F# library or
language constructs using their own embedded IL. The need for this is
becoming much more rare, indeed almost non-existent, now that the F#
library has matured a bit more. We expect this to continue to be the
case. It's even possible that we will make this a library-only feature
in the "product" version of F#, though we have not yet made a final
decision in this regard.
This was a message from Don Syme, dated January of 2008.
I just ran across
http://frankniemeyer.blogspot.com/2010/04/minimalistic-native-64-bit-array.html
Which contains the line
(# "sizeof !0" type('T) : nativeint #)
I believe the technical phrase is "what the heck?" I have never in my (~8 months) of F# programming run across something even resembling that...
FSI tells me something about deprecated constructs, used only for F# libs...
And google with (# does uh...well, not much
Any direction in this?
This is the notation for inline IL emission. It used to be a more prominent feature during F#'s earlier years, but has been deprecated. A gentleman named Brian from the F# team has indicated that it is currently used mainly to bootstrap the F# compiler, and that the team had intended to mark this construct as an error, not merely a warning.
See his post here for the full story.
It's inline IL (intermediate language) code. This construct is used internally by the F# team to implement bits of the F# core library you just can't do any other way. This code will admit a warning saying it shouldn't be used any where other than the F# core libraries, so you probably don't have to worry about it too much as it should never appear in production code.
Fascinating. But I think F# already gives us the conversion operations (for this particular operation!) you need without resorting to IL.
[<Unverifiable>]
let inline ArrayOffset (itemSize:int64) (length:int64) (start:int64) (idx:int64) =
if idx < 0L || idx >= length then raise(IndexOutOfRangeException())
NativePtr.ofNativeInt(nativeint(start + (idx * itemSize)))