[gambit-list] Gerbil questions

Adam adam.mlmb at gmail.com
Thu Oct 3 11:36:39 EDT 2019

Hi Vyzo,

The following questions arose from first time reading the Gerbil docs word
by word, if you would be up to clarifying these would be great.

After reading, I still don't get how much Gerbil is / has the ambition to
be a module system in the sense a tool for incremental dev with dependency
graph management and deep namespace management like described in the
previous email, versus a distribution of libraries with a macro expander
and special language forms. I hope this will become clear with these


   1. What do you mean by "Gerbil is a meta-dialect of Scheme with
   post-modern features"

   2. Where is the configuration option to make Gerbil use the traditional

   ".ss" is not a relevant file extension.

   (Similar to how C and C++ use ".c" and ".cpp" for file extensions, not
   ".cs" and ".cpps".)

   (Similarly I guess ".ssi" should only be relevant as some kind of
   intermediary internal data generated by Gerbil, anyhow I guess that becomes
   clear with other questions.)

   3. In |import|, why is not "local" module and "library module"

   Is this only a question of that Gerbil has more "namespaces" for module
   lookups, if so for what reason does it use more namespaces? Does this
   indicate additional assymetries in how Gerbil processes modules?

   Documentation ref.:
   "identifier            ; top or module scope module
   :identifier           ; identifier with ':' prefix, library module"

   4. Similarly, the string argument type to |import| is effectively
   unnecessary also right, as (import A) will load a.scm from the local
   directory, why was it introduced?

   Documentation ref.: ""path-to-module-file" ; file module, .ss extension

   5. If you have more modules with the same module name, Gerbil will
   automatically generate extra namespaces to maintain uniqueness, e.g.
   dira/A.scm , dirb/A.scm and dirc/A.scm will get namespaces A#, Agensym1#,
   Agensym2# (in arbitrary order) right?

   Documentation ref.: "File modules take their name from the including
   file, so this module is named A and uses A# as the namespace prefix."

   6. Why does |defsyntax-for-export| exist, is that a |defsyntax| variant
   that is bundled with (export), i.e. the normal |defsyntax| exports
   perfectly well doesn't it so what's the need for this?

   7. What's the point with |export|'s option "(export-expander
   <export-spec> args ...) ; export macro", don't you export macros just like
   you do with any other identifier?

   8. In the hello world example, you illustrate that Gerbil runs |main|
   for main procedure. Why?

   In Gambit |main| is implied in the global scope, you just put the code
   for main logics in the global scope in the main application logics module,
   why the fuss, please share your motivation for this additional complexity.

   9. |main| gets the OS command line arguments as arguments, this sounds
   like an exceptionally bad idea, for instance considering the 8192 arguments

   Please take care to disable this or describe how to disable it. This is
   a nice idea in theory only.

   Documentation ref.: "The module must define and export a main function
   that gets invoked with the command line arguments after loading the gerbil
   runtime and module dependencies."

   10. Ellipsis list splicing ( [1 2 [3 4 5] ... 6] => '(1 2 3 4 5 6) ) is
   motivated by what, from where did the idea originate?

   11. Re structs and classes: "Structs are index-based .. while classes
   are slot-based types"

   But the examples show both using slots. What do you mean by
   "index-based" here - actually by "slot-based" do you mean that a hashtable
   or a-list is used as internal representation?

   12. "defrules: Most macros are simple and medium syntax-rules macros",
   what do you mean "medium"?

   13. To compile a module from outside of the REPL you do "gxc mylib.ss".
   What about from inside the REPL?

   That is where you normally do it, not in stop-start fashion.

   14. In https://cons.io/guide/getting-started.html you specify exports
   explicitly ("(export #t) ; export all symbols" and "(export main)").

   export-all is the default, why add this when it was not needed, is it
   for perceived clarity?

   15. For static build there is the comment "Note that when creating
   static executables, you will need to pass on options to the linker if
   you're relying on foreign libraries. For example, to include a dependency
   on zlib: .. -ld-options -lz"

   Why, shouldn't this be a flag you specify within the zlib module which
   Gerbil then automatically passes on to the C compiler, is there any reason
   to not do it like this?

   I don't see why dynamic and static linking would not be symmetrical with
   respect to build process.


   1. Re |reload| documentation says "Reloads the module given by the
   module path and then imports the freshly reloaded module. The module path
   is the same as you would use in a import form; a string will reload a
   source loaded module while a library module path will reload a compiled
   module as applicable in the load path.".

   Are you saying that |reload| is assymetrical in its treament of "local"
   versus "library" modules, why would it be so? Kindly clarify and motivate.


   1. The normal mode of operation is a REPL, here you show a Unix shell
   for operation which is less frequently used. What are the REPL
   correspondents of these Unix shell commands?

https://cons.io/guide/ffi.html :

   1. Is it right that Gerbil does not allow interspersing Scheme code with
   C code like you normally do in Gambit, but instead it requires a
   |begin-foreign| form and then adds hoops for namespace management via
   |extern| - why??

   I see mostly no assymetry between any |lambda| and |c-lambda|, why would
   Gerbil introduce one.

   Similarly |c-declare| is just-another language form, why would you
   introduce a |begin-foreign| form and require it to be in there only, in
   real world Gambit code I don't see why that would be useful?


   1. (Same question as above:) :std/make's |make| is introduced here.
   Still unclear: What is Gerbil's built-in procedure for compiling one module
   from the REPL?


   1. |lambda%|: Why is this relevant when there's |lambda|, how is
   Gerbil's |lambda| different from Gambit |lambda|?

   (Documented as "Plain old Scheme lambda, without optional and keyword
   argument support".)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20191003/9552806b/attachment.htm>

More information about the Gambit-list mailing list