Gambit-list Mars 2013

gambit-list@iro.umontreal.ca

21 participants
30 discussions

Re: [gambit-list] Gambit-list Digest, Vol 102, Issue 28
by SEJAL SHAH 24 Mar '13

24 Mar '13

Hi, Now I don't want to get this mail please! Sejal. On Sun, Mar 24, 2013 at 1:13 PM, <gambit-list-request(a)iro.umontreal.ca>wrote: > Send Gambit-list mailing list submissions to > gambit-list(a)iro.umontreal.ca > > To subscribe or unsubscribe via the World Wide Web, visit > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list > or, via email, send a message with subject or body 'help' to > gambit-list-request(a)iro.umontreal.ca > > You can reach the person managing the list at > gambit-list-owner(a)iro.umontreal.ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gambit-list digest..." > > > Today's Topics: > > 1. Re: Foreign object printers? (Marc Feeley) > 2. Re: Your feedback would be much appreciated re: Proposal for > enabling IO errors to be reported through returning of a custom > value instead of by throwing exception, through DSL with exports: > ##io-error-behavior param, ##default-io-error-behavior unique > value, ##last-io-error param. (Mikael) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 24 Mar 2013 13:43:38 -0400 > From: Marc Feeley <feeley(a)iro.umontreal.ca> > Subject: Re: [gambit-list] Foreign object printers? > To: Jason Felice <jason.m.felice(a)gmail.com> > Cc: Gambit List <gambit-list(a)iro.umontreal.ca> > Message-ID: <4EA356E8-06FB-477A-9E97-D932618035DB(a)iro.umontreal.ca> > Content-Type: text/plain; charset=iso-8859-1 > > > On 2013-03-24, at 1:16 PM, Jason Felice <jason.m.felice(a)gmail.com> wrote: > > > Whats macro-writeenv-style and ##wr-mark about? > > The style field of a writeenv indicates the style in which the object is > to be written. Currently the style can be > > - write (11 "abc" 22) is written as: (11 "abc" 22) > - display (11 "abc" 22) is written as: (11 abc 22) > - print (11 "abc" 22) is written as: 11abc22 > - pretty-print uses indentation/line breaks for pretty printing > - mark used by #n=... notation > > So the mark style is special in that it does not produce output. It is > used when the readtable-sharing-allowed? flag is set: > > > (define (wr obj allow?) > (call-with-output-string > '() > (lambda (p) > (output-port-readtable-set! > p > (readtable-sharing-allowed?-set > (output-port-readtable p) > allow?)) > (write obj p)))) > > (wr (let ((x (cons 11 22))) (list x x)) #f) > "((11 . 22) (11 . 22))" > > (wr (let ((x (cons 11 22))) (list x x)) #t) > "(#0=(11 . 22) #0#)" > > The write/display/print/pretty-print procedures will make a first pass > over the object/subobjects with style=mark. This is to gather in a table > all the subobjects to write. Then, during the second pass, the #n=... > notation will be used when an object has been marked more than once during > the mark pass. > > Marc > > > > ------------------------------ > > Message: 2 > Date: Sun, 24 Mar 2013 20:12:33 +0200 > From: Mikael <mikael.rcv(a)gmail.com> > Subject: Re: [gambit-list] Your feedback would be much appreciated re: > Proposal for enabling IO errors to be reported through returning > of a > custom value instead of by throwing exception, through DSL with > exports: ##io-error-behavior param, ##default-io-error-behavior > unique > value, ##last-io-error param. > To: Marc Feeley <feeley(a)iro.umontreal.ca>, > gambit-list(a)iro.umontreal.ca > Message-ID: > < > CACbx-M-N+uhevRW9kiY0F6P9NfqqcsGS5X1bqukqbtHChcxwyA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Marc! > > Ah, one thing struck me: in some cases, IO primitives don't raise an > exception on error but instead return a special value, I think it's #!eof > always. > > This would not transform to returning #f by a with-exception-handler > wrapper, but it could with a port specific flag |io-error| or |eof-value| > or |treat-eof-as-error|. > > > > Do you have any thoughts on the previous email on with-exception-handler > and IO error semantics yet? > > Of course there's time though would be great to get this question about how > to reliably do general IO error handling settled. > > > The two possible ways I have the impression that there are now are > > 1) By: > * Add a |treat-eof-as-error| port flag > * Add an optional third arg |first?| to |with-exception-catcher| and > -handler that makes the thunk be invoked first in case of exception. > Internally there's two exception handler chains, the non-first that > works just like the one today - an exception handler added makes it be > invoked as first line in case of exception, and another chain that has > priority over the non-first chain, that's invoked before it and where new > handlers are added at the end and not at the beginning. (Perhaps internally > they can be implemented as one chain only.) > * Make |with-exception-handler| exception handlers recursive (now they > make an infinite loop). > > or > > 2): (Less general solution, so probably not desirable) By: > * Add a port-specific flag |io-error| to IO ports that's invoked in the > current place of both |raise| and eof. > > In either of these two, the IO primitives need to be checked so that the IO > error handling/|raise| calls are done in tail position / place that > produces the primitive's return value anyhow. > > Thanks and best regards, > Mikael > > 2013/3/22 Mikael <mikael.rcv(a)gmail.com> > > > Dear Marc, > > > > Spontaneously I think that the prospect of using with-exception-handler > as > > you propose sounds better than adding custom error behavior code to the > IO, > > as, the w.e.h. route would be more holistic in that it maintains the > error > > handling mechanism in Gambit one in total in number; also, > > > > It would work from a performance point of view as there is no overhead > per > > IO primitive call that's successful, which accounts for almost all of > them. > > The only potential issue with performance would be if the exception > handler > > part would take a lot of time, though I guess it can be generalized that > > that is not an issue. > > > > Then I guess the last point would be the design aspect that if somehow IO > > code would be run outside the current environment that the w.e.h. is > > installed in, the custom error behavior would disappear; that would > indeed > > be a benefit with a port specific flag, that it's not subject to the same > > limitation. Though, from the practical use I see today, that more or less > > does not happen so it's fine. > > > > > > I didn't think deeper about the possibility of w.e.h. before as I found > > myself without clarity on how the things I addressed in the previous > email > > could be solved, as they need to be solved for it to be a practically > > viable solution. > > > > > > Looking forward a lot to hear your take on those two-three things and > > hopefully get to a reliable io-error => #f soon =) > > > > Thanks, > > Mikael > > > > > > > > 2013/3/20 Mikael > > > > Hi Marc! > >> > >> > >> 2013/3/18 Marc Feeley <feeley(a)iro.umontreal.ca> > >> > >>> The problem I see with the approach you propose (whether it uses a > >>> parameter or a port specific flag) is that the semantics of an > "io-error" > >>> is vague. What is an IO error? The definition is important because > >>> exceptions that are IO errors are going to be processed using this new > >>> mechanism, and non-IO exceptions will use a different mechanism (normal > >>> exception handling). > >>> > >>> The approach I propose does not have this problem because the > programmer > >>> has complete control over the definition of an IO error. The exception > >>> object can be inspected to see if it qualifies as an IO error and an > >>> appropriate action can be taken. The definition of IO error can > depend on > >>> the type of port, the type of primitive which caused the exception > >>> (read-u8, read-char, read), etc. > >>> > >>> Marc > >>> > >>> > >> Aha. To really get this, there are two quite fundamental things about > the > >> applicability of the with-exception-handler possibility that I maybe > don't > >> get yet or at least would benefit of clarification, can we have a look > at > >> it? > >> > >> Also last a question re semantics of io-error. > >> > >> > >> > >> So, for the with-exception-handler mechanism to work out, it needs to go > >> together with other use of exception handling use that's being done in > the > >> same scope. > >> > >> In a setup where there's another exception handler *outside* the IO > >> with-exception-handler, there would be no issue as the IO w.e.h. 's > handler > >> would be invoked first for any exception that occurs, and do its > matching > >> and handling. > >> > >> In a setup where the other exception handler is made *inside* the IO > >> w.e.h. though, any IO exception that arises within that exception > handler > >> will be picked up by it first, and for the IO w.e.h. thing to work out, > >> that handler needs to be able to pass on the exception to the parent > >> exception handler (which is the IO w.e.h.) completely in its original > >> shape, in such a way that if the IO w.e.h. handler returns a value, that > >> will be passed as return value to the original |raise| call. > >> > >> An example of this would be a web-based PI calculator that uses > exception > >> handling locally in its PI calculate request thunk to pick up invalid > user > >> input. > >> > >> So let's ask how this could be done. > >> > >> Let's say below that we have a procedure (install-io-w.e.h. port thunk) > that > >> installs the IO w.e.h. that makes IO primitives return #f on exception, > so > >> that thunk is invoked with that w.e.h. installed. > >> > >> Then, we have application logics (logics) that, aside from using IO, > >> internally uses exception handling. > >> > >> So a setup something like, > >> > >> (define (logics) > >> (with-exception-catcher > >> (lambda (e) "Logics failed due to invalid user input!") > >> (lambda () > >> (pp (read-u8 broken-port)) > >> (/ 0 0) ; This is to simulate an exception due to invalid user > >> input. > >> ))) > >> (install-io-w.e.h. broken-port logics) > >> > >> > >> The desired behavior here is to print #f to the console and for logics > >> to then return "Logics failed due to invalid user input!". > >> > >> The issue now becomes, how would this local exception handler need to be > >> implemented as for this to work out. > >> > >> > >> The local exception handler needs to be specific about what kind of > error > >> it looks for as to know which to handle locally and which to re-raise. > This > >> might be a complete PITA in some situations as you're looking for a > >> catch-all behavior, as in the example above! > >> > >> Perhaps the order of exception handlers could be tweaked somehow, so > that > >> the IO w.e.h. would get highest priority or something, though how could > >> that be made as a 'clean' abstraction? I mean, who's in a place to > claim at > >> a general level that one exception is of higher prio than another? - > >> different classes could be introduced, like, "user exceptions" and "io > >> exceptions" or "system exception" (this would lead to an at least almost > >> functional equivalent of the port specific flag solution, just with a > more > >> indirect code path!), or, the exception matching procedure could be > >> exported to a separate mechanism, and the exception handler claiming the > >> highest specificity in the matching would get to handle it e.g. > (with-exception-handler > >> exception-match exception-handler thunk) where exception-match takes an > >> exception argument e and returns how well it matches the exception, i > duno > >> as a boolean or 0-10 or a symbol. > >> > >> Or, a global parameter object |is-nonlocal-exception?| could be > >> introduced that any exception handler is free to invoke as to check if > it > >> should re-raise the exception, and to overlap.. hmm, a more general > >> solution would be better. > >> > >> Do you see any general solution to this specificity problem? > >> > >> > >> > >> > >> > >> > >> Now to get to the next thing, let's just presume there's a solution to > >> this and we represent it in this example as a (if > >> (is-nonlocal-exception? e) (raise e) condition in the local exception > >> handler, again not because this would necessarily represent a general > >> solution but just to get on to the next thing in the reasoning; so now > we > >> have > >> > >> (define (logics) > >> (with-exception-catcher > >> (lambda (e) (if (is-nonlocal-exception? e) (raise e) "Logics failed > >> due to invalid user input!")) > >> (lambda () > >> (pp (read-u8 broken-port)) > >> (/ 0 0) ; This is to simulate an exception due to invalid user > >> input. > >> ))) > >> (install-io-w.e.h. broken-port logics) > >> > >> > >> Now, how do you make this *parent* exception handler (the IO w.e.h.) > that > >> got the exception passed to it, able to pass a return value to the > original > >> |raise| call? > >> > >> This is required for the exception handling-based IO error handling > >> behavior we're looking for to work. > >> > >> The problem reduces to > >> > >> (define (logics) (raise "Please return 'properly-handled!")) > >> > >> (define (proxy-exception-handler/catcher2 thunk) (lambda () > >> (with-exception-catcher (lambda (e) (raise e)) thunk))) > >> > >> (define (proxy-exception-handler/catcher1 thunk) (lambda () > >> (with-exception-handler (lambda (e) (raise e)) thunk))) > >> > >> (define (parent-exception-handler thunk) (continuation-capture (lambda > >> (cont) (with-exception-handler (lambda (e) 'properly-handled!) thunk)))) > >> > >> where proxy-exception-handler/catcher 1 & 2 are to represent an > arbitrary > >> chain of exception handlers that logics code may come up with. The > intended > >> behavior is > >> > >> > >> (parent-exception-handler (proxy-exception-handler/catcher1 > (proxy-exception-handler/catcher2 > >> logics))) => 'properly-handled! > >> > >> (parent-exception-handler (proxy-exception-handler/catcher1 logics)) => > >> 'properly-handled! > >> > >> (parent-exception-handler (proxy-exception-handler/catcher2 logics)) => > >> 'properly-handled! > >> > >> > >> > >> Actually evaluating these three tests showed: > >> > >> (parent-exception-handler (proxy-exception-handler/catcher1 > (proxy-exception-handler/catcher2 > >> logics))) => infinite loop (!) > >> > >> (parent-exception-handler (proxy-exception-handler/catcher1 logics)) => > infinite > >> loop (!) > >> > >> (parent-exception-handler (proxy-exception-handler/catcher2 logics)) => > >> 'properly-handled! > >> > >> > >> To start with, great that we see that with-exception-catcher delivers > out > >> of the box for this usecase! > >> > >> Thus we have with-exception-handler left. I guess the best way would be > >> if with-exception-handler inherently somehow would deliver for this, so > >> that support for this kind of use would be transparent and not require > >> possible updates of user code (e.g. any typical user code such as a PI > >> calculator etc. could without needing code review just be run within a > web > >> server that uses this special IO error handling). > >> > >> Is there any way to make with-exception-handler deliver for this > usecase? > >> > >> > >> > >> > >> > >> > >> Last, what about that for introducing a port specific flag there would > be > >> the issue that the semantics of an IO error is vague - > >> > >> Maybe you see something here I didn't get. As IO error for a port would > >> count any error reported from the OS about the port, as well as timeouts > >> within Gambit's IO system. > >> > >> So this would correspond to any OS IO primitive invocation that gives an > >> error return value (other than one that asks for a reiteration of the > >> procedure, which some of them come with). > >> > >> Another way to relate to it would be that such a port specific flag > would > >> serve to protect from requirement of programmer or admin intervention > for > >> any IO error that could possibly come up regarding the addressed ports. > >> > >> What do you see here? > >> > >> > >> > >> Best regards, > >> Mikael > >> > >> > >> > > >

1 0

Foreign object printers?
by Jason Felice 24 Mar '13

24 Mar '13

Is there a way to register or implement a printer for a specific foreign type? -Jason

3 6

OpenSSL SSL channels module pre-release and HTTP client early pre-release, attached
by Mikael 24 Mar '13

24 Mar '13

Hi guys, For anyone interested here's the pre-release version of the OpenSSL SSL channels ("openssl") module and an early pre-release of the HTTP client. (If you read this after May 2013 the attachment is most probably outdated and you better look at https://github.com/gambit-community or https://github.com/m-i-k-a-e-l/ .) *openssl module* The openssl module works extremely well and is mature. Relative to the amount of functionality provided, extreme effort has been put into its making. This is because OpenSSL's documentation on nonblocking use is incorrect in several parts, so study of other user implementations and practical testing has been required to make it work. Over the course of a couple of years, in the range three man weeks has gone into it this way. Due to that this is the nature of the problem addressed by this module, I hope that this openssl module will be the main one for Gambit and that any more effort into OpenSSL SSL channel modules in Gambit will go into making this one even better. The current version however relies on a version-unsafe hack for extracting the respective TCP port's socket, which possibly would be a feature to be included in Gambit, please see the "Next steps for release" section below. OpenSSL is let to write and read from the OS socket directly. This saves lots of roundtrips and buffering. *http-client module* The HTTP client supports the passing of custom method, headers and request body, and supports retrieval of status code, headers and request body, and it does both these with support for all of HTTP 1.0 and 1.1, so this is all there is to the HTTP protocol in itself. Exports: (simple-raw-http-request uri #!optional request-body (headers '())) => req (define-macro (with-http-client-all-response all-response . code) `(apply (lambda (reached-uri result stage status-code headers get-header response) ,@code) ,all-response)) (define (simple-raw-http-request-resp uri #!optional request-body) (with-http-client-all-response (simple-raw-http-request uri request-body) response)) Use: > (simple-raw-http-request "http://www.iro.umontreal.ca/~gambit/") (#<uri #13 scheme: "http" userinfo: #f host: "www.iro.umontreal.ca" port: #f path: "/~gambit/" query: () fragment: #f> #t done 200 (("connection" . "close") ("content-type" . "text/html") ("content-length" . "115") ("accept-ranges" . "bytes") ("etag" . "\"1c93d75-73-4443e1da730c0\"") ("last-modified" . "Mon, 21 Jan 2008 16:38:03 GMT") ("server" . "Apache/2.0.54 (Fedora)") ("date" . "Wed, 20 Mar 2013 19:20:12 GMT")) #<procedure #14 26#get-header> "<HTML>\n<HEAD>\n<META HTTP-EQUIV=REFRESH CONTENT=0;URL= http://dynamo.iro.umontreal.ca/~gambit/wiki/>\n</HEAD>\n</HTML>\n") > (simple-raw-http-request-resp "http://www.iro.umontreal.ca/~gambit/") "<HTML>\n<HEAD>\n<META HTTP-EQUIV=REFRESH CONTENT=0;URL= http://dynamo.iro.umontreal.ca/~gambit/wiki/>\n</HEAD>\n</HTML>\n" Currently it supports single threaded execution i.e. it opens HTTP connection, makes request, retrieves response and closes the connection in a sequence and there's no connection reuse - reuse and multiplexing across threads as well as following redirects will be implemented. Also invocation of several declared callbacks is not done currently, and will be trivial to implement. The DSL uses Sack's idea of providing all protocol functionality in a 'core' form. It can extremely easily be wrapped to a XMLHTTPRequest object. This http-client module replaces Sack's previous http-client module, which unlike Sack's web server module which works great, had terrible problems, for more info see the header section in http-client.scm . *Next steps for release* I'll make a "real" release of these two modules when the IO exception handling question discussed on the list now has got an answer and maybe extraction of TCP port socket can be done with a Gambit-builtin procedure. These two things currently bring version-unsafe hacks into the code, more specifically into tcpip.scm and sack/src/gamgambit-noexceptions-io.scm , so this is why I call this a pre-release. (Note that port-wait-for-input and port-wait-for-output of the tcpip module are not needed anymore as the firstmentioned has been in Gambit all the time and the latter was recently included in Gambit, ##-prefixed. Will remove them when I doublechecked they're in the newest Gambit version's namespace. As it looks the tcpip module will be removed.) *Future development* I'll be happy to see when current Black Hole will have package management functionality so that installation of these packages will be easy. Currently the OpenSSL module exports its functionality as a set of IO primitive closures, and, the HTTP server and client uses such IO primitive closures for interaction with its underlying IO layer. When there will be good support for application-layer port implementations in Gambit - I hope that will happen the next 1.5 years or so, we'll see - the HTTP server and client will use Gambit's IO primitives directly instead of these custom primitives, which will provide for a cleaner and more general code, and, The OpenSSL module and I suppose the HTTP-client (and probably HTTP server too) will export Gambit ports for use something like (open-ssl-channel-port settings) => port (open-http-client-port settings (lambda (request-body-port) (display .. request-body-port))) => response-body-port Thoughts, feedback, patches much welcome. Best regards, Mikael

1 1

Compilation of gambit (git master) on/for Windows 7 64 bit using mingw64 x86_64 fails
by panos stergiotis 23 Mar '13

23 Mar '13

1 0

(Ought to be counted as solved) Re: [...] reproducible pita bug: SIGSEGV on every ordinary termination (, q (exit) etc.) on Gambit-current on OpenBSD-current w at least g++ 4.7.2 & 4.6.3
by Mikael 20 Mar '13

20 Mar '13

Looks like this was because of some weird version incompatibility issue between libc or libstdc++ versions. I tried to track it down with ldd and didn't find it in a clear way, though, since with certain libc and libstdc++ choices this error goes away, it should plausibly have been in the first place because of version incompatibility. Generally on OBSD only the default GCC version is used, and use of G++ is not so much discussed, in particular not non-bundled versions of it, so there seem to be no clarification to get on this topic out there also. I read on a blog somewhere something like that if you have two two libstdc++ versions at the same time, it can be that the exception handling helper code gets loaded from another one than your application was compiled for and that you get undefined behavior and crashes that way. Don't remember right now if that was relevant to this though right now I'd think so. For now I relate to it as solved anyhow as for the OBSD versions I saw there's at least one G++ + GCC package that works well for compiling and executing Gambit. Thanks, Mikael 2013/1/12 Mikael > Dear Marc, > > Now had the occasion to go through if Gambit termination works on > different GCC & G++ versions in OpenBSD 5.2 AMD64 default. > > I did not check with the "-latest" aka snapshot OBSD release this time, > that could of course provide additional information, though sponaneously I > would guess that the issue with eg++ (GCC) 4.7.1 in the default release as > described below has the same underlying cause, as the output looks exactly > the same. > > This test make clear that there is a way to get Gambit going without > issues on OBSD, so, > > As far as I'm personally concerned this is a solved issue. > > > > For completeness, here are the results: > > Correct behavior of Gambit termination for different GCC & G++ versions on > OBSD 5.2 AMD64 non-snapshot is as follows: > > gcc (GCC) 4.2.1 20070719 (this is the bundled version): Worked. (also > ./configure --enable-single-host worked) > g++ (GCC) 4.2.1 20070719 (this is the bundled version): Worked. > > egcc (GCC) 4.6.3: Worked. > eg++ (GCC) 4.6.3: Worked. > > egcc (GCC) 4.7.1: Worked. > eg++ (GCC) 4.7.1: FAIL > > For GCC compilation, ./configure --enable-single-host --enable-debug was > used. > For G++ compilation, ./configure --enable-single-host --enable-debug > --enable-cplusplus was used. > > For invocation of the non-default version, CC=/usr/local/bin/egcc or > CXX=/usr/local/bin/eg++ respectively was > added as prefix to the ./configure command line, in bash. > > make clean was used to reset the GCC directory between compilations. The > g++ 4.6.3 compilation was also double-checked by also compiling from a > fresh Gambit source copy. > > Gambit compiled with eg++ (GCC) 4.7.1 produces the following in response > to ,q : > > Gambit v4.6.6 > > > ,q > terminate called after throwing an instance of '___throw_struct' > terminate called recursively > Abort trap (core dumped) > > > > If I recall right, on the snapshot OBSD AMD64 release, this failure > behavior was on both the 4.6 and 4.7 G++, and I did not try the 4.2 release > at all due to ./configure's warning about excessive RAM consumption. > > > The only hint I picked up as regards the source of this issue, is that it > might have to do with that 4.7.1 perhaps brings an alternative libstdc++ > package (libstdc++ 4.7.1 it's called) while perhaps the other ones don't. I > would guess this was not an issue though - it would make no sense for them > to publish a problematic package without making the installer print a > warning or alike. #openbsd seems to have nothing to say on the topic. > > > > If there would be any checks I could do for completeness at some point, > feel free to mention them. > > Thanks and with best regards, > Mikael > >

1 0

Running gambit program
by Steve Graham 19 Mar '13

19 Mar '13

Trying to figure out how to run a Gambit-C program from a Linux shell script. These don't seem to work: gsi <filename> gsi - <filename> gsi -e <filename> What does work? Thanks, Steve

4 19

ICFP 2013: Second Call for Papers
by David Van Horn 16 Mar '13

16 Mar '13

===================================================================== 18th ACM SIGPLAN International Conference on Functional Programming ICFP 2013 Boston, MA, USA, 25-27 September 2013 http://www.icfpconference.org/icfp2013 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Submissions due: Thursday, 28 March 2013 23:59 UTC-11 (Pago Pago, American Samoa, time) Author response: Wednesday, 22 May 0:00 UTC-11 Friday, 24 May 2013 23:59 UTC-11 Notification: Friday, 7 June 2013 Final copy due: Friday, 5 July 2013 Scope ~~~~~ ICFP 2013 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency and distribution; modules; components and composition; metaprogramming; interoperability; type systems; relations to imperative, object-oriented, or logic programming * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types * Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security * Education: teaching introductory programming; parallel programming; mathematical proof; algebra * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By Thursday, 28 March 2013, 23:59 UTC-11 (American Samoa time), submit a full paper of at most 12 pages (6 pages for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication * Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available:http://www.acm.org/sigs/sigplan/authorInformation.htm Submission: Submissions will be accepted on the web athttps://www.easychair.org/conferences/?conf=icfp2013 . Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 0:00 UTC-11 on Wednesday, 22 May 2013, to read reviews and respond to them. Special Journal Issue: There will be a special issue of the Journal of Functional Programming with papers from ICFP 2013. The program committee will invite the authors of select accepted papers to submit a journal version to this issue. General Chair: Greg Morrisett, Harvard University Program Chair: Tarmo Uustalu, Institute of Cybernetics, Tallinn Program Committee: Thorsten Altenkirch, University of Nottingham Olaf Chitil, University of Kent Silvia Ghilezan, University of Novi Sad Michael Hanus, Christian-Albrechts-Universität zu Kiel Fritz Henglein, University of Copenhagen Mauro Jaskelioff, Universidad Nacional de Rosario Alan Jeffrey, Alcatel-Lucent Bell Labs Shin-ya Katsumata, Kyoto University Shriram Krishnamurthi, Brown University John Launchbury, Galois Ryan Newton, Indiana University Sungwoo Park, Pohang University of Science and Technology Sam Staton, University of Cambridge Nikhil Swamy, Microsoft Research, Redmond, WA Dimitrios Vytiniotis, Microsoft Research, Cambridge

1 0

Old programmers
by Steve Graham 13 Mar '13

13 Mar '13

Compute or Creative Computing gave me absolute addressing for the C-64. ________________________________ From: mikel evins <mevins(a)me.com> To: Jason Felice <jason.m.felice(a)gmail.com> Cc: gambit List <gambit-list(a)iro.umontreal.ca> Sent: Wednesday, March 13, 2013 1:29 PM Subject: Re: [gambit-list] Old programmers On Mar 13, 2013, at 1:51 PM, Jason Felice <jason.m.felice(a)gmail.com> wrote: > Compute's Gazette and Byte! magazine FTW! > Hail, Brother! COMPUTE! is where I got the assembler. _______________________________________________ Gambit-list mailing list Gambit-list(a)iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

1 0

Old programmers
by Bradley Lucier 13 Mar '13

13 Mar '13

From: http://www.teamliquid.net/blogs/viewblog.php?topic_id=401393&currentpage=2 I am learning to code a little right now while taking all of my basics in college. I will continue the line that our family has with programming. My grandpa coded (with punchcards no less), my mom codes and I will code. In the name of all punchcard-programming grandpas, all I can say is "Ouch, that one hurt." Brad

8 8

Transforming top-level program code
by Jason Felice 13 Mar '13

13 Mar '13

I've had a couple ideas for modifications to the Scheme reader that I imagine would be front-ends to the compiler. Examples: 1. A front end which reads Scheme source but specially handles square braces, transforming them into Objective-C method calls via my library, so that I can put the following in a program: (let ((s [[NSString alloc] initWithCapacity:42])) ...) And have it dispatch non-dynamically (my current project is completely dynamic). 2. A testing library where "check" forms appear under each function in the same file as documentation. The check forms normally expand to nothing, but a command can be run from the command line scans the current directory and sub-directories for .scm files which (check ...) forms in them and runs them. 3. A complete environment with support for a lot of SRFI's and utility functions built in - a new REPL/compiler which is specialized for some domain. Black hole appears to do something like this. My question is, how do I hook into Gambit to compile or interpret after I've transformed the code, preserving line numbers?

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Mars 2013