quorum-developer — A list for asking and answering questions about the Quorum programming language.

[Quorum-developer] Empirical studies and error-handling

[Kyle S. <kyl...@gm...>]

Greetings all! I asked this question via a facebook message to the Quorum
page and was told I should post it here.

Is there one unified list of empirical studies that have influenced the
design of Quorum so far? I don't see anything like this on the Quorum
website, but it seems to me that this would be extremely useful given
Quorum's core value proposition of being an evidence-based language.

More specifically, I would like to know what drove the decision to use what
amounts to unchecked exceptions for error handling. I am personally
unfamiliar with any scientific literature on approaches to error-handling,
but I think it's definitely one of the most important aspects of
programming languages and frameworks, and my professional opinion is that
unchecked exceptions seem unlikely to be the best error-handling mechanism
for languages to use. Again, I don't know if this has been empirically
studied, though I definitely think it should be.

One good discussion of how to approach error handling (full of anecdotal
evidence, of course, and from an ultimately failed project no less) is
here: http://joeduffyblog.com/2016/02/07/the-error-model/

I have not used M# (the C#-based language discussed in the blog post
above), since it's not currently widely available. There appear to be a
couple of extremely important insights in the blog post, though:

 * The error model should distinguish between violated assumptions (i.e.
errors from which it's unlikely the program can recover automatically,
typically logic errors) and expected recoverable error conditions.
Different strategies (e.g. asserts and exceptions) should be used for the
two types of errors.
 * If exceptions are used to handle errors programmatically, they should be
considered *expected* parts of control flow and should therefore be
lightweight (like error codes). There is therefore limited value in
scraping stacktrace information from the runtime environment and packaging
it into exceptions, since programmers (in this model) should expect
exceptions to be caught--in which case the stacktrace will be ignored. (The
cost is obviously not as great when the program is running in a VM, but the
point remains that it should be superfluous in a program with robust error
handling.)
 * Exceptions (whether checked or unchecked) are implicitly part of the
exposed behavior of a function; this may tip the balance of the "checked
versus unchecked exceptions" debate toward "checked."

Again, M# isn't available for use, and the project described in the blog
post failed, so these considerations in no way meet the standard of
evidence required to even consider making a change to the Quorum language.
However, various languages (e.g. Rust, which is mentioned in the blog post
for this reason) *do* have similar error models to what the blog post
describes, so it seems entirely possible that studies on the costs and
benefits of different error model semantics *could* be performed. This
seems highly desirable to me.

[Quorum-developer] failure trying to build from sources

[Richard N. <rjn...@gm...>]

Following on from the conversation here:

https://quorum.atlassian.net/browse/QUOR-124

1) Build just using sources

I tried to build the ParserPlugin with ant but it failed:

https://gist.github.com/rjnienaber/a69518f87ef17e588a1f

Is there another dependency in this step?

2) Build using beta Compiler

If I try using the Quorum3 beta compiler, I get the following:

(SourceCode) $ java -jar Quorum.jar -name Quorum -compile main.quorum
TypeCheckTesterGenerated.quorum (etc) ....

Error: The working directory specified does not exist, or does not
correspond to a directory:
/Users/richardn/projects/quorum-language/Quorum3/SourceCode/Library/Standard/Plugins/

Richard