Hurl, the Exceptional Language

I mean, it’s a language based around exceptions for flow control, I think the “easy to reason about” ship has sailed.

Sometimes I wonder if I'm exceptionally (haha) talented as I personally find the impact of exceptions on flow control pretty easy to grasp. But based on my understanding of other advanced computer language concepts, which is pretty lacking in some regards, I come to the conclusion that it can't be too hard, and people make a lot of fuss about it for no particular reason.

The imported files should really hurl their exported functions, and the importer needs to catch it into a variable.

i think you mean to to say "has sunk"

I agree, side-effecting imports add to the spooky action at a distance aesthetic.

Python has this in a slightly different spot. Most pypi packages have the name and module aligned but it’s only a matter of convention, and there are some common deviations like the pyyaml package providing the yaml module.

I'm looking at you, Go.

I’m so confused by this. Unless you use a dot import, isn’t this just bar.*?

This is normally how it works, no?

I enjoy Elixir but this situation is quite unfortunate, there is alias, import require and use for referencing / pulling in code external to a file in some way or another, plus the possibility of calling a function from another module directly by name without an import statement using the module name – and the most annoying part of it is that none of these give an indication of which file the other module is from, which is like 50% of the utility of an import statement for me.

Instead there is this pattern of naming modules based on the file path they are located in, which is not enforced.

Let's not write software and especially programming languages which assume or depend on users having access to advanced tools that require a monthly subscription.

I use IntelliJ for work and it shows clearly where some reference

Useful when writing the code but not much use when reading the code.

    import foo(42, FULL_OF_EELS) as foo

    -:1:8: E0012: Initializer of module "foo" has 3 arguments, 2 were provided.

As an implementation detail, exceptions are usually much more expensive than just popping the stack, as computation is needed for each frame you traverse.

Having both throw and return is like regex: now you have two problems.

Unless you're using exclusively Java-style checked exceptions, then there literally (literally!) is huge difference. That is:

    def main():
        try:
            my_a = a()
        except ExA, ExB:
            my_a = None
        ...
         
    def a() -> A:
        ...
        my_b = b()
        ...

    def b() -> B:
        ...

BUT if b begins raising ExC instead of ExB, then that will break main at runtime. That is, main needs to be aware of what b could raise, even though it doesn't directly call it.

I dislike Go, but I understand why people like most of its decisions.

I cannot fathom why people think it does error handling well, though. The codebase I work in has _so_ many errors that are completely ignored, and errors are a lot harder to track down.

These problems can be solved by writing better code, but the problem is that it's, of course, hard to write good code.

Java's exception handling has problems, but at least it gives you nice stack traces and you can't forget to propagate an exception.

I think people like it because the control flow of a given program is more obvious when you write it that way. No one can "throw Foo" three libraries down from their caller as an "API". See https://go.dev/blog/errors-are-values

I prefer to build result-passing, no-exception-throwing systems out of an exception-throwing core where the language itself may throw exceptions but the thing I build from the language always returns result.

Elm is an extreme case where indexing into an array returns a result type instead of an exception when the index is out of bounds, unlike most languages including Haskell.

Maybe my program logic is intended to always access only valid indices in an array, but here I'm given a result type where I have nothing to do in the error case since my code is never intended to reach that case. I would rather let the language throw an out-of-bounds exception here to tell me that my implementation is incorrect while I'm testing.

Same with libraries in a language. It really depends on the use cases of the library you're writing whether results or exceptions are better. The most convenient thing for the user of a library would be to provide both exception-throwing and result-passing alternatives. This is what the OCaml standard library does as well.

I think once Java has finished up exception switch-case it will be a model followed by other languages. Being able to catch exceptions at both, method and transaction boundaries will be a boon for readable control-flow.

Why do names have to come from the English dictionary? Google can't (couldn't) be found in one.

I have a proposal: let's accept as a given that all single words have been taken, and require all new languages/tools to be named with either multiple words, or by including a special character.

Note that C# (aka C Sharp) was way ahead of its time by including both options.

Everyone understands that, but when the project name you're copying is popular enough (12k stars meets this threshold, personally) and is still actively used and developed, a name change should be more seriously considered as to avoid confusion (which I exhibited, fwiw).

lol

This industry pumps out new model languages every week, but is unable to generate new names with simple Markov chains?

Anyone giving a project a name that is already taken is a clown

Note that the specific naming of hurl.dev is not random: hurl is a wrapper for curl, where the requests are stored in a plaintext file.

So hurl.dev didn't roll dice and got hurl, but consciously got a close sounding word.

In that sense, that makes one claim over the other a little more valid, in my mind, though you're right that clashes will have to occur.

I did get confused extra hard by the url = hurl.wtf, when hurl.dev is so close yet about different topic.

OCaml 5 essentially has it, as "effect handlers". It's how lightweight concurrency is implementated.

You can think of algebraic effects kind of like:

From callsite Foo, I call out to a function with a known name, Bar, with one or more parameters. The runtime (or sufficiently smart compiler) searches upwards in scope, for a handler Baz that provides the function with that name. Baz's Bar is then called, with both the provided parameters, and, crucially, a function that is "the rest of Foo."

So, an implementation of Exception with effects would ignore the resume, and look something like:

    define_effect Exception {
      // only one function provided by Exception, but could have more
      throw(String)
    }
    define_handler printExceptions {
      throw(msg, resume_func): { println(msg) }
    }
    define_func getPage(url) {
      request = http.get(url)
      if not request.ok { throw("Could not download") }
      return page
    }
    // main entrypoint
    withHandlers printExceptions {
      page = getPage("https://cheese.com")
      println(page.text)
    }

    define_handler onErrorResumeNext {
      throw(msg, resume_func): { 
        println(msg)
        // YOLO, call it anyways
        withHandlers onErrorResumeNext {
          resume_func()
        }
      }
    }
    withHandlers onErrorResumeNext {
      page = getPage("https://cheese.com")
      println(page.text) // Probably uninitialized - a better  :P
    }

    // Stream - potentially infinite and/or asynchronous iterables
    // basically just like python generators
    define_effect Stream {
      emit(item)
    }
    define_handler toList(accumulator) {
      emit(item, resume_func): {
        if item == nil {
          return accumulator
        } else {
          accumulator.append(item)
          withHandlers toList { resume_func() }
        }
      }
    }
    define_handler take(how_many) {
      emit(item, resume_func) {
        if how_many == 0 {
          emit nil
        } else {
          withHandlers take(how_many-1) { resume_func() }
        }
      }
    }
    define_func fib_stream() {
      a, b = 0, 1
      loop {
        emit a
        a, b = b, a+b
      }
    }
    // Usage
    first_five = withHandlers toList {
      withHandlers take(5) {
        fib()
      }
    }
    println("The first five fibonacci numbers are", first_five)

    Each.toList do
      a = Each.range 0 5
      -- beginning of resume_func f_A
      b = each [1, 2, 3]
      -- beginning of resume_func f_B
      guard (a < b)
      -- beginning of resume_func f_C
      (a, b)
    -- yields
    [(0, 1), (0, 2), (0, 3), (1, 2), (1, 3), (2, 3)]

    results = []
    for (a = 0; a < 5 ; a++) {  // for each a, call f_A(a)
      foreach b in [1, 2, 3] {  // for each b, call f_B(b)
        if not a<b { continue } // if a<b, call f_C(a, b)
        results.append((a, b))
      }
    }

Exceptions/hurl = exactly 0 resumptions toss = exactly 1 resumption effects = 0..many resumptions

[1]: https://share.unison-lang.org/@unison/base/code/releases/3.5...

More general than the toss keyword even. If you're interested in concrete examples, you might have a look at the koka documentation

It's a very restricted form of conditions, since it only allows resuming.

A conditions system would subsume both `toss` and `hurl` (because you can have an unwinding restart), as well as provide more flexibility: the condition can provide multiple user-defined restarts and the handler can pick between them (statically or dynamically), as well as feed content back into the signalling function.

For instance a classic CL restart is `use-value` which is the conventional name of restarts feeding a default value in case of missing or invalid item.

So let's say that you have a hashmap type, on lookup failure it could trigger a condition with a `use-value` handler to feed it a default value (possibly dynamically constructed), or abort/unwind, it could also have a restart to insert-and-return the value (so would behave as a `defaultdict`/`putIfAbsent`)

Unfortunately, it's not open source, but it's still hilarious :)

This is fantastic

Another alternative would be to use macros instead.