Could anyone of you imagine concrete situation, where the static type system is more an obstacle than a helpful tool?
The proceedings can be downloaded from the POPL webpage.
I find this extremely exciting (not only because I didn't get funds to attend POPL this year). To my knowledge, this is the first time that this is done in POPL/ICFP/PLDI; electronic proceedings were previously only delivered to attendees, with an explicit request not to share them.
I am not sure what is the reasoning that make which people decide to do it this year, or not to do it before. I hope that the proceedings will remain available after the conference (next week), and that this idea will be adopted for the years to come.
Here is IDE screenshots
Github & source code (compiler & language)
Very simple minimal math language with ideas like STEPS
I'm looking for somebody who can help with beta-testing & demo making, language update, etc.
Dimension types are extremely useful for preventing errors in programs that manipulate physical quantities. There are several Haskell libraries for them, F# has a built-in version, etc. (I've read about a nice Python package that addresses the same issues dynamically, which may be a good source of inspiration, though my personal interest is in static approaches.)
Of course there is the thorny issue of selecting a basis with which to express dimensions. The dimensions of the SI base units are a common choice. The dimensions of the cgs units are another appealing choice in some respects, though you do need to deal with fractional powers (e.g.
Since my target users are engineers, I am inclined to choose the dimensions of the SI base units. For simplicity I will set aside the question of additional user-defined basic dimensions, because it is only slightly related to my primary question.
There is broad agreement (for decent reasons) that angles are dimensionless, and there is a long history of mostly treating them that way in the mathematics, physics, and engineering literature. Yet pragmatically, serious errors can arise when revolutions are mistaken for radians or angular velocities are confused with frequencies. Factors of 2 pi are liberally sprinkled all over the place, and it is pretty easy to forget or misplace one.
This form of confusion and traditional resort to name-based disciplines seems very much like the type of confusion and lack of formality that dimension types are intended to address. I find that I much prefer my toy system where angles are treated as dimensions to the version in which they are not, because it requires me to annotate all the places where numbers turn into angles (and vice versa) with the "units" that I am intending to use. This naturally leads to extremely good documentation of interfaces, serialization formats, and interoperation with external code.
There is a related problem where torques and energies share the same SI dimension (
Should angles be modeled as a dimension for software engineering purposes? Should they be modeled in some other way? Should they be left implicit?
(To throw another wrench in the works, similar remarks apply to solid angles, although they may arise considerably less often for my target users. It also feels arbitrary to stop after 3 dimensions, and I assume--although I am not familiar with one--that there is some sort of generalization of solid angles to n-dimensional space.)
I haven't seen this discussed here yet: http://www.puzzlescript.net/
It is an HTML5-based puzzle game engine that uses a simple language for patterns and substitutions to describe game rules. For example (taken from their introduction), the basic block-pushing logic of a Sokoban game can be given as:
[ > Player | Crate ] -> [ > Player | > Crate ]
This line says that when the engine sees the pattern to the left of
Rules are matched and applied iteratively at each step (i.e., when the player acts), until there are no more matches, and then movement takes place. There are mechanisms for influencing the order in which rules are run, and for forcing subsets of the rules to be iterated. By default, rules apply to both rows and columns, but horizontal- or vertical-only rules can be created.
It is an interesting example of a very narrowly-focused DSL, based on a (relatively) uncommon model of computation. It's also very fun to play with!
I've recently been looking at a notion of interfaces for BitC. The language already has type classes in the style of Haskell, with all of the pros and cons of these. The deeper my dive into interfaces, the more confused I became about the difference between interfaces and type classes. This either means that I'm hopelessly confused or that I've stumbled into something useful. I'm sure the LtU audience can explain my confusion. :-)
BitC has object-style methods in a syntactic sense, but no virtual methods or inheritance. In such a language, object methods are sugar. We also have a notion of interfaces, currently called "capsules". A capsule provides existential encapsulation of an underlying object combined with a known set of methods. In contrast to Java-style interfaces, a capsule type has an explicitly invocable constructor. This means that a capsule can have non-default instantiations for a given underlying type T. Capsule constructor arguments corresponding to method initializers are constrained to be compile-time evaluable. This has the consequence that every capsule "method table" is a compile-time constant in the same way that every type class instance method table is a compile-time constant.
Capsules may have either static of conventional methods. A static is method does not receive or require a reference to the encapsulated object.
The lifetime of a capsule instance is guaranteed not to exceed the lifetime of the object (if any) that it encapsulates.
Q: How is a capsule type consisting exclusively of static methods different from a type class, if at all?
MemorySharp - Managed library for memory editing, and Fasm.NET - Managed wrapper to use the FASM compiler from .NET applications
(Obviously of possible interest for some language implementors)
By Jämes Ménétrey (aka "ZenLulz") :
MemorySharp is a C# based memory editing library targeting Windows applications, offering various functions to extract and inject data and codes into remote processes to allow interoperability.
The goal of this library is to provide a safe, powerful and easy to use API, keeping the remote process as clean as possible. This library is said Out-of-Process, in other words it does not need to be injected within the target process. Only your application loads MemorySharp, ensuring that only the requested operations are executed in the opened process. For the moment, the library only supports 32-bit development.
Also on GitHub: https://github.com/ZenLulz/MemorySharp
and on NuGet: http://www.nuget.org/packages/MemorySharp/
A managed wrapper to use the FASM compiler from .NET applications.
This library is written in C++/CLI and embeds FASM compiler as a linkable Microsoft COFF object. As FASM compiler is built in 32-bit, the managed assembly can only be used within a 32-bit development.
The branches match with the current versions of FASM compiler as published on the official website.
Also on GitHub: https://github.com/ZenLulz/Fasm.NET
and on NuGet: http://www.nuget.org/packages/Fasm.NET/
Both librairies come with the MIT license:
* MemorySharp, since 9/14/2013 (Announcement)
* Fasm.NET, as of v2.0.0
Excerpt from MemorySharp's feature list :
* Check if the process is debugged
* Allocate and free a chunk of memory
* Enumerate all modules loaded
* Create and terminate threads
* Enumerate the windows of the process
* Assemble mnemonics
(... and more)
Fasm.NET's feature list :
* Assemble mnemonics on the fly
(A few FASM links)
Happy new year 2014, everybody, "by the way" :)
And a random fact, as of 01/01/2014:
both the CLR and C# are still in their teenage, for just a couple more years to come... ;)
I'm looking at how different statically typed languages tackle the problem of letting you define types and define interface implementations for those types.
For example, to define an implementation of interface I for type T, Java uses interface methods, Haskell uses typeclasses, Scala uses implicits.
The disadvantage of the Java approach when compared with Haskell/Scala:
Haskell approach vs Scala approach:
What do you think is the "right" way to do this? Given my limited knowledge right now, I think I'd go with something Scala-like and maybe make some modifications. For example, I think the "only one implementation per type" restriction of Haskell might be useful.
Is there a good survey of the different approaches?
So I've been working on a new language for a while and the topic of how to implement closures came up. I have seen closures usually implemented on the heap or with some malloc region of memory. This seems suboptimal so I thought of it some more and came up with the idea of using type unions to store local variables. This way closures could be passed around on the stack normally.
Obviously this has downsides if you hold too many local variables or few large ones. Since this has probably been done before, I would like to ask the community what their experiences have been with alternative closure implementations.
Also to note, specialization of functions is an option that could help reign in the size of the closure struct.
Coq developpers recently put together a survey of their tool usage, which will hopefully inform future evolutions. From Matthieu Sozeau's announcement:
Active forum topics
New forum topics