[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
questions.
https://cons.io/guide/intro.html:
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
".scm"
".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"
symmetrical?
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
optional"
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
limit.
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.
https://cons.io/guide/shell.html:
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.
https://cons.io/guide/package-manager.html:
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?
https://cons.io/guide/build.html:
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?
https://cons.io/reference/core-prelude.html:
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".)
Thanks!
Adam
-------------- 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