February 2016 - Gambit-list - mailman.iro.umontreal.ca

Gambit versus Python+GMP: Timing for Chudnovskys' algorithm for pi
by Bradley Lucier 07 Apr '22

07 Apr '22

Bakul Shah wrote a particularly elegant Scheme program for Chudnovskys' algorithm for pi based on the Common Lisp program here: https://bitbucket.org/tarballs_are_good/numericl/src/5fe8fe7089f48ab1c8a388… Nick Craig-Wood wrote a Python program using the GMP multiprecision library that appears to use exactly the same algorithm here: http://www.craig-wood.com/nick/articles/pi-chudnovsky/ I modified both programs a bit and include them here. They time the calculation of $10^n$ digits of pi for $n=1,2,3,4,5,6,7$. The results are heine:~/programs/gambiteer/gambit> !py python pi_chudnovsky_bs_gmpy.py 31415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679 ('chudnovsky_gmpy_mpz_bs: digits', 10, 'time', 1.0967254638671875e-05) ('chudnovsky_gmpy_mpz_bs: digits', 100, 'time', 3.0040740966796875e-05) Last 5 digits 70679 OK ('chudnovsky_gmpy_mpz_bs: digits', 1000, 'time', 0.00025582313537597656) Last 5 digits 01989 OK ('chudnovsky_gmpy_mpz_bs: digits', 10000, 'time', 0.00386810302734375) Last 5 digits 75678 OK ('chudnovsky_gmpy_mpz_bs: digits', 100000, 'time', 0.0834801197052002) Last 5 digits 24646 OK ('chudnovsky_gmpy_mpz_bs: digits', 1000000, 'time', 1.655979871749878) Last 5 digits 58151 OK ('chudnovsky_gmpy_mpz_bs: digits', 10000000, 'time', 30.67442488670349) Last 5 digits 55897 OK heine:~/programs/gambiteer/gambit> gsi chud1.scm Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 10, CPU time: 0.. Last 5 digits 26535. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 100, CPU time: 0.. Last 5 digits 70679. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 1000, CPU time: .004. Last 5 digits 1989. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 10000, CPU time: .028. Last 5 digits 75678. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 100000, CPU time: .472. Last 5 digits 24646. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 1000000, CPU time: 6.448. Last 5 digits 58151. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 10000000, CPU time: 98.612. Last 5 digits 55897. So it appears that for this algorithm applied to large integers, GMP's bignum routines are about 3-4 times as fast as Gambit's bignum routines. Not so bad. For smaller bignums, GMP has a bigger advantage. The C program gmp-chudnovsky.c includes certain optimizations to this basic algorithm: http://gmplib.org/pi-with-gmp.html ftp://ftp.gmplib.org/pub/misc/gmp-chudnovsky.c On my machine, compiled with gcc -O3 -march=native -o gmp-chudnovsky gmp-chudnovsky.c -lgmp -lm the CPU times for 1,000,000 and 10,000,000 digits are 1.064 and 18.200 seconds, respectively. This is with a somewhat older machine model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz running Ubuntu 13.04 with heine:~/programs/gambiteer/gambit> gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) heine:~/programs/gambiteer/gambit> gsi -v v4.6.9 20130607151908 x86_64-unknown-linux-gnu "./configure '--enable-single-host' '--enable-multiple-versions' '--enable-shared'" and the Ubuntu-provided GMP 5.0.5. (I'm sure the GMP folks have a better way to build GMP on my machine than the "generic" 64-bit version provided by Ubuntu.) Brad

7 18

Re: [gambit-list] JavaScript backend
by Marc Feeley 13 Feb '17

13 Feb '17

First of all, this change is for the universal backend. It is more of a temporary kludge to experiment with dynamically loading files generated by the universal backend. Here’s how it works… At the end of the link file, the Gambit linker generates a table of the Scheme modules required by the program. The table is passed as a parameter to the g_module_registry_init function of the Gambit runtime system. For example, the link command: gsc -link -l lib/_gambit.js a.js b.js will generate at the end of the link file “b_.js”: g_module_registry_init([new G_ModLinkInfo("_gambit",0), new G_ModLinkInfo("a",1), new G_ModLinkInfo("b",2)]); At then end of a file generated for the compilation of a module there is a call to a runtime system function that registers the module in the module registry. For example, when “a.scm” is compiled with the command “gsc -target js -c a.scm”, the file “a.js” generated ends with: g_module_register([g_make_interned_symbol("a"),g_bb1__20_a,1,null,false]); The parameter of g_module_register is a “module descriptor” giving information on the module: name, main function (g_bb1__20_a), preload flag (1), module meta information (null), and a dummy field (false) that is only interesting for the C backend. So when the files of generated code are loaded (incrementally) by the JS VM, g_module_register accumulates the modules in a table. When all the modules required by the program have beed loaded (in the example, _gambit, a and b) the function g_module_register will call the main function of the first module. This will run the Scheme code at the toplevel of the first module. The first module contains a loop, in Scheme, that iterates over the module registry and calls the main function of each of the remaining modules in the registry (this information is available in Scheme in the global variable ##program-descr). Specifically, the first module is the Gambit universal library (lib/_univlib.scm), which ends with a call to ##load-vm (a procedure defined in lib/_kernel.scm that runs each module other than the first). What my most recent change does is extend g_module_register so that any subsequent module that is loaded by the JS VM causes its immediate execution by calling the module's main function. In the C backend the mechanism is slightly different (and more flexible): the ##load-object-file procedure of the Gambit runtime library constructs a vector of module descriptors and this vector is passed to ##register-module-descrs-and-load! (defined in lib/_kernel.scm) which then runs the modules. It is more flexible because the loaded object file can contain more than one module, and also control goes through Scheme before the module is executed. Marc > On Jan 3, 2016, at 2:54 AM, Adam <adam.mlmb(a)gmail.com> wrote: > > Marc, > > Wait, what's the point? > > That is effectively C modules' default behavior isn't it? (even if it's the runtime or linker-generated code that actually does the actual run command.) > > So this way you create symmetrical behavior but the actual run command is in the module file itself rather than in runtime/linker - > > Is there any disadvantage.. could be, no, like, I need more modules loaded at the same time and with this model you introduced now, the global namespace in JS files is evaluated at load time so could cause a problem? > > > 2016-01-03 14:10 GMT+08:00 Marc Feeley <feeley(a)iro.umontreal.ca>: > I’ve just pushed a small change to the module registration method. Now, loading the generated .js file will run that file. > > Marc > > > On Jan 2, 2016, at 11:39 PM, Blake McBride <blake(a)mcbride.name> wrote: > > > > Yes, and I use jQuery get and html methods to load the html part. > > > > > > On Sat, Jan 2, 2016 at 8:43 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: > > That’s an interesting app! > > > > As I said, it shouldn’t be hard to do. In your app, how do you load new JS code? Are you using jQuery and the getScript method? > > > > Marc > > > > > On Jan 2, 2016, at 8:42 PM, Blake McBride <blake(a)mcbride.name> wrote: > > > > > > Hi Marc, > > > > > > Thanks for the reply. > > > > > > I started development of a Web based business application in 2006. The app is in production use. The front-end is about 450 screens written in Flash. The back-end is written in Java (over 9,000 classes) on top of an SQL database with 250 tables accessed through Hibernate. The front-end and back-end communicate through SOAP web services. > > > > > > Since Flash is now dead, I need to re-write at least parts of the front-end in JS to support tablets and phones at least. I have front-end JS code that communicates with the back-end SOAP Web services so I theoretically wouldn't need to touch the back-end. > > > > > > I have a preference to utilize scheme if I can, but the back-end is already written and works. It doesn't make sense to mess with it given the investment. > > > > > > The problems I had with Gambit (as well as many other systems) is as follows: > > > > > > Once a user logs in, my app has a consistent visual / UI framework. Beyond this framework, there are 450 different screens that appear within the framework (like in one of the div's). > > > > > > A. I cannot load all 450 screen at system startup. I must lazy load them as they are called up. > > > > > > B. The initial UI framework code should contain all of the Gambit machinery and libraries so that each of the 450 screens can be small, light-weight, compiled separately yet have full access to the entire Gambit facility. > > > > > > With respect, my investigation into Gambit as a possible solution in the past led me to the conclusions at that time it was not possible to produce separately compiled modules that leveraged off of a single main module for the Gambit machinery and libraries. > > > > > > I suppose some time has passed and I wanted to see if the situation has changed. I can only use Gambit if: > > > > > > 1. I can compile and load each screen separately > > > > > > 2. I only have to have one copy of the Gambit machinery and library so that the separate screens are small. > > > > > > Thank you. > > > > > > Blake > > > > > > > > > On Sat, Jan 2, 2016 at 7:06 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: > > > asmjs is cool and Gambit has already been compiled to it thanks to emscripten (see “Gambit in the browser”: http://feeley.github.io/gambit-in-the-browser/) The performance is not bad, perhaps 10x to 20x slower than when Gambit is compiled by gcc to native code. The main problem is the size of the JS that is generated when compiling Gambit-C with emscripten to JS. The gsi interpreter yields roughly 10 MB of asmjs code. > > > > > > As far as code size is concerned, a better solution is to use Gambit's JS backend with the Gambit library. The code generated is roughly half the size when minimized (and it could be even less if some thought went into how identifiers are encoded). > > > > > > Even more savings can be had by doing away with the default Gambit library and writing a custom library specialized for the application. Gambit’s library has lots of functionality that is not normally needed by typical applications. For example, the predefined map procedure can handle an arbitrary number of list parameters. If the application only uses the single list version, then this definition would be sufficient: > > > > > > (define (map f lst) > > > (if (pair? lst) > > > (cons (f (car lst)) (map f (cdr lst))) > > > ‘())) > > > > > > That 4 line version is 1/20th the size of the map defined in the Gambit library (which handles multiple lists, has type checking, precise error messages, same list length checking and is safe for multithreading). > > > > > > So perhaps what’s needed for Gambit to be more successful for web dev is the creation of such a “slim” library for Gambit to replace the default feature-full library. Gambit’s “tree shaker” would also help to eliminate the unused procedures of the slim library (unfortunately this only works for “whole program” compilation, so separate compilation would only be used for the development phase). > > > > > > Anyway, if this interests you please let me know. > > > > > > Marc > > > > > > > On Jan 1, 2016, at 11:44 AM, Blake McBride <blake(a)mcbride.name> wrote: > > > > > > > > Just some opinions. > > > > > > > > asmjs.org defines a portable subset that allows JS platforms to compile into very fast code. Targeting that subset, and within their spec, is probably a good idea. > > > > > > > > JS has, and is becoming increasingly, a very, very important platform. With ajax and rest services, code increasingly independent from the back-end is being developed. So, in a very important sense, JS has become its own platform, just like X86, and X86_64, along with Linux, Windows, Mac, etc. > > > > > > > > Many apps consist of two major parts: the back-end processing, and the front-end human interface. While one can write the back-end processing in any of dozens of languages targeting X86 or a VM, and the OS, there is really only one target for the other half - the human interface - and that is JS. > > > > > > > > While many languages are now targeting the JS platform (I am using the word "platform" to mean X86, X86_64, either, plus the OS) including, believe it or not, Smalltalk, there are few that can, IMO, be used in a real world application for several reasons. But, these issues will likely be resolved soon. > > > > > > > > With respect, Gambit, at least in the past, was in many ways another toy solution - one with a functioning "Hello world" application but missing important features that make it usable in a real-world situation. I would love to be a part of that solution, but alas, life doesn't offer me that level of freedom. I am only capable of using a system that is reportedly working, reporting bugs, making small adjustments, and providing feedback. Regardless of my attitude, preferences, and intentions, I cannot provide more. > > > > > > > > Look at node (JS for the back-end) and its vastly increasing popularity. Since developers are being forced to use JS on the front-end, it's bleeding over to the back-end. I think solutions that take JS seriously at this stage will prosper greatly. > > > > > > > > Now, having said all that, I would love to see Gambit target JS as a high-priority, first-class target. If that were the case, I would be happy to contribute what I stated above. > > > > > > > > Thanks! > > > > > > > > Blake McBride > > > > > > > > _______________________________________________ > > > > Gambit-list mailing list > > > > Gambit-list(a)iro.umontreal.ca > > > > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list > > > > > > > > > > > > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >

2 1

Gerbil-v0.3
by Dimitris Vyzovitis 28 Feb '16

28 Feb '16

I have tagged a new release for Gerbil, reaching v0.3 What's new in this release: - std/test: unit testing (similar to rackunit) and basic tests for stdlib - std/iter: plt-style iteration macros (for,for/collect,for/fold) - bug fixes and small improvements As usual, code is on Github: https://github.com/vyzo/gerbil -- vyzo

1 0

{Spam?} (Marc + ML:) Extension/patch feedback & inclusion request: Practical custom types in the sexp reader (finally)
by Adam 25 Feb '16

25 Feb '16

Dear Marc & list, First, the fun stuff suggested is in the *"Result, usage"* secton below - check it out first :D This is to discuss the pull request https://github.com/feeley/gambit/pull/180 that I just made. I hope this provides a clean and practical solution to a problem that has been discussed here on the list last years, and to which not really clean solutions have been suggested until now. Marc, in particular can you please check out my question secton "Implementation stuff I don't remember why - Marc clarify?" right at the bottom here, and let us know so everyone will know why it needs to be exactly like this? Thanks! *Purpose* There are times when as a user you want to enhance your s-expression format with a custom type. E.g., sometimes you have a custom value type such as an FFI type, that you want to make serializable. *Problem* The writer is fairly easy to extend, you just overlap Gambit's |##wr| procedure with your own (lambda (write-env obj) ...) procedure, where |obj| is the value that Gambit is serializing right now, and that procedure either does its own serialization by outputting the customs structure using (##wr-str write-env string-serialized-form), or passes on execution to the underlying (original) |##wr|. So so far so good. The reader is more complex to extend though. One syntax that theoretically could have worked would have been took into gambit's #. syntax, to inline actual code to be evaluated by the reader, in the serialized form of the sexp. That is not only unsafe though, but also, Gambit namespace management is a task that is difficult to impossible - Gambit is simply not really made for that, so having your custom forms of data serialized to #.(my-data-form ...) does not scale. *The solution I suggest* Luckily, internally Gambit has a procedure |##readtable-char-sharp-handler-set!|, which installs user-defined hash-sequence deserializer in a readtable! E.g. install an #\X-character handler into it, and any read element #Xyour-data will have your-data readable by that custom handler. *Implementation problem 1* The problem then is that Gambit not exports any ways to make your own custom handlers - it just exports its own handlers, such as |##read-sharp-vector| (for "#(..."), |##read-sharp-char| (for "#\..."), |##read-sharp-dot| (for "#...."), |##read-sharp-bang| (for "#!..."), etc. . (All those are implemented in lib/_io.scm , and are installed in every readtable using - you guessed it - |##readtable-char-sharp-handler-set!|, in |##make-standard-readtable|.) To implement your own handler, you need access to the lowlevel macros |macro-read-next-char-or-eof|, |macro-readenv-filepos-set!| and |macro-readenv-wrap|. Also, perhaps, even if you had access to those macros in userland, because Gambit's IO could change at some point perhaps actually using them in userland would be a hack - and so, it would be better if Gambit exported a generalized mechanism for the user to implement his own readtable handlers, that itself takes care of the lowlevel stuff. *Implementation problem 1 solution* To enable users to implement their own readtable handlers, I suggest the inclusion into Gambit of a procedure |##make-readtable-char-sharp-sexp-reader-transformer|, which takes the arguments (transform #!optional (read ##read-datum-or-label)) and returns a readtable hash-sequence deserializer for use with |##readtable-char-sharp-handler-set!|. |transform| is the user-provided function that receives as only argument the data that was read out of the sexp in an ordinary format (discussed below), and performs any conversion to that to the custom format (e.g. C FFI type etc.) - the transform procedure evaluates to the conversion result to be used in the sexp. |##make-readtable-char-sharp-sexp-reader-transformer| abstracts away the need of taking care of/takes care of all the Gambit-IO-internal macros, as discussed above. *Implementation problem 2* The next problem is how the content of that custom hash-sequnce type is read - The different ##read-sharp-* procedures all implement their own specific deserializer logics, to read the different hash-sequence formats e.g. "#(e1 e2)", "#\newline", "#!value", "#|| comment ||", etc. - rightly so as the formats are completely custom to the respective hash-sequence. The ##read-sharp-* procedures frequently, but not always, implement the whole reading logic locally in themselves. There are some instances of reading logics defined globally though - - |##read-datum-or-label| reads a single datum (e.g. "abc", "123", "#f" or "(1 2 3)"), that one is used by |##read-sharp-ampersand|, for deserialization of the box form e.g. "#&#t", or for the datum-comment form e.g. "#;(im not read)". - |##read-expr-from-port| reads any expression from a port, for |##eval| to be fed with it. That one is used by |##read-sharp-dot|, e.g. for "#.(+ 1 2)". - There's a bunch of ##build- forms for reading vectors, lists, integers - |##read-datum-or-label-or-none-or-dot| seems to read pretty much anything, and is used for instance as continuation for the whole reading process. *Implementation problem 2 solution* Of these, it seems to me that |##read-datum-or-label| is a perfect default - in particular, the list type makes perfect sense for storing complex custom types. *Implementation stuff I don't remember why - Marc clarify?* As of the moment of writing, - What's the label-marker check and error handling for? - Why is the "unwrap":ping during the call to the |read| procedure needed? *Result, usage* The result of this addition is that you can plug in your custom serialization code as follows: (define-type coord x y) (##readtable-char-sharp-handler-set! (input-port-readtable (repl-input-port)) #\$ (##make-readtable-char-sharp-sexp-reader-transformer (lambda (v) (apply make-coord v)))) (set! ##wr (let* ((old-wr ##wr)) (lambda (we obj) (if (coord? obj) (begin (##wr-str we "#$") (##wr-str we (object->string (list (coord-x obj) (coord-y obj))))) (old-wr we obj))))) And it's used as follows: > *(make-coord 15 16)* #$(15 16) > *(define c #)* > *(coord-x c)* 15 > *c* #$(15 16) > *(object->string c)* "#$(15 16)" > *(call-with-input-string # read)* #$(15 16) > The only important catch to be aware of, is that actually typing in #$(15 16) in the REPL will evaluate to the object, which will then cause an exception: > *#$(15 16)* *** ERROR IN (console)(a)19.3 -- Ill-formed expression That's analogous to: > *(eval print)* *** ERROR -- Ill-formed expression #<procedure #16 print> 1> As of the time of this post, the extention consists only of the following addition to lib/_io.scm : (define (##make-readtable-char-sharp-sexp-reader-transformer transform #!optional (read ##read-datum-or-label)) (define (read-without-wrap re) (let* ((old-wrapper (macro-readenv-wrapper re)) (old-unwrapper (macro-readenv-unwrapper re))) (macro-readenv-wrapper-set! re (lambda (re x) x)) (macro-readenv-unwrapper-set! re (lambda (re x) x)) (let ((result (read re))) (macro-readenv-wrapper-set! re old-wrapper) (macro-readenv-unwrapper-set! re old-unwrapper) result))) (lambda (re next start-pos) (macro-read-next-char-or-eof re) ;; skip char after #\# (macro-readenv-filepos-set! re start-pos) ;; set pos to start of datum (let ((args (read-without-wrap re))) (if (##label-marker? args) (begin (##raise-datum-parsing-exception 'datum-or-eof-expected re) (##void)) (let ((obj (transform args))) (macro-readenv-wrap re obj)))))) Perhaps this can be simplified further. Looking forward to your thoughts and feedback, and I hope to finally enable Gambit with this :) In particular if you feel any name would be more relevant than "##make-readtable-char-sharp-sexp-reader-transformer" then let me know. Thanks!

3 9

Brad, just to get up to date about GCC memory consumption and other GCC bugs re Gambit
by Adam 22 Feb '16

22 Feb '16

Hi Brad, About the GCC bug that sometimes GCC could take gigabytes of RAM (20-75GB) for certain Gambit files, I re-read your previous article at http://webmail.iro.umontreal.ca/pipermail/gambit-list/2009-February/003159.… . (Btw the mentioning of an addition to http://dynamo.iro.umontreal.ca/wiki/index.php/Configure_script_options , I don't know if I see that addition there, you could doublecheck.) You mention there that the problem GCC versions are 4.2.* and 4.3.* only, and that "-fno-move-loop-invariants" fixes it. (I recall that you also reported the issue to the GCC development team and that in response they implemented a "max loops" check internally that fixed it on.. later GCC version, something like this.) I just wanted to check with you now, that the above was all there has been to GCC's skyrocketing-RAM-consumption issue. So, if I just add CFLAGS="-fno-move-loop-invariants" to my ordinary "./configure --enable-single-host" etc. , no GCC/G++ version will skyrocket? Are there any more gotchas to GCC use for various versions, except for that "-O2" produces broken code in some particular version? Thanks!

2 3

Gerbil-v0.2
by Dimitris Vyzovitis 21 Feb '16

21 Feb '16

Hi all, I have tagged a new release in Gerbil, v0.2. This release brings better MOP integration with Gambit types, and Generics support. The requisite macros for defining generics and generic methods is in :std/generics, and the documentation has been updated to provide a quick tutorial. If you are upgrading with git pull, do a full build after pulling because of changes in the runtime and core prelude. As usual you can get Gerbil from Github: https://github.com/vyzo/gerbil -- vyzo

2 3

{Spam?} Fw: new message
by goetter＠mazama.net 17 Feb '16

17 Feb '16

Hey! Open message <http://elitesmile.com.au/gave.php?vqp> goetter(a)mazama.net

1 0

{Spam?} Fw: new message
by goetter＠mazama.net 17 Feb '16

17 Feb '16

Hey! Open message <http://beatthechamp.com/figure.php?tn> goetter(a)mazama.net

1 0

Marc, can you use this to implement /regexp/ syntax too? :)
by Adam 17 Feb '16

17 Feb '16

Dear Marc, Vyzo wonders if you can use this to implement /regexp/ syntax. My spontaneous guess is that I guess so, but I have no idea how the |read| procedure should be written in order to read a string, with normal escaping, up to the ending #\/ char? Feel free to provide an example. The same example then could be used to read #"string" if anyone would be interested. Thanks!

1 0

[CFP] Scheme and Functional Programming Workshop 2016
by Alex Shinn 17 Feb '16

17 Feb '16

Call For Presentations 17th Annual Scheme and Functional Programming Workshop Nara, Japan (Co-located with ICFP 2016) 18 September 2016 http://scheme2016.snow-fort.org/ ==================================================================== The 2016 Scheme and Functional Programming Workshop is calling for submissions. This year we are accepting general presentation proposals in addition to papers. Submissions related to Scheme, Racket, Clojure, and functional programming are welcome and encouraged. Topics of interest include but are not limited to: Program-development environments, debugging, testing Implementation (interpreters, compilers, tools, benchmarks, etc.) Syntax, macros, hygiene Distributed computing, concurrency, parallelism Probabilistic computing Interoperability with other languages, FFIs Continuations, modules, object systems, types Theory, formal semantics, correctness History, evolution and standardization of Scheme Applications, experience and industrial uses of Scheme Education Scheme pearls (elegant, instructive uses of Scheme) We also welcome submissions related to dynamic or multiparadigmatic languages and programming techniques. ==================================================================== Full submissions are due 24 June 2016. Authors will be notified by 22 July 2016. Camera-ready versions are due 15 August 2016. Workshop is 18 September 2016. All deadlines are 23:59 (UTC-12, "Anywhere on Earth"). Paper submissions must be in ACM proceedings format, no smaller than 9-point type (10-point type preferred). Microsoft Word and LaTeX templates for this format are available at: http://www.acm.org/sigs/sigplan/authorInformation.htm Paper submissions should be in PDF and printable on US Letter, and generally in the range of 6 to 12 pages. Presentation submissions should include an outline of the material. Talks are 40 minutes, including questions and answers. More information available at: http://scheme2016.snow-fort.org/ ==================================================================== Organizers: Alex Shinn (General Chair) Kathryn Gray (Program Chair) (Apologies for duplications from cross-posting.) -- Alex

1 0