I am trying to use a tree based map in Coq, specifically Coq.FSets.FMapAVL.
I found this 4 year old question: Finite map example
Looking at the standard lib documentation referenced in the comments, I see this note:
NB: This file is here only for compatibility with earlier version of FSets and FMap. Please use Structures/Orders.v directly now.
What does this mean? When I google "Structures.v" or "Orders.v" I always end up at other documentation pages with related deprecation warnings.
What is the proper, non-deprecated way to use an FMap in Coq 8.6?
Since the OrderedTypeEx module is deprecated, we won't use Nat_as_OT defined in it.
There is Nat_as_OT in OrdersEx (just a synonym for PeanoNat.Nat), which is useful for our purposes.
Unfortunately, the following code
Require Import Coq.Structures.OrdersEx.
Module M := FMapAVL.Make Nat_as_OT.
won't work, because signatures OrderedType.OrderedType (currently used by FMapAVL) and Orders.OrderedType are not compatible.
However, the OrdersAlt module contains functors, which allow to build a module of one type from another. In this case, we are interested in Backport_OT. The following code shows how to use FMapAVL.Make, the rest of the code can be copied from the linked question:
From Coq Require Import
FSets.FMapAVL Structures.OrdersEx Structures.OrdersAlt.
Module backNat_as_OT := Backport_OT Nat_as_OT.
Module M := FMapAVL.Make backNat_as_OT.
The situation with FMapAVL was explained by Pierre Letouzey in this Coq-Club post:
the transition between old-style OrderedType and the new one isn't
finished yet (some work remain to be done on FMaps for instance),
and we cannot simply remove the old-style OrderedType.
Related
Why module using .A has to be prefixed with dot? It doesn't work if you omit the dot.
File ./A.jl
module A
export sayHi
function sayHi()
println("hi")
end
end
File ./Main.jl
include("./A.jl")
using .A # <= Why it has to be prefixed with dot?
sayHi()
Running, start REPL and type
include("./Main.jl")
Part 2
And if you move file A.jl to different location, like ../some-dir/A.jl it has to be prefixed to two dots using ..A. Why?
Because you define module A inside your current module. The dot means "look inside the current module for this". https://docs.julialang.org/en/v1/manual/modules/#Relative-and-absolute-module-paths-1
After digging it deeper - it seems like the answer is - don't use modules.
The documentation is wrong, it says
When in reality, the module usage is heavily tied to the location of files, it could be using Foo, using .Foo, using ..Foo or using Main.Foo - depending on the location of the Foo module relative to the file that imports it. In my personal opinion - something is very wrong with that design.
No support in the VSCode Editor, it doesn't understand using ..Foo. There are other ways to use modules, including altering startup.jl or JULIA_LOAD_PATHS - none of it works either. I assume nobody noticing these problems because nobody actually using modules.
Top answer on YCombinator - gives the same answer - the best way to use modules in Julia - is to not use it at all https://news.ycombinator.com/item?id=19232824
Can someone give a full explanation of the syntax for Atom's data-grammar attribute (used in keybinding selectors)?
For instance, what is the difference between
[data-grammar='source example']
and
[data-grammar~='source example']
?
Also, how do you specify multiple grammars? For instance, how would you specify that a key binding should be limited to html or xml formats?
If there already exists documentation on this somewhere, I have not yet found it, but would appreciate being pointed to it.
Quick Example:
keymap.cson:
"atom-text-editor[data-grammar='text tex latex']":
'f5':'latex:build'
Grammar Information & Documentation
I began by looking at the file-types package. source and text categorize languages - source deals with development languages, while text deals with documentation/logs formats.
You can add and customize language recognition by reading the flight manual. I've linked some specific sections below that are helpful for that.
Flight Manual | Basic Customization:
Language Recognition
Language Specific Settings
Working with [data-grammar]:
The little doocumentation given is listed under the Keymaps in Depth section.
Flight Manual | Keymaps in Depth
Selectors and Custom Packages.
This also describes the not([...]) functionality used below and how to manipulate various rules.
Although in the above, grammars are listed in a dot format, ie source.c, to use them in the [data-grammar='<name>'] format spaces are instead required.
An example of how I might use the data grammar option in my keymap.cson config is as such (here I'm using the latex package):
"atom-text-editor[data-grammar='text tex latex']":
'f5':'latex:build'
The ~ is not the correct syntax for desired functionality with data-grammar. Instead, use something like "atom-text-editor:not([data-grammar='<name>'])":
Note that you wouldn't use data-grammar in something like config.cson. The syntax for language specifics looks something like this instead:
# **config.cson**
".latex.tex.text":
editor:
softWrap: true
Extra useful information - List of registered Grammars
A dump of the output of Object.keys(atom.grammars.grammarsByScopeName).sort().join('\n') through the Dev Console (View > Developer > Toggle Developer Options > Console)
source.c
source.cake
source.clojure
source.coffee
source.cpp
source.cs
source.css
source.css.less
source.css.scss
source.csx
source.diff
source.gfm
source.git-config
source.go
source.gotemplate
source.java
source.java-properties
source.js
source.js.rails source.js.jquery
source.js.regexp
source.js.regexp.replacement
source.json
source.litcoffee
source.makefile
source.nant-build
source.objc
source.objcpp
source.perl
source.perl6
source.plist
source.python
source.python.django
source.regexp.python
source.ruby
source.ruby.gemfile
source.ruby.rails
source.ruby.rails.rjs
source.sass
source.shell
source.sql
source.sql.mustache
source.sql.ruby
source.strings
source.toml
source.verilog
source.yaml
text.bibtex
text.git-commit
text.git-rebase
text.html.basic
text.html.erb
text.html.gohtml
text.html.jsp
text.html.mustache
text.html.php
text.html.ruby
text.hyperlink
text.junit-test-report
text.log.latex
text.plain
text.plain.null-grammar
text.python.console
text.python.traceback
text.shell-session
text.tex
text.tex.latex
text.tex.latex.beamer
text.tex.latex.memoir
text.todo
text.xml
text.xml.plist
text.xml.xsl
To complement Mr G's answer, atom-text-editor[data-grammar~='html'] with the ~= means match an <atom-text-editor> HTML element with a data-grammar attribute that contains "html" amongst any other possible whitespace separated words.
For example, if the current language of the file is PHP, then the text-editor HTML element will look something like this:
<atom-text-editor data-grammar="text html php">
And atom-text-editor[data-grammar~='html'] will match this.
More info on attribute selectors: https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors
As for trying to select multiple grammars, I don't think it's possible unless they share a common word in the data-grammar attribute, e.g., both HTML and PHP share "html", or both C and JavaScript share "source" (but in this case many other grammars share "source"). The only other way is to specify a keymap for each grammar individually even if it's the same key combination.
So, in the asdf manual/documentation in section 6.5 of the package-inferred-system extension, the example uses an all.lisp file for determining packages (which I/we will assume will contain all of the function and package information for that respective subdirectoty).
What I want to know is what would be the "proper" way of including all of the function and package declarations in this all.lisp file. Would I do something like including all of the function declarations for that subdirectory in the all.lisp file, and then use the register-system-packages function in the asdf file. Or could I omit the all.lisp file, and let the compiler infer the packages from the files (but would I have to then use the register-system-packages function for every single file I add to this system).
I'm just wondering more about the specifics of using this system and the files and declarations that have to be made when adding a new file to the system.
Sorry for the opacity of the question; I can't seem to grasp the specifics of this system
1- See how it's done in lisp-interface-library/*/all.lisp, using uiop:define-package and its :use-reexport clause.
See for instance pure/all.lisp:
(uiop:define-package :lil/pure/all
(:nicknames :pure)
(:import-from :lil/interface/all)
(:use :closer-common-lisp)
(:mix :fare-utils :uiop :alexandria)
(:use-reexport
:lil/interface/base
:lil/interface/eq
:lil/interface/order
:lil/interface/group
:lil/pure/empty
:lil/pure/collection
:lil/pure/iterator
:lil/pure/map
:lil/pure/set
:lil/pure/alist
:lil/pure/tree
:lil/pure/hash-table
:lil/pure/fmim
:lil/pure/encoded-key-map
:lil/pure/queue
:lil/pure/iterator-implementation
:lil/pure/map-implementation
:lil/pure/set-implementation
:lil/pure/alist-implementation
:lil/pure/tree-implementation
:lil/pure/hash-table-implementation
:lil/pure/fmim-implementation
:lil/pure/encoded-key-map-implementation
:lil/pure/queue-implementation
))
2- These days, I recommend use requiring asdf 3.1 and not using asdf-package-system. For maximal backward incompatibility, use
#-asdf3.1 (error "<my system> requires ASDF 3.1 or later. Please upgrade your ASDF.")
And then in your defsystem, :class :package-inferred-system
3- I do not follow this forum closely. ASDF questions find a quicker answer on the asdf-devel mailing-list.
As I interpret that, you would simply have the package defined in all.lisp depend on the packages defined in the other files of that system. It is then, in a way, an entry point for the dependency graph into that system. I would expect all.lisp to contain high level entry definitions that naturally depend on the other files.
For example, if you build a system that has a (sub-)system for exposing a web interface, the webinterface/all.lisp file/package would contain functions for configuring, starting, and stopping the web server. These functions would depend on the handler definitions in other files/packages which in turn would depend on other files/packages that provide the data or do the meat of request processing.
I want to use R's mathematical functions as provided in libRmath from Ocaml. I successfully installed the library via brew tap homebrew science && brew install --with-librmath-only r. I end up with a .dylib in /usr/local/lib and a .h in /usr/local/include. Following the Ocaml ctypes tutorial, i do this in utop
#require "ctypes.foreign";;
open Ctypes;;
open Foreign;;
let test_pow = foreign "pow_di" (float #-> int #-> returning float);;
this complains that it can't find the symbol. What am I doing wrong? Do I need to open the dynamic library first? Set some environment variables? After googling, I also did this:
nm -gU /usr/local/lib/libRmath.dylib
which gives a bunch of symbols all with a leading underscore including 00000000000013ff T _R_pow_di. In the header file, pow_di is defined via some #define directive from _R_pow_di. I did try variations of the name like "R_pow_di" etc.
Edit: I tried compiling a simple C program using Rmath using Xcode. After setting the include path manually to include /usr/local/include, Xcode can find the header file Rmath.h. However, inside the header file, there is an include of R_ext/Boolean.h which does not seem to exist. This error is flagged by Xcode and compilation stops.
Noob alert: this may be totally obvious to a C programmer...
In order to use external library you still need to link. There're at least two different ways, either link using compiler, or link even more dynamically using dlopen.
For the first method use the following command (as an initial approximation):
ocamlbuild -pkg ctypes.foreign -lflags -cclib,-lRmath yourapp.native
under premise that your code is put into yourapp.ml file.
The second method is to use ctypes interface to dlopen to open the library. Using the correct types and name for the C function call, this goes like this:
let library = Dl.dlopen ~filename:"libRmath.dylib" ~flags:[]
let test_pow = foreign ~from:library "R_pow_di" (double #-> int #-> returning double)
Ada is still new to me, so I am trying to find my way around the GPS IDE. I asked another question earlier, but I think this problem has precedence over that one, and may be at the root of my trouble.
When I compile, I am getting a long list of *warning: source file ... not found"
In my .gpr file, I have listed all of the spec and body source files and use the following naming scheme:
package Naming is
for Casing use "mixedcase";
for Dot_Replacement use ".";
for Spec_Suffix ("ada") use "_s.ada";
for Body_Suffix ("ada") use "_b.ada";
end Naming;
What is odd it the error messages all look either like this:
warning: source file "xxx_b.adb" not found
or this
warning: source file "xxx.adb" not found
Note that neither of these (xxxb.adb or xxx.adb) conform to the file specs, which should end with .ada.
Can someone explain what is going on here?
I'm 99% sure that the problem is one of the ones I mentioned in answer to your other question: GNAT does not normally support more than one compilation unit in a file. I got exactly the behaviour you describe with GPS and these files:
james_s.ada:
with Jane;
package James is
end James;
jim_s.ada:
package Jim is
end Jim;
package Jane is
end Jane;
The error message on compiling james_s.ada says it can't find Jane_s.ada, but when I ask GPS to go to the declaration of Jane it takes me to the "correct" line in jim_s.ada.
You could use gnatchop to split jim_s.ada, but it doesn't understand project files or naming conventions; you probably want to keep the existing names for the code that works, so you'd rename gnatchop's output as required.
However! to my great surprise, it turns out that GNAT does support having more than one compilation unit in a file, provided package Naming in the project file tells it about each unit in the file:
package Naming is
for Casing use "mixedcase";
for Dot_Replacement use ".";
for Spec_Suffix ("ada") use "_s.ada";
for Body_Suffix ("ada") use "_b.ada";
for Spec ("Jim") use "jim_s.ada" at 1;
for Spec ("Jane") use "jim_s.ada" at 2;
end Naming;
It's up to you whether to do this or to bite the bullet and use gnatchop, either on the multi-unit files or on the whole source tree.
First off, this isn't an Ada problem, its a Gnat problem. Other Ada compilers have no problem with the file names you are using.
However, Gnat is rather unique in that it expects there to be only one program unit (package body, package spec, stand-alone routine, etc) per source file. This is because it is also rather unique in that it expects to be able to find the source code for any program unit just by knowing that unit's Ada intentifier. Most other Ada compilers maintain some kind of library file that maps file names to program units, and you have to register all your files into it. (Whereas your typcial C compiler just leaves the problem of finding files for all your code up to the user entirely).
Generally the easiest thing to do with Gnat, the way that will cause you the least trouble, is to just use its default file naming convention (and of course don't put multiple program units in a single file.
If you already have some existing Ada code (perhaps developed for another compiler), the easiest way to import it into Gnat is typically to run the gnatchop tool on it all. So that's what I'd suggest you try.
From GPRbuild User's Guide:
Strings are used for values of attributes or as indexes for these attributes. They are in general case sensitive, except when noted otherwise [...]
Based on this, I believe you have to use "Ada" instead of "ada" as index for Spec_Suffix and Body_Suffix. I currently do not have access to the tools for testing this, so I suggest to just try it out.