With the current master branch of Gambit, given the files:
==> foo.scm <==
(define-macro (hello)
'(display "Hello world\n"))
==> foo.sld <==
(define-library (foo)
(export hello)
(import (scheme base) (gambit))
(include "foo.scm"))
The following error occurs:
$ gsi .
> (import (foo))
> (hello)
*** ERROR IN (stdin)(a)2.2 -- Unbound variable: foo#hello
Using ##define-macro instead of define-macro has the same effect, as do
`gsi -:r7rs .`, using (load "foo.scm")…
[View More] instead of (import (foo)), and
using the compiler instead of the interpreter. However, copy/pasting the
define-macro form into the REPL works fine. Exporting procedures
(instead of macros) works fine. What is the best current practice for
exporting macros?
[View Less]
Hi Vyzo,
So finally read https://github.com/vyzo/gerbil/blob/master/README.md and
all subpages on https://cons.io/ word by word.
I was trying to go through the obvious moves of incremental dev and it
crashed down totally. Kindly point out the misunderstandings and any Gerbil
customizations that are needed for this obvious usecase:
1. I create a module "a.ss" (this is a typo, should be "a.scm" but i
understand Gerbil has an exotic default, query about how to normalize the
setting in …
[View More]subsequent email). Code is:
(display "Hello world\n")
2. Compile the module:
The documentation does not disclose how to do this from the REPL, so I
do it by
,q
GAMBCOMP_VERBOSE=yes gsx a.ss
GAMBCOMP_VERBOSE=yes gsi
I see that this works as ~/.gerbil/lib/ now gets a module file (.o*),
great. Now,
3. Import the module:
(import "a")
So far, the correct thing happens: The text "Hello world" is printed out.
4. Now, with gsi running, separately in another xterm we alter a.ss
(a.scm) a bit, we add two exclamation marks to the string, so the content
is now:
(display "Hello world!!\n")
5. In the gsi REPL, we run again:
(import "a")
What happens now is a mysterious nothing!
This shows that Gerbil does not automatically reimport updated dependencies.
Also, no new binary is produced - there is no output showing any gcc
invocation (which is the behaviour specified by "GAMBCOMP_VERBOSE=yes"),
and also "ls -l ~/.gerbil/lib/" shows that no new .o* files have been
produced.
Disaster.
There is no mentioning in the documentation of how to make |import|
automatically recompile any module that has been compiled already AND
automatically reimport any module in the dependency graph, whose
modification timestamps have changed since the previous |import|.
The obvious usecase at hand is that you have more files as dependencies in
a code project, and as you go about development you edit them sporadically,
and Gerbil will have them auto-recompiled, auto-reimported and their global
namespace auto-evaluated (in a.ss's case, a |display|) as you go along,
this is essential.
Is this about a Gerbil setting that I need to configure, or a question of
deep Gerbil hacking, or is Gerbil unfit for the work and I should leave it
altogether?
Thanks,
Adam
PS
Following rectification of the above, I would throw in some FFI stuff like
echo "((c-lambda () void "printf(\"Hi from C\\n\");\"))" >> a.ss
to see that FFI stuff is handled symmetrically in the same fashion as any
other Scheme code.
[View Less]
The Gambit@30 workshop was a blast! For those who couldn’t make it, you can find PDFs for some of the presentations on github at https://github.com/gambit/gambit-at-30 .
The repository also contains the compressed image of mimosa for running Gambit on bare metal. You can copy the image to a real IDE HDD and use it to boot a real PC, or use the QEMU emulator like this:
% gunzip -c mimosa.img.gz > mimosa.img
% qemu-system-i386 -m 1G -hda mimosa.img
Once booted, here are some …
[View More]interesting things to type
at the Gambit REPL:
> (current-directory)
> (directory-files)
> (load "fact.scm")
> (load "fib.scm") ;; run it interpreted
> (compile-and-load "fib.scm") ;; run it compiled to x86
> (load "x86-asm.scm") ;; x86 assembler example
> (load "x86-os.scm") ;; read RTC with in/out instructions
> (edit "fib.scm") ;; save/exit with ESC key
The state of the filesystem is preserved in mimosa.img. This includes
the REPL history and any files generated or edited with `(edit ...)`.
Have fun!
Marc
[View Less]
To celebrate the Gambit@30 event, I have committed to the github repo the work that has been done by the students I supervised over the summer and that will be presented at Gambit@30.
Some of the more prominent enhancements include:
- Close to full R7RS conformance
- Module system which simplifies code sharing and distribution
- Some builtin modules that will grow with time
- Improvement of the native code backend (now supports x86, ARM and RISC-V)
- Gambit on bare metal
- Geiser support
…
[View More]These will be discussed at Gambit@30. For a small taste of the module system, try:
% gsi github.com/gambit/hello/demo
% gsi github.com/gambit/hello@1.0
% gsi github.com/gambit/xlib/demo # assumes you have an X server running
Gambit's version number has not been incremented because I need some feedback that it works well “in the wild” and that some trivial mistake hasn’t been overlooked.
I’m looking forward to your feedback, and to seeing some of you tomorrow!
Marc
[View Less]
-------------------------------------------------------------------------
Second call for papers
21st Symposium on Trends in Functional Programming
tfp2020.org
---------------------------…
[View More]----------------------------------------------
The symposium on Trends in Functional Programming (TFP) is an international
forum for researchers with interests in all aspects of functional
programming,
taking a broad view of current and future trends in the area. It aspires
to be
a lively environment for presenting the latest research results, and other
contributions.
* TFP is moving to new winter dates, to provide an FP forum in between the
annual ICFP events.
* TFP offers a supportive reviewing process designed to help less
experienced
authors succeed, with two rounds of review, both before and after the
symposium itself. Authors have an opportunity to address reviewers'
concerns
before final decisions on publication in the proceedings.
* TFP offers two "best paper" awards, the John McCarthy award for best
paper,
and the David Turner award for best student paper.
* This year we are particularly excited to co-locate with Lambda Days in
beautiful Krakow. Lambda Days is a vibrant developer conference with
hundreds
of attendees and a lively programme of talks on functional
programming in
practice. TFP will be held in the same venue, and participants will
be able
to session-hop between the two events.
Important Dates
---------------
Submission deadline for pre-symposium review: 15th November, 2019
Submission deadline for draft papers: 10th January, 2020
Symposium dates: 13-14th February, 2020
Visit tfp2020.org for more information.
[View Less]
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 …
[View More]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
[View Less]
(Sorry if this basic question has been answered before; didn't find in
the list archives, wiki or manual.)
What's the general approach for wrapping C functions like this:
int foo(struct bar **out);
So the foo function sets *out to some value of type "struct bar *", and
we want to keep that "struct bar *" in Scheme and pass it around to
other FFI functions.
If it's not necessary to preserve the "int" return value then this can
be worked around by writing a wrapper function in C:
struct …
[View More]bar *my_foo_wrapper(void) {
struct bar *bar;
foo(&bar);
return bar;
}
But is there a more general way to get values from out parameters into
Scheme?
[View Less]