7 ms·

For anyone designing a programming language, enforce namespace to includes/imports! and if possible, don't allow top level side effects. let foo = include

• moomin 2y ago
  I mean, it’s a language based around exceptions for flow control, I think the “easy to reason about” ship has sailed. (Don’t confuse this with me thinking this project is worthless, I think it’s art.)
  • infogulch 2y ago
    I agree, side-effecting imports add to the spooky action at a distance aesthetic.
  • karma_pharmer 2y ago
    i think you mean to to say "has sunk"
  • groestl 2y ago
    > 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.
    • eyelidlessness 2y ago
      It’s largely difficult because either: - you’re working in a language that doesn’t have checked exceptions, so the set of potential errors and the set of potentially error-raising calls is infinite but unknowable - you’re working in a language that has checked exceptions, and you hate that it makes you do work, so you catch-rethrow runtime errors that recreate the first scenario - you’re working in a language that has checked exceptions, but someone else did the second scenario so you’re in the first scenario anyway
      • xboxnolifes 2y ago
        The unchecked exception example doesn't seem any different than using a dynamically typed language and reading return values, and exceptions seem to get significantly more hate than those.
        • eyelidlessness 2y ago
          Because even in a dynamically typed language you can generally go look at what the function returns. You can’t look at what it throws without walking the entire call stack and inspecting the source code of the runtime.
      • groestl 2y ago
        Other programmers tend to be bad at reliably cleaning up resources such as file handles, locks etc, so I need to inspect the whole invocation tree anyways to have an understanding of what runtime implications I've summoned by invoking other people's code. As for myself, I've lived through the hell that are checked exceptions in Java. You learn that compositionality and checked exceptions are at odds when you try to insert a remoting layer into an application that has grown without IOExceptions. Then you learn that it's actually not necessary to know the set of possible errors, just make sure that you're not a bad programmer as in my first paragraph, and everyone will be fine. This is also something that you can learn from Exceptional C++.
        • fiddlerwoaroof 2y ago
          Yeah, I’ve never understood the complaints about exceptions either: most of the time you want the exceptions to just bubble up anyway because, in that case, you only have to think about the contracts of the functions you interact with and not about the unusual states you might be in. Return-type or return-value based error handling has always seemed to me to be significantly worse.
    • retrac 2y ago
      Flow control involving recursion is already well into the weeds. Recursion and exceptions is probably a nightmare for someone not fond of ML or Lisp.
      • groestl 2y ago
        But why? I don't get it. You call something. It can break. It will break. Treat it as such wrt to resources you've allocated. You can ignore error details here. At the highest level of your application (and at a few critical places, executors, retrying strategies etc) handle all the exceptions you know of, and implement a sane default for everything you don't know. Done.
    • moomin 2y ago
      Not really, what’s happened is that everyone’s so scared of exceptions they only use them in extremely confined ways. These ways are relatively easy to reason about. But the full fat arbitrary goto around your call stack is avoided.
  • andypants 2y ago
    The imported files should really hurl their exported functions, and the importer needs to catch it into a variable.
    • fmbb 2y ago
      Oh, dependency injection?
      • kdmccormick 2y ago
        Ha!
      • cobbal 2y ago
        Maybe even dependency ejection.
    • ntietz 2y ago
      That’s a great idea. I’ll have to do that for the next version.
• BoppreH 2y ago
  This also allows one to pass parameters to `foo.init()`, something you cannot do with naked imports.
  • Joker_vD 2y ago
    import foo(42, FULL_OF_EELS) as foo -:1:8: E0012: Initializer of module "foo" has 3 arguments, 2 were provided.
    • endofreach 2y ago
      In case we're still in the design phase of the language, named arguments would help around that (coupled with a good IDE)... but yeah, probably i agree with how i interpret your comment. Shouldn't be like how parent proposed imports work. Would lead to too much pain.
• remram 2y ago
  Preferably enforce that the namespace matches the include/import statement, if the statement doesn't use an explicit name binding... import "foo/bar" should make foo.* OR bar.* available, not bazz.*. I'm looking at you, Go.
  • mikepurvis 2y ago
    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.
    • remram 2y ago
      Ah yes, Python's package manager has it wrong also. But at least Python the language is clear, so you can know "import foo" or "from bar import foo" creates a name "foo" in your file. Go has no such limitation. Imagine doing "import pyyaml" and "yaml" is the name defined...
      • jakewins 2y ago
        Wait I’m so confused by this - this is the opposite of how I thought it worked? Go import creates exactly the symbol you mention in the import statement, like “import fmt” creates a symbol “fmt”? Can you give an example of what you mean?
        • sweeter 2y ago
          Yea, this is correct. ```go import ( "net/http" "os" "github.com/anacrolix/torrent" tstor "github.com/anacrolix/torrent/storage" ) ``` would import as: http, os, torrent and tstor. That guy is mixed up.
          • remram 2y ago
            I don't know what this proves. See example above for an example of exactly what I've said.
• Wonton56 2y ago
  I do not disagree, but I use IntelliJ for work and it shows clearly where some reference is imported from and let you navigate to it with a shortcut. VSCode does similar things with plugins and LSP, just much worse. I cannot work in VSCode because navigating code is so slow. Is this suggestion only useful when you don’t have such tools? It seems impossible to me that people can live without them, at least in a professional setting.
  • kwhitefoot 2y ago
    > 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.
  • sspiff 2y ago
    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.
• packetlost 2y ago
  This is the chief problem with Python and most Lisps
• manusachi 2y ago
  Agree! For that very reason in Elixir `import` is discouraged in favor of `alias`
  • __jonas 2y ago
    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.
    • smj-edison 2y ago
      Doesn't Elixir (and Erlang for that matter) specifically require a module to not be in a specific place in order to have hot reloading of modules? Though I suppose you could still have hot reloading and require a module to be in a specific place.
      • throwawaymaths 2y ago
        Nope. Elixir doesn't care where your module lives. (You can even "nest" modules, though it's not a great practice)
      • __jonas 2y ago
        Not sure, could be that Elixir stuck close to Erlang's module system yeah. But for example gleam [1] is another language on the BEAM (compiles to Erlang), that has a much nicer approach: All imports must be declared explicitly, and the import path in your local project is based on the file structure so you always know where something is imported from [2]. [1] https://gleam.run/ https://gleam.run/ [2] https://tour.gleam.run/basics/modules/ https://tour.gleam.run/basics/modules/
• lhfasufdowedfs 2y ago
  Agreed 100%. I forked Ruby to have require that didn't clobber the symbol table but then lost interest in Ruby itself because the ecosystem seems unhinged on shared global mutable state.
• djha-skin 2y ago
  I mean, for anyone designing a programming language, don't use exceptions as the chief means of control flow. Critiquing a joke design is of dubious usefulness, at best :)
• sergiotapia 2y ago
  This is precisely why I stopped using Nim. I was going crazy trying to remember what functions were called etc. I could do from x import nil but it felt like fighting the language.
  • xigoi 2y ago
    Requiring namespaces would break dot call syntax, which is one of Nim’s main features.
    • firesloth 2y ago
      It could be preserved if specifying the namespace used a different syntax. Right now, if I have the `foo` module and `bar` function, I can call `arg1.bar()`, or `foo.bar(arg1)`. But if the namespace didn't also use `.`, then it wouldn't be an issue. For sake of argument, lets choose `/` like Clojure. Then we'd get: `arg1.foo/bar()` so we can specify the namespace and uniform function call syntax is preserved.
      • xigoi 2y ago
        True. That said, would you find, say, "one,two".std/strutils/split(',') more readable than this? "one,two".split(',')
        • firesloth 2y ago
          Maybe. First, you need the module name primarily for disambiguation for compiler or possibly for readability. I wouldn't recommend requiring it for everything, eg one of the arguments against requiring naming all imported symbols explicitly is for procs that use `[ ]`. But I think the std/strutils/split counter example isn't strong for two reasons: 1. When you disambiguate in Nim, you use just the module name, not it's full path. So it would still just be `strutils/split`. 2. If we were to introduce such a syntax, we could also introduce an `import foobarbazqux as foo` alias syntax, which is present in many languages (eg JavaScript, Clojure, etc). This would also be useful if we ever had module name collisions, which has never happened to me in Nim, but doesn't seem impossible.