Fat Gerbil prelude
So I would like to propose a fat gerbil prelude, named :gerbil/fat which adds basic batteries to the core language.
Minimum imports and re-exports:
:std/sugar
:std/generic
:std/iter
:std/format
What else should be in the fat prelude?
Obvious extension: :gerbil/gambit.
I am not sure why this is needed.
Maybe a couple of popular SRFIs or modules from misc?
Here's the head of two dozen or so gerbil repos that I grepped for imports:
| count | module |
|---|---|
| 114 | :std/sugar |
| 69 | :gerbil/gambit/threads |
| 57 | :gerbil/gambit/ports |
| 50 | :std/test |
| 50 | :clan/utils/base |
| 49 | :std/iter |
| 49 | :std/format |
| 48 | :std/error |
| 42 | :std/srfi/1 |
| 35 | :std/logger |
| 28 | :std/text/utf8 |
| 28 | :std/srfi/13 |
| 27 | :std/build |
| 27 | :gerbil/gambit/os |
| 26 | :std/misc/list |
| 26 | :gerbil/gambit |
| 25 | :gerbil/gambit/exceptions |
| 23 | :std/pregexp |
| 20 | :std/generic |
| 19 | :std/misc/ports |
| 19 | :std/actor |
| 18 | :std/text/json |
| 18 | :std/net/bio |
| 18 | :gerbil/gambit/exact |
| 18 | :gerbil/expander |
| 17 | :std/net/address |
| 17 | :std/getopt |
| 17 | :std/foreign |
| 17 | :gerbil/gambit/bits |
| 16 | :std/make |
| 15 | :gerbil/core |
| 14 | :std/srfi/srfi |
| 14 | :std/crypto/etc |
| 14 | :std/actor/proto |
| 14 | :gerbil/gambit/random |
| 14 | :gerbil/gambit/misc |
| 13 | :std/srfi/9 |
| 13 | :std/parser/base |
| 13 | :std/os/fd |
| 13 | :clan/utils/number |
| 12 | :std/stxutil |
| 12 | :std/misc/threads |
| 11 | :std/srfi/19 |
| 11 | :std/os/error |
| 11 | :std/misc/process |
| 11 | :std/actor/message |
| 11 | :clan/utils/list |
| 11 | :clan/utils/basic |
| 10 | :std/sort |
| 10 | :std/net/socket |
| 10 | :std/net/request |
| 10 | :std/misc/channel |
| 10 | :std/db/dbi |
| 9 | :std/os/socket |
| 9 | :std/net/httpd |
| 9 | :std/crypto/libcrypto |
| 8 | :std/srfi/8 |
| 8 | :std/parser/rlang |
| 8 | :std/net/socket/base |
| 8 | :std/generic/dispatch |
| 8 | :std/event |
| 8 | :std/crypto/digest |
| 8 | :scheme/base |
| 8 | :clan/utils/date |
| 7 | :std/text/base64 |
| 7 | :std/parser/lexer |
| 7 | :std/actor/xdr |
| 7 | :gerbil/gambit/hash |
| 6 | :std/text/hex |
| 6 | :std/srfi/14 |
| 6 | :std/srfi/128 |
| 6 | :std/parser/defparser |
| 6 | :std/os/signal |
| 6 | :std/os/fcntl |
| 6 | :std/net/uri |
| 6 | :std/misc/uuid |
| 6 | :std/misc/string |
| 6 | :std/misc/shuffle |
| 6 | :std/actor/rpc/base |
| 6 | :gerbil/gambit/fixnum |
| 5 | :vyzo/libp2p/peer |
| 5 | :std/xml/ssax |
| 5 | :std/text/zlib |
| 5 | :std/text/yaml |
| 5 | :std/srfi/95 |
| 5 | :std/srfi/125 |
| 5 | :std/protobuf/io |
| 5 | :std/parser/deflexer |
| 5 | :std/debug/heap |
| 5 | :std/db/postgresql |
| 5 | :std/crypto/cipher |
| 5 | :gerbil/gambit/hvectors |
| 4 | :vyzo/libp2p/pb/p2pd |
| 4 | :vyzo/libp2p/multiaddr |
| 4 | :vyzo/libp2p/client |
| 4 | :std/parser/stream |
| 4 | :std/os/pid |
| 4 | :std/net/bio/output |
| 4 | :std/net/bio/input |
| 4 | :std/misc/rtd |
| 4 | :std/misc/queue |
| 4 | :std/misc/pqueue |
| 4 | :std/crypto |
I don't see why this can't exist but at the same time I don't actually see a use for it either. Every one of my files has different imports, and I use only-in to minimize imports.
Is this wanted to better help new developers learn the language? In a way choosing all your imports means getting to know the stdlib better. I can see gerbil/fat be part of the documentation but not the actual stdlib. It could be a tutorial on how to create one's own stdlib package, including some standard imports and user-defined functions.
My IRC history is sporadic so I might have missed the discussion that led to this issue being raised. Who needs this for what?
Well the need is for cutting the boilerplate, especially for scripts or interactive code. For (static) binaries I would very much recommend against fat.
Hi,
I'm just starting to use Gerbil, but when I saw this issue I wanted to chime in: I find really confusing when I read a certain file/module with many non-qualified imports, because it makes much harder to figure out where does a certain function of thingy come from.
I have seen similar patterns of fat modules like the proposed :gerbil/fat in Python (a bogus proxy module does many imports so that whatever is importing it, gets everything) in some codebases I worked with, and the result in maintainability is just... awful. I'm often okay with reducing boilerplate, but I don't think imports are the target.
For what my opinion is worth, I'm with @belmarca: I'm curious as to who benefits from that. In my experience with Python (the language I'm often paid to write code on) it's common practice to import everything (either qualified or specific imports like only-in) and this doesn't seem to be a problem.