I have code that produced a circular build error, and I looked up the error. This page gives a similar but smaller example of what's in my .mli file: https://ocaml.org/learn/tutorials/ocamlbuild/New_kinds_of_build_errors.html
Essentially the problem is that my file is both defining a type and defining functions that use arguments and return values of that same type. However, that's exactly what I want my program to do. My type is not private, it's declared explicitly in the .mli file:
type state = {
current_pos : int*int;
contents : int*int list;
}
val update_state : state -> state
It seems to me reasonable to want to build a module that defines a type and then to share that type with other files, but it seems like the circular build error will always prevent that. Is there some "more proper" way of doing this sharing?
There's nothing at all wrong with the code you posted. It compiles fine. So the problem is in your .ml file.
The page you point to shows code that is incorrect. The only point being made is that you'll get a different error if you use ocamlbuild than you would if you just compile the file directly.
The key point is that you should not use the name of a module inside the definition of the module.
Instead of this (in a.ml):
type t = int
let x : A.t = 14
You should have this:
type t = int
let x: t = 14
If your code is really like this example, you just need to remove the module names inside the .ml file.
As you say, what you want to do is by far the most common use of a module.
Related
I understand that in Flutter, I can declare a Map using a map constructor':
eg.
var map_name = new Map();
and then use it:
map_name[key] = value
or using Map literals:
var details = {'Username':'Fede','Password':'pass#123'};
However, I have seen perfectly valid code in Dart such as:
Map<String, int> phoneBook ={
'Fede': 12345678,
'Juli': 5467899,
'Pablo' : 56788654,
};
This kind of declaration can be accepted by the compiler in normal cases:
code accepted by compiler
but (after hours of debugging) I have seen that not finishing the declaration of one map in this way by not assigning a name for it, the compiler (in Android Studio) will yield an error telling that "Map isn't a type" in other valid declarations, even in other files calling that file where the Map declaration was not finished! That is, the error is quite spread.
crashed code
map isnt't a type
In other words, the unfinished declaration of one Map breaks the possibility to declare any other Maps in this way, anywhere linked to that unfinished sentence giving a 'map isn't a type' error. The problem dissappears when you just put a name to the unfinished Map declaration and Maps are treated as types again. So my question is: Are Maps a type for Flutter, or is it just a minor bug?
In your "crashed code" picture, i seen that you have not provide name for second map.Your error is kind of syntax, please provide correct declaration to make its work. I tried your code in my IDE and its working perfectly.The syntax you tried is totally valid and it should working.
I have the following code in some e file:
<'
package my_package;
struct packet {
foo() is {
print "Hello";
};
};
'>
And my top file imports several files, including this one, and at some point it calls the foo() method.
Now, by mistake I added this code:
struct packet {};
in some other file (I just forgot that I already had a struct called “packet”), which is imported by top before the above file.
Strangely, when I tried to load the top file, I got this error:
*** Error: 'p' (of type main::packet) does not have 'foo()' method.
at line 9 in top.e
p.foo();
But why didn’t it fail already on the file that defines foo()?
It has a struct declaration for packet, but packet was already (mistakenly) declared in an earlier file, so why didn’t it give a duplicate type name error? Is it allowed to have two structs with the same name??
Actually, it's not that the main package takes precedence.
But when a type name is used in some file, the same package to which this file belongs, takes precedence.
In this case, the top.e file probably didn't have any "package" statement, so it also belonged to package main.
If top.e had "package my_package", then "packet" in it would resolve to my_package::packet (and not to main::packet), and there would be no error.
You are allowed to have the same name for different structs, but they must be defined in different packages. In your case you first define packet in the my_package package. I'm guessing the other code you added was in some other file that did not have the line package my_package; in it. This means you defined another struct called packet in the main package. This effectively means that you have two different types: my_package::struct and main::struct. In main::packet you didn't define any foo() function (as you can see also from the error message). As Yuti mentions, in your top.e file you probably don't have a package declared, so the main package takes precedence over any other package.
As an exercise, if you change your code in top.e to my_package::packet instead of simply packet it's going to work. You can anyway see something is wrong from the error message. You know you expected my_package::packet, but you were creating a main::packet.
Have a look in the Specman e Language Reference, section 28, Encapsulation Constructs for more info on packages.
I have in a function the following variable :
97
98 UINT8 Reponse;
99 static UINT8 Initialisation = 0;
100 static DWORD StartTime = 0; //
Initialisation is also the name of one function :
void Initialisation(void)
When I clic on the hyperlink on Initialisation line 99, the block of function void Initialisation(void) is oppened.
Did any of you have an idea of what is appening ?
Thanks you for your help
Jean-Marie
See doxygen's Known Problems:
Not all names in code fragments that are included in the documentation are replaced by links (for instance when using SOURCE_BROWSER = YES) and links to overloaded members may point to the wrong member. This also holds for the "Referenced by" list that is generated for each function.
For a part this is because the code parser isn't smart enough at the moment. I'll try to improve this in the future. But even with these improvements not everything can be properly linked to the corresponding documentation, because of possible ambiguities or lack of information about the context in which the code fragment is found.
and
Doxygen does not work properly if there are multiple classes, structs or unions with the same name in your code. It should not crash however, rather it should ignore all of the classes with the same name except one.
Why doesn't eclipse show an error when I use a variable without declaring it?
Edit:
AFAIK dynamic nature only means that type of variable is not known until run time. The variables must still be defined (explicitly or implicitly) before being used. For example - Python which is also a dynamic language reports this as an error.
Edit2:
How does groovy interpret this code so that it still isn't an error?
Because in dynamic languages like groovy, one could have implemented methodMissing() / propertyMissing(). So although such variable or method does not actually exist, it may be still not be an errors until the program is actually run. Such errors can usually only be detected at runtime and hence IDE's usually don't complain about it.
Although to hint you, eclipse is underlining such variables there which it is not able to statically reference.
EDIT :
To explain the concept by code example, just check the method test below. Now IDE can't know that something , that ... can actually be a method in this class.
This vastly helps in building DSLs in groovy.
class TestClass {
def test() {
def a = something.that.didnt.exist()
or how about some random statements that make no sense at all
a = ew Parser().doSomething() ew blah blah blah
}
def propertyMissing(String name) { println "$name"; return this }
def methodMissing(String name, args) { println "$name with $args"; return this }
}
new TestClass().test()
I think you may try to use #CompileStatic tag on method.
Then Eclipse will compile and check errors at compile time or in develop time.
I haven't Eclipse to check this now, so this is just for a proposal.
I'm a bit confused about interfaces vs. signatures in OCaml.
From what I've read, interfaces (the .mli files) are what govern what values can be used/called by the other programs. Signature files look like they're exactly the same, except that they name it, so that you can create different implementations of the interface.
For example, if I want to create a module that is similar to a set in Java:
I'd have something like this:
the set.mli file:
type 'a set
val is_empty : 'a set -> bool
val ....
etc.
The signature file (setType.ml)
module type Set = sig
type 'a set
val is_empty : 'a set -> bool
val ...
etc.
end
and then an implementation would be another .ml file, such as SpecialSet.ml, which includes a struct that defines all the values and what they do.
module SpecialSet : Set
struct
...
I'm a bit confused as to what exactly the "signature" does, and what purpose it serves. Isn't it acting like a sort of interface? Why is both the .mli and .ml needed? The only difference in lines I see is that it names the module.
Am I misunderstanding this, or is there something else going on here?
OCaml's module system is tied into separate compilation (the pairs of .ml and .mli files). So each .ml file implicitly defines a module, each .mli file defines a signature, and if there is a corresponding .ml file that signature is applied to that module.
It is useful to have an explicit syntax to manipulate modules and interfaces to one's liking inside a .ml or .mli file. This allows signature constraints, as in S with type t = M.t.
Not least is the possibility it gives to define functors, modules parameterized by one or several modules: module F (X : S) = struct ... end. All these would be impossible if the only way to define a module or signature was as a file.
I am not sure how that answers your question, but I think the answer to your question is probably "yes, it is as simple as you think, and the system of having .mli files and explicit signatures inside files is redundant on your example. Manipulating modules and signatures inside a file allows more complicated tricks in addition to these simple things".
This question is old but maybe this is useful to someone:
A file named a.ml appears as a module A in the program...
The interface of the module a.ml can be written in file named a.mli
slide link
This is from the OCaml MOOC from Université Paris Diderot.