I’ve gone through references to generic templates in our codebase to
see what else we can drop. In this case, we are still using
coerceContractId so I’ve updated the comment to explain the current
usecase.
We needed this for our generic template hacks. Since they are gone now,
I'm very much in favour of removing this extension since "undecidable"
always sounds a bit scary, even if it is only at compile time.
CHANGELOG_BEGIN
- [DAML Compiler] Don't make `UndecidableSuperClasses` a default language
extension for DAML anymore. If you really need this feature for a module,
you can reenable it using a `LANGUAGE` pragma at the top.
CHANGELOG_END
* Introduce a simpler template desugaring without support for generic templates
This adapts the LF conversion to the new template desugaring
introduced in our GHC fork. The guiding principle is that we use the
typeclasses directly to avoid generating, typechecking and converting
redundant code caused by indirections. I updated the template
desugaring documentation so that is probably a good starting point for
reviewing this.
* Address review comments
* Fix daml doc tests
* Fix data dependency tests
* Switch to new ghc-lib release
Display the actual number the user tried to use instead of 1.2345.
The logic to display the number is not perfect but definitely better than
we have now. If somebody knows a _simple_ way to do this better, please
tell me about it.
Until now, we broke long party names in the table view in the scenario at
spaces. This looked quite ugly.
Now, we don't break them at spaces. At the same time we also moved the CSS
into a file rather than having it in the code to make changes like this one
easier in the future.
This fixes#3642.
This reenables the migration checks. The migration command now only
generates stumbs for conversions instead of using the formerly (generic)
upgrade template.
* Successfully parse rss xml and find latest blog post object
* Show notification with link to blog (on every ide startup...)
* Only show blog post if not seen before
* Formatting
CHANGELOG_BEGIN
- [SDK] Notify IDE users about new daml-driven blog posts
CHANGELOG_END
* Add setting for user to opt out of notifications
* Use await rather than then
* Catch and swallow exceptions
* Another await and minor cleanup
We don't drop full support from the compiler yet but rather ban their use by
adding a check to the preprocessor. We'll remove the actual support as we go
along with fixing the upgrading story.
CHANGELOG_BEGIN
- [DAML Compiler] Make the experimental feature "generic templates"
unavailable. The current implementation is at odds with other, more important
language features still under development.
CHANGELOG_END
* daml-lf: rename Map to TextMap in archive proto
+ in Scala/haskell AST
* a bit more renamming
* Update compiler/daml-lf-tools/src/DA/Daml/LF/TypeChecker/Serializability.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* fix test
* Apply suggestions from code review
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Update compiler/daml-lf-ast/src/DA/Daml/LF/Ast/Base.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Set Sdk-Version in DAR Manifest to compiler SDK version.
CHANGELOG_BEGIN
- [DAML Compiler] Bugfix: The Sdk-Version field in a DAR manifest file
now matches the SDK version of the compiler, not the sdk-version field
from daml.yaml. These are usually the same, but they could be different
if you set the DAML_SDK_VERSION environment variable before running
``daml init`` or ``daml build``.
CHANGELOG_END
* Fallback to daml.yaml if env var not set
* add yaml dependency
* Always require sdk-version, and emit warning on mismatch with env var
* More explicit about where override comes from
* Add packaging regression test
* generate choice instances for cross sdk dependencies
* add line to test cross-sdk exercise of choice
* revert to naming choice in GenerateSimpleDalf as "NotChoice"
* remove filter/special-handlimg for "Archive" choice
* dont assume a tycon with the same name as a choice; instead use type from chcArgBinder
* error if cant find the template datatype def
* naming
* avoid intercalate followed by re-split on "." in module name
* GenerateSimpleDalf: have two choices: one of record type, one of variant type
* Update Upgrade.hs
* added some linebreaks, spaces for readability
* address cosmetic comments
* use Sdk. prefix as necessary so tests work
* mollify hlint
* fix: daml-assistant/integration-tests
* Change title of release notes tab
This suggests that a new release is available, but not necessarily
installed. We do this for the case that the extension is updated
(which triggers the tab to open) but the actual SDK is not.
* Keep 'New'
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* MVP for a daml2ts codegen
This PR adds an MVP for a codegen for TypeScript.
Given a DAR, daml2ts replicates the structure of the serializable type
definitions in it as TypeScript type definitions following our JSON
representation of DAML-LF types. It also adds decoders for all these types,
which can be used to check where an arbitray JSON value has the given type.
Finally, daml2ts also produces one JavaScript object for each template, which
reflects the type information of that template.
All produces objects implement some interfaces defined in a TypeScript
library currently called `@digitalasset/daml-json-types`. This libary is not
yet uploaded to NPM but rather included in the `tests/ts/daml-json-types`
directory. This libary also contains the JSON decoders for all of DAML-LF's
builtin types.
There are quite a few limitations right now. Most notably, variant and enum
types are not properly typed right now but rather gradually "typed" as
`unknown`. We also don't support nested `Optional`s, the `Numeric` type or
sum-of-product types in DAML. These issues are tracked in #3518.
There is currently one test. It takes a very simple DAML model, generates
the TypeScript for it and checks that it compiles and contains no linter
warnings/errors. Proper integration tests against the JSON API will follow.
* Address @cocreature's comments
* Make test work on Windows
* language: make only needed packages visible for cross sdk imports
This gives us more control over what packages are visible in the package
database during cross sdk imports and makes sure we're not accidentally
picking up the wrong one.
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* deal with evil dalf imports
* Move packaging tests to a separate test suite
Originally, we had these as part of the integration test suite since
`bazel run damlc build` couldn’t locate `ghc-pkg` but that has been
fixed for a while.
Moving it to a separate test suite speeds things up as the integration
tests are rerun very often and also makes development much more
convenient since the new test suite supports `-p` properly to filter
to specific tests.
For now, I’ve left the upgrading tests as part of the integration
tests. I expect that we probably want to factor those out to another
test suite as well.
* fix warnings
Previously we opened file FooX before FooX+1 which we import from FooX
so there is a race condition if we try to resolve imports in FooX fast
enough. Now we open them in reverse order to fix this.
The other option would be to write all files to disk before opening
them but given that we can easily avoid this here, I’d rather keep
things in memory.
It has grown large enough that by now it definitely deserves to be in
its own module.
This PR does not change any of the actual code, it simply moves it around.
* language: fix for tuple types in source generation
We correct the source generation from dalfs containing TupleN data
types. A test is added to the integration tests of daml assistant and
the `generate-src` command is improved to make this test possible.
* check that tuple type comes from DA.Types
* check that compilation succeeded
* pattern match golf
* check for tuples between 2 and 20
This change allows to only import `module A` from the instances package
if data dependencies are present instead of `module A` and `module
AInstances`.
* Add toAnyContractKey and fromAnyContractKey
This is necessary to add exerciseByKey to DAML triggers.
* Switch to proper ghc-lib release
* Remove unnecessary filter
* Bump timeout because macos is terrible
* bazel fmt
I didn't really read the code around the FIXME. After spending a few moments
on it, I'm now convinces the current behaviour is the right behaviour. I
can't think of a short way to explain it in a comment without inflicting my
my previous confusion on others. Thus, I just remove the FIXME.
* No longer depend on "@bazel_tools//tools/jdk:jar"
To avoid the following warnings
```
WARNING: /home/aj/.cache/bazel/_bazel_aj/c1e06e2358666d118d0ae50e2d32c25d/external/bazel_tools/tools/jdk/BUILD:124:1: in alias rule @bazel_tools//tools/jdk🫙 target '@bazel_tools//tools/jdk:jar' depends on deprecated target '@local_jdk//:jar': Don't depend on targets in the JDK workspace; use @bazel_tools//tools/jdk:current_java_runtime instead (see https://github.com/bazelbuild/bazel/issues/5594)
```
* Targets and files should not share names
To avoid the warning
```
WARNING: /home/aj/tweag.io/da/da-master/compiler/damlc/tests/BUILD.bazel:316:1: target 'simple-dalf.dalf' is both a rule and a file; please choose another name for the rule
```
* bazel: 0.28.1 --> 1.1.0
* bazel-watcher sha256
* Fix missing line in patch
* proto_source_root --> strip_import_prefix
See https://github.com/bazelbuild/bazel/issues/7153 for details.
* Update rules_nixpkgs
Required to avoid errors of the form
```
ERROR: An error occurred during the fetch of repository 'node_nix':
parameter 'sep' may not be specified by name, for call to method split(sep, maxsplit = None) of 'string'
```
and
```
ERROR: An error occurred during the fetch of repository 'node_nix':
Traceback (most recent call last):
File "/private/var/tmp/_bazel_runner/17d2b3954f1c6dcf5414d5453467df9a/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl", line 149
_execute_or_fail(repository_ctx, <3 more arguments>)
File "/private/var/tmp/_bazel_runner/17d2b3954f1c6dcf5414d5453467df9a/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl", line 318, in _execute_or_fail
fail(<1 more arguments>)
Cannot build Nix attribute 'nodejs'.
Command: [/Users/runner/.nix-profile/bin/nix-build, /private/var/tmp/_bazel_runner/17d2b3954f1c6dcf5414d5453467df9a/external/node_nix/nix/bazel.nix, "-A", "nodejs", "--out-link", "bazel-support/nix-out-link", "-I", "nixpkgs=/private/var/tmp/_bazel_runner/17d2b3954f1c6dcf5414d5453467df9a/external/nixpkgs/nixpkgs"]
Return code: 1
Error output:
src/main/tools/process-tools.cc:173: "setitimer": Invalid argument
```
* Update rules_scala
* .proto has been removed, use [ProtoInfo] instead
See
https://docs.bazel.build/versions/1.1.0/be/protocol-buffer.html#proto_library
* python3_nix add nix_file attribute
To avoid the following error
```
ERROR: /home/aj/tweag.io/da/da-bazel-1.1/BUILD:66:1: //:nix_python3_runtime depends on @python3_nix//:bin/python in repository @python3_nix which failed to fetch. no such package '@python3_nix//': Traceback (most recent call last):
File "/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl", line 149
_execute_or_fail(repository_ctx, <3 more arguments>)
File "/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl", line 318, in _execute_or_fail
fail(<1 more arguments>)
Cannot build Nix attribute 'python3'.
Command: [/home/aj/.nix-profile/bin/nix-build, "-E", "import <nixpkgs> { config = {}; overlays = []; }", "-A", "python3", "--out-link", "bazel-support/nix-out-link", "-I", "nixpkgs=/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/nixpkgs/nixpkgs"]
Return code: 1
Error output:
error: anonymous function at /home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/nixpkgs/nixpkgs.nix:3:1 called with unexpected argument 'config', at (string):1:1
```
* rules_haskell unnamed string.split(_, maxsplit = _)
The keyword argument may no longer be named.
* string.replace(_, _, maxsplit = _) may not be named
* Move proto sources from deps to data
Fixes
```
ERROR: /home/aj/tweag.io/da/da-bazel-1.1/daml-lf/archive/BUILD.bazel:150:1: in deps attribute of scala_test rule //daml-lf/archive:daml_lf_archive_reader_tests_test_suite_src_test_scala_com_digitalasset_daml_lf_archive_DecodeV1Spec.scala: '//daml-lf/archive:daml_lf_1.6_archive_proto_srcs' does not have mandatory providers: 'JavaInfo'. Since this rule was created by the macro 'da_scala_test_suite', the error might have been caused by the macro implementation
```
* Define sha256 for haskell_ghc__paths
Bazel 1.1.0 fails on missing hashes.
* Disable --incompatible_windows_native_test_wrapper
* //compiler/daml-extension don't modify sources
Modifying sources in-place can cause issues on Windows, where build
actions are not sandboxed and changes on sources can affect other build
steps.
* bazel-genfiles --> bazel-bin
The bazel-genfiles symlink has been removed since Bazel 1.0.
See https://github.com/bazelbuild/bazel/issues/8651
* Mark dev_env_tool repository rule as configure
See
https://docs.bazel.build/versions/1.1.0/skylark/lib/globals.html#repository_rule
* Move data deps into data attribute
* Mark dev_env_tool as local = True
* Manually fetch @makensis_dev_env
When buidling simple project that has our favourite large project as a
dependency, this decreased
- total allocations from 63GB to 57GB
- run time from 34.0s to 31.5s
* language: introduce data-imports
Right now the user experience for importing dalfs and dars from
different sdks is quiet confusing. This PR tries to solve this. We add
an additional field `data-imports` to daml.yaml. These imports can come
from different SDK's and we will generate interface files containing the
data types and their Template instances.
This also simplifies the migration command, as it now always imports the
respective packages as `data-imports`.
Given that I initialy messed this up during development (that’s where
the `reverse` in setting up the typecheck env comes from), it seems
like a good idea to have a test for this :)
* Add support for on-disk incremental builds in damlc build
* Normalise file paths of internal modules because Windows
* stop stealing my $s hlint
* Apparently jars are also called exe
* Address review comments
* Bump to proper ghcide revision
* Display release notes using webview
* Use const and fix string
* Check for version upgrade before showing release notes
* Changelog entry
* Use node-fetch instead of web-request
* Remove spurious state update
* language: cross sdk dalf/dar imports
The final piece for cross sdk imports. With this PR we can import the
data types of packages and dalfs that were created with different sdks.
This is done by generating interface files from dalfs and an 'instances'
package that contains the template instance definitions of template data
types. The instances itself are defined via the `external` keyword,
which is inlined to proper daml-lf instance definitions given in the
respective dalf package.
We test that cross sdk imports work by importing the `simple-dalf` in
the daml-assistant integation tests and running a scenario.
* Allow data A = A by prepending DamlEnum$ to type name.
* Single con enums basically work.
* Fix export lists for single constructor enum types.
* Revert "Fix export lists for single constructor enum types."
This reverts commit 7475a3dfbe3531d3ef62fdbcfe64c01a9e22d7af.
* Switch to a "stupid theta" approach
* Clean up enum type preprocessor
* Run enum preprocessor on generated code.
* Add daml-docs golden test for single constructor enums
* s/genPreprocessor/generatedPreprocessor/g
* Update copyright header
* Update release notes
* Remove unnecessary OverloadedStrings
Currently we hide modules, for which we don't define an alias, when we
specify one alias for *one* module. With this change, all modules
without aliases are still exposed.
* language: refactoring of iface file generation and package db setup.
This is a refactoring of the damlc part that creates the package
database and the code generation for interface files. This is a
preparation for the cross sdk imports.
We also add an internal command to damlc to generate generic instances
code and use simple copying via {..} in the migration command. An
additional test checks that migration via generics still works.
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Upgrade.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* clearer description for generate-gen-src
* updated documentation
* correct copy/pasta mistake
* added a comment on different build options in migration command.
* Update compiler/damlc/lib/DA/Cli/Damlc.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* resolve dalf paths from dar manifest
* added a comment on different headers in upgrade modules.
* removed monoid instance for ExtractedDar
For numeric, the superclass dicts can be of the for `dict @10` so only
handling variables doesn’t work. Now we walk down applications and
check the name on the left.
* Don't cache the GHC Core produced during compilation
In our experiments, this reduced the memory footprint by ca. 18% on a very
big code base.
* Adapt integration tests
* Fix integration tests
* Extend Priority type with Telemetry value
* Include Telemetry logging level in logger
* Log viewing of scenario results
* Update ghcide with telemetry logging level
* Update bazel-common to fix javadoc issues
Specifically, to fix the following error
```
ERROR: /home/aj/tweag.io/da/da-bazel-1.1/ledger-api/rs-grpc-bridge/BUILD.bazel:7:1: in javadoc_library rule //ledger-api/rs-grpc-bridge:rs-grpc-bridge_javadoc:
Traceback (most recent call last):
File "/home/aj/tweag.io/da/da-bazel-1.1/ledger-api/rs-grpc-bridge/BUILD.bazel", line 7
javadoc_library(name = 'rs-grpc-bridge_javadoc')
File "/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/com_github_google_bazel_common/tools/javadoc/javadoc.bzl", line 27, in _javadoc_library
dep.java.transitive_deps
object of type 'JavaSkylarkApiProvider' has no field 'transitive_deps'
```
* Define Maven deps using rules_jvm_external
* Pin artifacts
* Remove bazel-deps generated targets
* Remove bazel-deps
* Switch to rules_jvm_external targets
* update bazel documentation
* pom_file: There are no more bazel-deps targets
* BAZEL-JVM.md `maven_install` typo
* Add TemplateTypeRep to AnyContractId
* Define Trigger.ContractId t
* Use Trigger.ContractId t
* Implement fromCreated and fromArchived
* instance MapKey TemplateTypeRep
* More efficient ACS access using Map TemplateTypeRep
* ./fmt.sh
* toString and fromString for Identifier
* Replace Identifier by TemplateTypeRep
* TheContractId --> AbsoluteContractId
https://github.com/digital-asset/daml/pull/3245#discussion_r338033546
* Properly fill eventId for active contracts
This gets rid of the last remaining bit that assumes
contractId==eventId.
Fixes#65.
Contributes to #2068.
* Do not conflate eventId and contractId in the daml-lf interpreter
* Do not treat contractId as eventId in Ledger.scala
* Remember the transaction that divulged a contract.
* In this scope we can treat divulged contracts the same as disclosed ones
* revert a few more syntactical changes to make the overall diff smaller
* retain the same behavior on the scenario service api
* fix unreleased after rebase
* language: dalf imports and a test
This adds the possibility to directly import dalfs in a project. We test
that we can import the `simple-dalf` in the daml-assistant integation
tests. For now we only check that data type generation works, not yet
the template instance.
The following was fixed: When rewriting package self references, this
changes the hash of the package later on and leads to different package
hashes. Also we need to be careful to write the orignal binary
representation to this and not re-encode it because the encoding might
have changed with a different sdk.
* addressing moritz's comments.
* windows doesnt like bazel paths
* language: fix: don't look for daml files in hidden directories
Fixes#3134. When locating daml source files, we need to make sure we're
not recursing into the .daml directory, because it contains source files
of the dependencies.
* Update daml-assistant/integration-tests/src/Main.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Generalize AnyTemplate type to Any in DAML-LF
See #3131 for the motivation for this. The tl;dr is that we need
something like AnyTemplate for choice types as well.
Since the protobuf was already more general in anticipation of such a
change, this change only changes the internal AST on the Haskell and
Scala side.
Since AnyTemplate change has never made it out of 1.dev, I updated the
changelog in the LF spec instead of adding a new entry.
* Update daml-lf/spec/daml-lf-1.rst
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* windows debugging
* more windows debugging
* clean expunge
* don’t cat the config file
* remove comment on type equality
* windows …
* gnah
* foobar
* foobar
* does anything ever work?
* reenable caching
* Do not build daml-lf-ast separately
This moves the creation of a package database from given dalfs out of
the migrate command and into the init command. In particular, this makes
the process of creating a package database independent of the migrate
command.
It also changes the way this package database is created to be only
dependend on given dalf files.
* language: add internal command for generating source from dalf.
We add an internal command for generating DAML source code from .dalf
packages. Also adds an internal flag to tell the compiler, that it is
compiling generated source.
* Intern all strings and dotted names in the DAML-LF protobuf encoding
On one of our huge DAML code bases this has brought down the size of the
DALF by 60% and cut the memory usage during decoding by 50%.
The `@QUERY-LF` tests in the damlc integration tests check that the
interning actually works.
* Add scala decoder support for interned strings
* Memoize versionisOlderThan. Speeds up decoding by 6x.
* Properly fix the performance problem with version ordering
LanguageVersion.ordering was a `def` and not `val` causing us to
recreate the ordering tables every time.
* Clean up //daml-lf/archive:decode-test
* Use int32 for interning indices
* Adapt QUERY-LF tests
* Strip a few useless field_ prefixes
* Add test for uniqueness in interning tables
* Drop field_ prefix from jq queries
* Fix Scala encoder
* Fix bond-trading tests
* Rename decode-test to decode-tester
* Address @cocreature's comments
* daml-lf: proper versioning for reading internedStrings
* daml-lf repl: revert change
We're working on a feature to import plain DALFs without any attached
source or interface files into a DAML project. This PR provides a tool to
generate a simple DALF file for testing this feature.
* Remove polymorphic literals from library
* Add BECastNumeric and BEShiftNumeric in DAML-LF AST.
* Update rest
* Copyright header
* Remove polymorphic literals from LF conversion.
* Update tests
* Add test for forbidden polymorphic literals
* Add newline in DA.Numeric
* use MulNumeric instead of CastNumeric in DA.Internal.Prelude
After string interning we won't have direct access to string anymore but
rather need to go through the interning tables. This PR implements the
required infrastructure for that endeavour.
* Write JSON files in damlc integration test
There were quite a few occurences where I needed to look at the JSON
representation of the generated DALF in the past. Particularly, when
trying to come up with the `@QUERY-LF` pragmas for new tests.
This PR writes the JSON files to disk next to the (pretty printed)
DALF files.
* Remove useless rewriting of numbers into strings
* Refactor DAML-LF encoder/decoder in prep for string interning
Refactor the encoder/decoder such that all the functions concerned with
interning live next to each other and code will break once the types of
the protobuf messages change.
This PR is a pure refactoring and does not change any functionality.
* Fix typos
Right now, some functions are polymorphic in the monad we use. This is
absolutely unnecessary.
This PR fixes one monad and uses it all over the place. This is a pure
refactoring which doesn't change any functionality.
* Upgrade ghc-libs
* Convert template instances as type synonyms to DAML-LF
* Look for TEMPLATE_INSTANCE suffix for daml docs
* Update desugaring documentation
The compiler rewrites constraints like `Template (Foo t) => ...` into
`FooInstance t => ...`. Unfortunately, this rewriting does not yet kick in
when the constraint contains superfluous parentheses as in
`(Template (Foo t)) => ...`.
This PR fixes the problem.
Fixes#2994.
* Merge package reference detection into package id encoding
Currently, the encoding of a DAML-LF package works in two phases:
1. We compute the set of all package ids refernced by the package to encode.
2. We use this set of package ids to form a table for interning that is then
consulted during the encoding of package ids.
This PR changes it such that the interning table is computed while the
package is being encoded. New package ids are added to the table whenever
they are encountered for the first time.
This is in preparation for the general inlining of all strings, which will
use the same approach to building the interning table.
This PR is a pure refactoring and does not change any functionality.
* Addess @cocreature's comments
* Add unordered-containers as a dependency
Previously the test names consisted of the full absolute file paths
which got unreadable very quickly. Sadly the absolute file paths still
leak into the error messages since I don’t know of a nice way to get
relative paths here (just making them relative to cwd doesn’t work)
but this is still much more readable.
Previously, we sometimes missed the dlint hints because we got killed
due to a typechecking error before they were produced. Now, we
force them to be generated which should hopefully fix that.
Currently, the integration tests fail sometimes because of missing lints.
Our suspicion is that the linter gets killed when the type checker fails
before it managed to produce the lints. This change makes sure we wait for
the linter.
* Numeric implementation
* Dealing with all sorts of numeric literals.
* Fix DA.Generics
* Reduce code duplication with IF_NUMERIC
* Simplify Prelude with IF_NUMERIC
* Fix daml-lf validation for MUL_NUMERIC and DIV_NUMERIC