kagebe

A common mistake for us Germans. Especially if one hasn't worked in an English-"speaking" environment (US/UK/..., international company or publishing in English academic proceedings/journals) and/or learned how to write idiomatic English. Abusing and over-using relative clauses is a favorite speaking and writing technique in these parts. ;)

I use it to share passwords with one other person via a suitably restricted git repo, works perfectly fine.

Edit: See sister comment by runejuhl.

Linear types are a more fundamental concept (in functional programming and type theory) than reference capabilities, since they apply to values of any type and a linear type system does not need any references or objects that have state and behaviour.

The "linearity" of linear types comes from the typing rules of values with a linear type: They must be used exactly once. In fact, the simple typing rules of a linear type system allows one to implement all manner of capabilities and especially capabilities for references.

Partial evaluation (whether online/offline) is not implemented in any (current) C/C++/Rust compiler, for very good reasons. "Global Optimizations" may do a significant number of optimizations that partial evaluation may do and some that partial evaluation is unable to do (depending on your abstractions, e.g. code motion).

I totally agree that these kinds of optimizations are unnecessary for most applications, which is why we target and compare against High-Performance Computing algorithms and DSLs. Have a look at the publications and comparisons with OpenCV and similar.

If you want to wrap AnyDSL HPC code with some other language, sure. There is an experimental compiler flag --emit-c-interface right now. :)

However, most of the current HPC DSL frameworks generate some C code from Python/etc by stitching together library calls to BLAS/etc. in some haphazard, mostly untyped way - not ideal.

But I'd say that front-and-center: "AnyDSL is about creating ultra optimized cross-hardware performance critical code, targeting LLVM, CUDA, and OpenCL code based on the same high level code." All of the talk about theory is just distracting people from the actual "killer app" of AnyDSL.

Thanks, I agree. Presentation could definitely use some work. As it stands, it's mostly a presentation of the published research work and not yet addressed to users.

In AnyDSL, Impala is a host language for shallow-embedded DSLs. No parser generators/grammar required/needed as that is not the point.

From the last paragraph of the overview section: "The DSL developer just reuses Impala's infrastructure (lexer, parser, semantic analysis, and code generator). He does not need to develop his own front-end."

We should probably emphasise that and restructure the introduction text.

In most compilers today, the front-end generates an AST, from which an(other) intermediate representation (IR, named Thorin in AnyDSL[1]) is generated. On that IR, the "middle-end" already optimizes a lot and the back-end finally generates whatever output formats the compiler targets (for AnyDSL: LLVM, CUDA/NVVM, OpenCL).

* In AnyDSL, the front end takes the code and compiles it into, well, the same language, only with decreasing levels of abstraction from the hardware.

The AnyDSL language (Impala) compiler works exactly like my compiler description above. However, the levels of abstraction you refer to here, are all written in the same "top level" language (a "host" language in DSL literature terms) and are basically just libraries on top of each other. The @ on the iterate call partially evaluates the call (aggressive inlining and specialization) at compile time on the Thorin IR. This feature allows the compiler to remove the layers of abstraction again and bake the code together, like you say.

But yes, it still feels fundamentally like a compiler. Only a compiler where you can't just link in existing C-based libraries, because then it wouldn't be able to do its magic. So you therefore need to reinvent all the wheels?

Yes, it is a compiler - but you don't need to write one for your DSL (unless you really need other syntax). You're correct with regard to external libraries: If you need to remove the abstraction overhead (e.g. function calls) of your external library for performance reasons you'd need to re-implement that in AnyDSL. However, that holds true for any DSL framework and compiler, unless you compile everything to (C) binaries and do partial evaluation at link time. But at that point you've already lost a lot of information that a compiler can usefully exploit to generate better code: more abstract types, higher-order functions, scheduling info, alias info, etc..

[1] See the paper: http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf

Xtext and AnyDSL have very different goals. Xtext is mostly about Syntax and IDE-Support, while AnyDSL is about compilation. With Xtext you'll get support for defining the grammar of your language, but you'll write your own compiler for your DSL - the DSL is "deeply-embedded" in the host language Java, that is: represented as a Java datastructure. In AnyDSL, you don't have any support for custom syntax - all your DSLs are basically just "libraries"/types/functions in the host language Impala - a "shallow" embedding. Java examples of shallow embedding are most "fluent interface" libraries, e.g. jOOQ[1].

This has the benefit that you don't need to know about compiler tech to implement your DSL. However, a domain-specific compiler can optimize using domain-specific knowledge and potentially generate faster code. For this reason AnyDSL/Impala provides online partial evaluation with the '@' operator, which aggressively specializes functions and evaluates at compile time. With the right DSL abstractions, this can result in generated code that is as fast as hand-tuned code.

For a more complete view of the relation between partial evaluation and DSL embedding, have a look at the GPCE'15 paper[2].

We totally agree that the website and documentation (there is some in the github wikis) is lacking at the moment and we're working on them. However, AnyDSL is still a young research project.

[1] http://www.jooq.org/doc/3.9/manual/sql-building/sql-statemen... [2] http://compilers.cs.uni-saarland.de/papers/gpce15.pdf

In related news: Radu Grigore "Java generics are Turing complete" POPL'17 Preprint: https://arxiv.org/pdf/1605.05274

As far as I understand, for LMS: Those types T for which one has implemented needed operations for the Rep[T] type.

Shameless plug: For another comparison of MetaOCaml, LMS, Terra and AnyDSL (our approach) under the lens of staging/partial evaluation see our paper from GPCE'15: http://www.cdl.uni-saarland.de/papers/gpce15.pdf

How about asking your customers, instead of stalking them by default?

Even telephone hotlines warn you that the calls may be recorded and give you (at least) a way to opt out. No site ever gave me such an option, but my browser has it - so I'm using it indiscriminately.

If you want my trust, give me an (opt in and later opt out) button, limit your tracking as much as you can (time, do not correlate with others, personal info, etc.) and as much information about your tracking as you can and what you use it for. In fact, give me an easy way to see what you have profiled and give me an option to clea(n/r) it.

I guess that sounds like hard work. Maybe Piwik can be extended to provide such things? Does it already do some of that?

I think it's not only the interactive elements, but also the way information is displayed. I actually think he (and others) might benefit from a really responsive desktop environment, especially compared to the Windows floating window manager.

The videos you linked to show this very well in my opinion:

- In the longer one with Hawking and the System he's using it to type and read Wikipedia, all the while quite some screen estate is wasted with (for him probably unusable) title bars, partially hidden desktop icons in the background and the browser partially behind his input software.

- The "data entry" video shows Notepad being opened and being partially hidden by the input UI.

That does not seem useful. I would rather use apps that automatically fit themselves to available space and predefined layouts for multiple apps or a dynamic tiling approach.

Wasn't the original goal 'Reducing the coupling between our core packages'? How is a fully display of all the transitive dependencies necessary for that?

The goal already implies, that what's important here, are the (both direct and indirect) dependencies between their packages. To understand those better, you do not need to draw a dependency to any Go core library or other 'uninteresting' library, which would be a leaf in the directed graph or whose transitive dependencies are only 'uninteresting'.

I think those chord graphs might actually be the way to go, if you'd just restrict the amount of packages to the relevant ones.

It might be nice to automatically add references to source lines where those dependencies are needed to the tooltip.

Now, I'm very strongly influenced by my german culture, but the article made me curious: What kind of history does this particular house have, except maybe for its looks? The article just states that the neighbours think it's historic and they seem to imply that them being "thight and political" should also sway Kevin Rose. The petition isn't accessible at the moment.

Now, I don't think his new building would really fit, but why isn't the neighbourhood protected in some way? E.g. my hometown isn't particularly old for german standards, the oldest houses are about 120 years old, but there are still many rules concerning new buildings: The kind/colour of the roof tiles (couldn't build a flat roof), maximum height, etc.. However, they aren't protected against razing either, I think.

but based on her description she would have had time to properly use a gun in defense

I quote the article: "She pulled the knife out further and pushed it into my blue purse" Into the purse that would have contained the gun. I think she would have been stabbed before she could have reached inside.

No one intend on robbing you up close and personal is going to pull out his knife from 15 feet away or announce to you from that distance, especially in such a public situation, that he's going to rob you. He wants to threaten you with a knife, not with his voice.

And this is what I mean with "training": the reflexes to pull your gun instinctively when seeing a flash of a weapon in pretty much any situation, in this case: With your headphones on and watching some movement on your phone, as she was doing.

Maybe most gun owners are well trained enough to hit moving people at some distance, but I would argue, that nearly none of them are well trained enough to hit somebody who is moving within arms reach and will try to hit you with a knife/grab your arm/etc.. Most martial arts practitioners will say that they are not well trained enough to evade/fight somebody untrained but handling a knife.

you think there's still an ethical issue?

I will argue ethics whenever the outcome is death, especially when there are bystanders and even more when the other option is to lose some possessions.

If someone was caring a gun, they could have helped. If she were caring, then she could have put an end to this nightmare herself.

No, that is not how it would work out in most (if not all) cases. Especially not in such a public place. And especially not if the gun was contained in something, e.g. her purse.

Even if that person were a great shot, in a (even moderately) close combat fight with a knife-wielder, she would most likely not be able to pull/unlock the gun before being stabbed, or miss and/or hit others or just be plain too scared/untrained to keep that much control.

Even if it worked, there would be the question of ethics and legality of wounding/killing another person to save her possessions. The legality may not be an issue in (many states in) the US, but even there not always a clear case and most likely will have some legal procedure.

If she were able to use the gun for intimidation and get the assailant to run away, that might work, but the attacker is obviously beyond quite some normal mental restrictions when threatening to kill her in a public place and might not easily be deterred.

Guns are the perfect tool for killing people when you know you want/plan to kill people. They are effective in wounding too, if you're able to hit where it doesn't kill. They are mostly useless in not getting wounded/killed by someone who wants to wound/kill you.

Well, then I restate: "Those proofs were not proofs of the theorems they/Bloch wanted to prove." The point being: Proving is not just about your proof, but also about writing meaningful Theorems, or as it is more commonly called when programming: specification.

The implementer is not free of proving her implementation correct, given that the original algorithm was proven correct on some theoretical computational model. Bloch argues that, since the original proof is not sufficient, the implementer needs to test. I'd add, that if the implementer would adapt/redevelop the proof for her implementation, she might forgo testing. Of course, this is practically impossible for many execution environments.

While you may be right with regards to the file size (although most SSA-representations are not built for small size, there is quite some potential to reduce it, imho), you'll have to do register allocation/spilling/etc. in your VM/compiler anyway and that is easier and faster on SSA[1, and more]. The dominance frontiers algorithm is actually not that good imho, there are better options[2], especially considering that one may not want to construct an unnecessary dominance tree in an Interpreter/VM. Now, I have no experience how much overhead SSA-deconstruction inflicts when lowering to machine code.

[1] http://www.cdl.uni-saarland.de/projects/ssara/ [2] http://www.cdl.uni-saarland.de/projects/ssaconstr/

Yes, I'm associated with that group.

In my opinion, the main take-away here is that the proofs were, obviously, no proofs. If you program with modulo arithmetic you have to do your proofs with modulo arithmetic. If you use IEEE floating point, say goodbye to your theorems about real arithmetic.

If you forget/omit a single fact about your target platform/machine/api (whatever axioms you found your reasoning on) in your proof, it may be worth nothing.