Using exuberant-ctags 5.8 for gcc 4.4.3 c89
I am just started using exuberant-ctags and I am just wondering what options do you add.
Here is a list and I am just wondering added too many could it be over kill.
$ ctags --list-kinds=c
c classes
d macro definitions
e enumerators (values inside an enumeration)
f function definitions
g enumeration names
l local variables [off]
m class, struct, and union members
n namespaces
p function prototypes [off]
s structure names
t typedefs
u union names
v variable definitions
x external and forward variable declarations [off]
I was going to use the following:
ctags -e --c-kinds=+defgpstux -R
I am just wondering: is that overkill?
c classes No -- I don't have any classes as this is c
d macro definitions YES -- I have many macros
e enumerators (values inside an enumeration) YES
f function definitions YES
g enumeration names YES
l local variables [off] NO
m class, struct, and union members NO
n namespaces NO
p function prototypes [off] YES
s structure names YES -- Is there any difference with m
t typedefs YES
u union names YES
v variable definitions NO
x external and forward variable declarations [off] YES
I wouldn't say it is overkill, I would turn on m though (structs and union member searching is very good)
Ctags in general is good if you are working from the command line or with an editor that supports it (gvim for example). If you really want advanced features I'd recomend going for a good IDE. There are somethings you simply can't do directly with ctags (such as call hireachy, or refactoring which a good IDE with good C/C++ indexing support will give you)
I don't think any of these are overkill, however you might want to investigate CScope to 'take it to the next level'. It seems like you might be squeezing the maximum you'll be able to get out of ctags and thats where CScope picks up.
Related
I was curious about F#'s "constructed type" syntax. It's documented here.
type-argument generic-type-name
or
generic-type-name
With the following examples:
int option
string list
int ref
option<int>
list<string>
ref<int>
Dictionary<int, string>
I was curious if there's anything special about the "backwards" syntax, with the parameter before the type, or if it's just sugar for generic types with one parameter. The following is valid:
type 'a MyOption = // MyOption<'a> also works
| MySome of 'a
| MyNone
But I could not get it to work with multiple type parameters. Why do F# developers prefer this syntax for types with one parameter? Is it possible or desirable to make it work with two?
The backwards syntax is a legacy from OCaml. Personally, I never use it. If you really want to, you can make it work with multiple type arguments like this:
type MyMap = (int, string) Map
However, this generates a pointed warning (that might soon become an error):
This construct is for ML compatibility. The syntax '(typ,...,typ) ident' is not used in F# code. Consider using 'ident<typ,...,typ>' instead. You can disable this warning by using '--mlcompatibility' or '--nowarn:62'.
Bottom line, I would recommend always using .NET syntax instead: MyOption<'a> instead of 'a MyOption.
Why do F# developers prefer this syntax for types with one parameter?
Not all of us do. I love F# and am in awe of it, but find the OCaml style distracting.
It gets especially confusing when the two styles are mixed - compare the readability of Async<Result<int,string list>> list with that of List<Async<Result<int,List<string>>>>.
Here is a thread with some arguments from both sides from fslang suggestions, which I think led to the deprecation of OCaml-style for everything but list, option and a few others.
I find it regrettable that the OCaml style is specified as the preferred option (for these types) in the various style guides, and used throughout the core libraries, while there is such a strong drive to make the language more accessible to newcomers. It definitely adds to the learning curve, as documented in this question,
and here,
here,
here,
here,
here.
Is it possible or desirable to make [OCaml style naming] work with two [type parameters]?
I think a better question is: "Is it possible to only use .NET style?".
Unfortunately the tooling shows types the way they are declared, and the core libraries consistently use OCaml style. I have asked Rider about always showing declarations .NET style in code vision, who referred me to FSharp compiler services. I have not (yet) investigated that avenue further.
In our own code we have taken to overriding the OCaml signatures of functions that ship with F# and other libraries as we come across them, for example:
[<AutoOpen>]
module NoCaml =
module List =
/// Returns a new collection containing only the elements of the collection for which the given predicate returns "true"
let filter = List.filter : ('a -> bool) -> List<'a> -> List<'a>
/// val groupBy : projection:('T -> 'Key) -> list:'T list -> ('Key * 'T list) list (requires equality and equality) 'T is 'a 'Key is 'b Applies a key-generating function to each element of a list and yields a list of unique keys. Each unique key contains a list of all elements that match to this key.
let groupBy = List.groupBy : ('a -> 'b) -> List<'a> -> List<'b * List<'a>>
// etc.
This solves the problem in almost all cases (some exceptions like list construction using [] remain, and need to be overridden at the point of declaration).
I'm not sure what influence this has on performance at runtime - hopefully the extra function calls are optimised away.
I hope this question is appropriate for this site, it's just about the choice of concrete syntax in Idris compared to Haskell, since both are very similar. I guess it's not that important, but I'm very curious about it. Idris uses => for some cases where Haskell uses ->. So far I've seen that Idris only uses -> in function types and => for other things like lambdas and case _ of. Did this choice come from realizing that it's useful in practice to have a clear syntactical distinction between these use cases? Is it just an arbitrary cosmetic choice and I'm overthinking it?
Well, in Haskell, type signatures and values are in different namespaces, so something defined in one is at no risk of clashing with something in the other. In Idris, types and values occupy the same namespace, which is why you don't see e.g. data Foo = Foo as you would in Haskell, but rather, data Foo = MkFoo - the type is called Foo, and the constructor is called MkFoo, as there is already a value (the type Foo), bound to the name Foo, e.g. data Pair = MkPair http://docs.idris-lang.org/en/latest/tutorial/typesfuns.html#tuples
So it's probably for the best it didn't try to use the arrow used to construct the type of functions, with the arrow used for lambdas - those are rather different things. You can combine them with e.g. the (Int -> Int) (\x => x).
I think it is because they interpret the -> symbol differently.
From Wikipedia:
A => B means if A is true then B is also true; if A is false then nothing is said about B
which seems right for case expressions, and
-> may mean the same as =>, or it may have the meaning for functions given below
which is
f: X -> Y means the function f maps the set X into the set Y
So my guess is that Idris just uses -> for the narrow second meaning, i.e. for mapping one type to another in type signatures, whereas Haskell uses the broader interpretation, where it means the same as =>.
Is somewhere exists programming languages with auto-updatable variables.
For example:
a = 100
b = a * 3 + 1 // 301
c = sin(b) + a // 99.1428
After modifying 'a': a = 105, corresponding variables automatically recalculated:
b: 316
c: 104.3053
If such languages exists, what approaches are used to implement this behavior?
What you want is deferred evaluation. It's common in spreadsheet applications. I think the R language also allows for something like that.
You can implement it in almost any language.
The usual approach is that you define a terminator class (say Number) and override the operators (if the language supports it, like c++, C# or python) to return nodes in an tree. So a * 3 + 1 will be equivalent to something like (b = Sum(Mult(a, Number(3)), Number(1)). Once you have something like this you can change the value of a with an accessor and then request the top node to be reevaluated, which gives you the value you need.
There are probably a couple of implementations already out there. It's not hard to implement, but it'a bit tedious to define all the classes and implicit conversions needed. It get's more complicated if you want to optimize the evaluation.
You might want to take a look at Functional Reactive Programming in general, and Elm in particular, which provide that kind of computational style in a functional programming environment.
I'm wondering why some _closure symbols do not have corresponding _info symbols.
On OSX I have installed ghc-7.8.3 via https://ghcformacosx.github.io/
If I run:
nm -gU /Applications/ghc-7.8.3.app/Contents/lib/ghc-7.8.3/bin/../directory-1.2.1.0/libHSdirectory-1.2.1.0-ghc7.8.3.dylib | grep findExecut
I get the following output:
0000000000010348 D _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutable1_closure
000000000000a3a8 T _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutable1_info
000000000000fe90 D _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutable2_closure
000000000000fe78 D _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutable3_closure
000000000000fe58 D _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutable4_closure
00000000000046c8 T _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutable4_info
00000000000105a8 D _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutable_closure
000000000000d6f0 T _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutable_info
0000000000010338 D _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutablezuzdsa_closure
000000000000a030 T _directoryzm1zi2zi1zi0_SystemziDirectory_findExecutablezuzdsa_info
Note that not all of the _closure symbols have corresponding _info symbols.
I have a situation where tar-0.4.1.0 is referencing the findExecutable3_info symbol, and linking fails because it isn't found. But first I'd like to understand the why and wherefores of the _info symbols.
See this diagram of a closure from https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects:
Every ordinary ("boxed") Haskell value is represented in memory by an object called a closure. The first word of the closure is called the "info pointer" and identifies what sort of value it is, while the rest of the closure contains data that determines the specific value (for instance, the fields of an ADT). Most closures are dynamically allocated on the heap, but a compiled Haskell program can also contain so-called static closures in its data sections. The _closure symbols are these closures that live inside the object file, and the _info symbols are the pointers to the end of info tables and the start of entry code.
For instance, if your program contains the source
x :: Integer
x = 123
then it will be compiled into the core
x :: Integer
x = S# 123# -- S# is the "small integer" constructor for Integer,
-- and 123# is an unboxed Int# literal
and in the object file there will be a symbol with a name like x_closure which is two words long, whose first word points to S#_info (via an ELF relocation) and whose second word is the value 123. In this case, there is no need for an x_info because x is an S# value.
For a function f, GHC will generate both an f_info which can be called directly when f is used in a context in which it is supplied enough arguments, and an f_closure with info pointer f_info which can be used otherwise (for example if f is used as an argument to a higher-order function). See https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#FunctionClosures.
As for your linker error, you probably have some interface files that are out of sync with their corresponding object files. There is no particular meaning to the name findExecutable3, it's just some auxiliary definition that got lifted to the top level when compiling findExecutable. I would guess that somewhere in the interface file for System.Directory (or a module which depends on it) you have some unfolding that refers to a function findExecutable3, but when System.Directory was compiled, findExecutable3 actually ended up being some other sort of value.
I have multiple sequences I want to zip in a more readable way such that I could write
a.Zip(b)
in query syntax as
From a in Foo1
Join b in Foo2
without the result being a cross join
or
From a in Foo1
Zip b in Foo2
The standard Zip method allows you to write something like (using C#):
from t in first.Zip(second, (f, s) => new { First = f, Second = s }
select ... t.First ... t.Second;
I think this should be readable enough. Your question seems to suggest that you'd like to be able to create your own keyword e.g. zip and extend the C# query expressions using it. This is not possible in C# or Visual Basic (but I agree it would be nice in a way).
With some effort, you can redefine what standard C# query construct does, so that join would behave like zip (In that case, the equals part of the query would not be needed, so you'd have a lot of syntactic noise). Possibly, you could also redefine what from clause. I didn't try it, but I believe you could get something like:
from f in first.Zip()
from s in second.AddToZip()
from t in second.AddToZip()
select ... f ... s ... t ...;
I wrote an article that describes how to do this redefining for the group by clause (Using custom grouping operator in LINQ), so this can give you an idea how this can be done.
(But honestly, I think that the standard Zip method should be fine. The redefinition of operators is quite subtle. The group by example may be more appealing because grouping using method is uglier, but even that is on the edge...)