<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Hi Vyzo,</div><div><br></div><div>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.</div><div><br></div><div>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 questions.</div><div><br></div><div><a href="https://cons.io/guide/intro.html">https://cons.io/guide/intro.html</a>:</div><div><ol><li>What do you mean by "Gerbil is a meta-dialect of Scheme with post-modern features"<br><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></li><li>Where is the configuration option to make Gerbil use the traditional ".scm"<br><br>".ss" is not a relevant file extension.<br><br>(Similar to how C and C++ use ".c" and ".cpp" for file extensions, not ".cs" and ".cpps".)<br><br>(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.)<br><br></li><li>In |import|, why is not "local" module and "library module" symmetrical?<br><br>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?<br><br>Documentation ref.:<br>"identifier            ; top or module scope module<br>:identifier           ; identifier with ':' prefix, library module"<br><br></li><li>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?<br><br>Documentation ref.: ""path-to-module-file" ; file module, .ss extension optional"<br><br></li><li>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?<br><br>Documentation ref.: "File modules take their name from the including file, so this module is named A and uses A# as the namespace prefix."<br><br></li><li>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?<br><br></li><li>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?<br><br></li><li>In the hello world example, you illustrate that Gerbil runs |main| for main procedure. Why?<br><br>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.<br><br></li><li>|main| gets the OS command line arguments as arguments, this sounds like an exceptionally bad idea, for instance considering the 8192 arguments limit.<br><br>Please take care to disable this or describe how to disable it. This is a nice idea in theory only.<br><br>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."<br><br></li><li>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?<br><br></li><li>Re structs and classes: "Structs are index-based .. while classes are slot-based types"<br><br>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?<br><br></li><li>"defrules: Most macros are simple and medium syntax-rules macros", what do you mean "medium"?<br><br></li><li>To compile a module from outside of the REPL you do "gxc mylib.ss". What about from inside the REPL?<br><br>That is where you normally do it, not in stop-start fashion.<br><br></li><li>In <a href="https://cons.io/guide/getting-started.html">https://cons.io/guide/getting-started.html</a> you specify exports explicitly ("(export #t) ; export all symbols" and "(export main)").<br><br>export-all is the default, why add this when it was not needed, is it for perceived clarity?<br><br></li><li>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"<br><br>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?<br><br>I don't see why dynamic and static linking would not be symmetrical with respect to build process.<br></li></ol></div><div><a href="https://cons.io/guide/shell.html">https://cons.io/guide/shell.html</a>:<br></div><ol><li>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.".<br><br>Are you saying that |reload| is assymetrical in its treament of "local" versus "library" modules, why would it be so? Kindly clarify and motivate.</li></ol><div><a href="https://cons.io/guide/package-manager.html">https://cons.io/guide/package-manager.html</a>:<b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><ol><li>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?</li></ol><div><a href="https://cons.io/guide/ffi.html">https://cons.io/guide/ffi.html</a> :</div><ol><li>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??<br><br>I see mostly no assymetry between any |lambda| and |c-lambda|, why would Gerbil introduce one.<br><br>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?</li></ol><div><a href="https://cons.io/guide/build.html">https://cons.io/guide/build.html</a>:</div><ol><li>(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?</li></ol><div><a href="https://cons.io/reference/core-prelude.html">https://cons.io/reference/core-prelude.html</a>:</div><ol><li>|lambda%|: Why is this relevant when there's |lambda|, how is Gerbil's |lambda| different from Gambit |lambda|?<br><br>(Documented as "Plain old Scheme lambda, without optional and keyword argument support".)</li></ol><div><br></div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><div>Thanks!</div><div>Adam</div></div></div></div></div></div></div></div></div>