As I understand it, when a managed language (like Haxe) can and wants to compiles to a non-managed language (like C++), it includes some form of garbage collector in the runtime.
I was wondering if it would be possible to completely abstract away memory management in the intermediate representation / abstract syntax tree, so that a garbage collector would not be needed and the default behavior (stack allocations live until end of scope and heap allocations live until freed) could be used?
Thank you!
If I understood you correctly, you're asking whether it's possible to take a garbage collected language and compile it to an equivalent program in a non-garbage collected language without introducing memory errors or leaks, just by adding frees in the right places (i.e. no reference counting or otherwise keeping track of references or implementing a garbage collection algorithm in anyway or doing anything else at run time that could be considered garbage collection).
No, that is not possible. To do something like this, you'd have to be able to statically answer the question "What's the point in the program, after which a given object is no longer referenced", which is a non-trivial semantic property and thus undecidable per Rice's theorem.
You could define a sufficiently restricted subset of the language (something like "only one live variable may hold a strong reference to an object at a time and anything else must use weak references"), but programming in that subset would be so different from programming in the original language¹ that there wouldn't be much of a point in doing that.
¹ And perhaps more importantly: it would be highly unlikely that existing code would conform to that subset. So if there's a compiler that can compile my code to efficient GC-free native code, but only if I completely re-write my code to fit an awkward subset of the language, why wouldn't I just re-write the project in Rust instead? Especially since interop with libraries that aren't written in the subset would probably be infeasible as well.
We have a few non-erlang-connected clusters in our infrastructure and currently use term_to_binary to encode erlang terms for messages between the clusters. On the receiving side we use binary_to_term(Bin, [safe]) to only convert to existing atoms (should there be any in the message).
Occasionally (especially after starting a new cluster/stack), we run into the problem that there are partially known atoms encoded in the message, i.e. the sending cluster knows this atom, but the receiving does not. This can be for various reasons, most common is that the receiving node simply has not loaded a module containing some record definition. We currently employ some nasty work-arounds which basically amount to maintaining a short-ish list of potentially used atoms, but we're not quite happy with this error-prone approach.
Is there a smart way to share atoms between these clusters? Or is it recommended to not use the binary format for such purposes?
Looking forward to your insights.
I would think hard about why non-Erlang nodes are sending atom values in the first place. Most likely there is some adjustment that can be made to the protocol being used to communicate -- or most often there is simply not a real protocol defined and the actual protocol in use evolved organically over time.
Not knowing any details of the situation, there are two solutions to this:
Go deep and use an abstract serialization technique like ASN.1 or JSON or whatever, using binary strings instead of atoms. This makes the most sense when you have a largish set of well understood, structured data to send (which may wrap unstructured or opaque data).
Remain shallow and instead write a functional API interface for the processes/modules you will be sending to/calling first, to make sure you fully understand what your protocol actually is, and then back that up by making each interface call correspond to a matching network message which, when received, dispatches the same procedures an API function call would have.
The basic problem is the idea of non-Erlang nodes being able to generate atoms that the cluster may not be aware of. This is a somewhat sticky problem. In many cases the places where you are using atoms you can instead use binaries to similar effect and retain the same semantics without confusing the runtime. Its the difference between {<<"new_message">>, Data} and {new_message, Data}; matching within a function head works the same way, just slightly more noisy syntactically.
I have become a great fan of the powerful type system in F# and how it allows you to create some very tight restraints on your domain models (for those interested, see this). I have also become a great fan of RavenDB and how it makes database work very simple in most of the cases I run into. However, there seems to be issues getting the two to play nicely together - at least if you insist on immutable types.
As long as you don't ever have to update your entities, all you need to do is make the id property mutable. While I'm certainly not happy that this is necessary, I can live with it. However, it seems that change tracking is handled in such a way that you must mutate the original object retrieved from the database and it is not possible to attach a new object to the database to represent an updated version of an existing entity. It does seem to be possible to do what I want using the patching API, but the documentation clearly warns against this type of general usage.
Am I missing a part of the RavenDB API that will let me do this without too much fuss or must I abandon the idea of immutable domain models (or perhaps make a feature request for it)?
The problem with immutable in that scenario is that you are actually dealing with mutable data.
The document is being mutated. The fact that you don't mutate it in user space is of little matter here.
What you can do is wrap calls to Advanced.Evict & Store in a StoreUpdated or something like that extension method. But I would call into question the usage of immutable data to represent mutable state.
Pointers can be still used in pascal and i think they may preserve it until delphi is alive.
Even though i have used pointer when i am learning pascal. I still can't understand the real use of pointers, I manage to do all my delphi programs without it.(by some other ways)
what is the real use of pointers. And I am asking for real world usage, and can we manage to do anything without pointers.
You use pointers a lot more often than you think you do in Delphi. The compiler just hides it.
var
SL: TStringList;
...
SL := TStringList.Create;
// SL is now a pointer to an instance of the TStringList class.
// You don't know it because the compiler handles dereferencing
// it, so you don't have to use SL^ . You can just use the var.
SL.Add('This is a string');
A string is also a pointer to a block of memory that stores the string. (It actually stores more than that, but...)
So are instances of records, PChars (which is a pointer to a character array, basically), and tons of other things you use every day. There are lots of pointers that aren't called Pointer. :)
the pointers contain the address of a memory location, because that are present everywhere. each variable which you declare, even the code which you write can be accessed using a pointer, the pointers is one of the most essential elements in Win32 programming, you must read this great article from Rudy Velthuis Addressing pointers to understand the pointers usage.
To understand what pointers might be used for in modern day Delphi, one needs to understand how pointers have been historically used and how Delphi uses pointers behind the scenes.
Pointers to code
One can have a pointer to a piece of code. This can be used for the intuitive thing (parameterizing some algorithm with the functions it needs to call; example: TObjectList.Sort takes a function pointer as a parameter). Modern Delphi uses pointers-to-code to implement the following (without going into details):
Virtual Method Tables; We can't have OOP without VMT's
Interfaces
Events and anonymous methods.
Those are all very powerful methods of avoiding raw pointers to code, indeed there's very little need for raw code pointers today.
Pointers to data
Everybody learned pointers using the Linked Lists. Pointers are essential in the implementation most non-trivial data structures; In fact it's hard to name a useful data structure that's not implemented using pointers.
Delphi gives lots of grate abstractions for data pointers, so we can work without ever touching an pointer. We have Objects (class instances) and good implementations for most data structures (string, TObjectList, dynamic arrays).
When do we use Pointers?
We essentially use pointers to implement more of the grate stuff that Delphi provides for us. I can give examples of what I've used pointers for, but I find it more interesting to give examples of what others have used pointers for:
TVirtualTree: Makes good use of pointers to data.
Pascal Script for Delphi: Makes extensive use of raw pointers to code!
Let's start with a definition, taken from Wikipedia:
A pointer is a programming language
data type whose value refers directly
to (or "points to") another value
stored elsewhere in the computer
memory using its address.
All computers address memory and to do so the machine language that they execute must do so using pointers.
However, high level languages do not need to include pointers explicitly. Some examples of those that do not are LISP, Java, C#, Perl, Python, but there are many more.
I'm interpreting your question to be why languages support explicit pointer use, since all languages use pointers implicitly.
Delphi descends from Pascal which is a rather primitive language when viewed from the 21st century. Pascal pointers are the only way to use references. In modern Pascal derivatives, e.g. Delphi, have many types of data that are reference based, but implicitly so. For example I'm thinking of strings, object instances, interfaces and so on.
It is perfectly possible to write any program in Delphi without resorting to explicit pointers. The modern trend away from explicit pointers is down to the observation that explicit pointer code is more prone to errors than the alternatives.
I don't think there's any real reason to carry on using explicit pointer code in Delphi. Perhaps very time critical algorithms may push you that way, but I'm really struggling to think of anything that is significantly better implemented with pointers than with the alternatives.
Personally I avoid using explicit pointers wherever feasible. It generally makes code easier to write, verify and maintain, in my experience.
1) Classes are pointers. Strings are pointers. The compiler pretty much hides this from you but you do need to understand this when debugging.
2) Any sort of tree structure needs pointers.
I use a lot of custom data structures in my programs (for instance, in my own scripting language /interpreter/, where I store the structures, or "records", used in this language - these can contain other records and the nesting is unrestricted). I do this at the very lowest level, namely, I allocate a number of bytes on the heap, and then I read, parse, and write to these completely manually. To this end, I need pointers to point to the bytes in the allocated blocks. Typically, the blocks consists of "records" that reference each other in some ways. In addition, many of these structures can be written to file (that is, I have also designed my own binary file formats), simply by copying from the heap (in RAM) to the disk byte-by-byte.
Pointers (memory addresses) are a basic CPU type to access memory. Whatever language you use to write an application, when it comes to the CPU it has to use "pointers" to work.
Thereby they are a low-level type which allows a huge degree of versatility, at the price of a somewhat more complex management and the risk of accessing or writing the wrong memory if not used correctly.
You could let a language translate your data to pointers and memory buffers, or use pointers directly if the language allows for it. Being able to do it allows for direct and optimized memory access and management.
I thought I could add my salt to the soup, but the answers above say it mostly all. There's one more thing though. I remember being scared when I saw all those referencing and dereferencing operators (in different languages) and all the magic that was done with pointers. I didn't dare to look the devil in the eye for YEARS. I preferred to ineffectively copy data instead of going down the pointer path.
Today though, I do love pointers. Working with pointers makes you aware of what happens under the hood. And it makes you aware of the memory you are playing with (responsibly). Practically it allows you to code more effitiently and consciously! Last but not least it turns out to be quite fun to play with such simple but powerful toys.
My superficial understanding of variables in f# suggests that declaring a variable to be 'mutable' and using a 'ref' variable essentially both do the same thing. They are both different ways to address the same underlying issue - a limited and structured allowance of mutability in a functional language without having to resort to the IO Monad. That there is a technical different has been 'abstracted' by my understanding.
If this is the case why can't closures capture mutable variables, but they can capture ref instances?
More generally, what is the technical different between the two forms that allows this difference?
What is the purpose from a language design point of view of introducing two mutability shortcuts rather than just one?
I'm sorry if this is a multi-parter, but they all seem related.
See
http://lorgonblog.wordpress.com/2008/11/12/on-lambdas-capture-and-mutability/
especially the "language design commentary" section (I'd quote it here, but it doesn't stand alone well, you need the whole blog entry for context).