Fat Gerbil prelude #345

New issue

2019-10-23T17:49:44Z

vyzo commented

2019-10-23 17:49:44 +00:00

(Migrated from github.com)

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?

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?

vyzo commented

2019-10-23 18:04:39 +00:00

(Migrated from github.com)

Obvious extension: :gerbil/gambit.

Obvious extension: `:gerbil/gambit`.

belmarca commented

2019-10-24 17:10:21 +00:00

(Migrated from github.com)

I am not sure why this is needed.

ghost commented

2019-10-24 17:52:41 +00:00

(Migrated from github.com)

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

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 |

belmarca commented

2019-10-24 18:05:22 +00:00

(Migrated from github.com)

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?

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?

vyzo commented

2019-10-24 18:54:51 +00:00

(Migrated from github.com)

Well the need is for cutting the boilerplate, especially for scripts or interactive code.
For (static) binaries I would very much recommend against fat.

Well the need is for cutting the boilerplate, especially for scripts or interactive code. For (static) binaries I would very much recommend against fat.

lsmag commented

2019-12-08 04:30:58 +00:00

(Migrated from github.com)

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.

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.

Sign in to join this conversation.