Re: [racket-dev] Tweaked doc pages
On Thu, Mar 7, 2013 at 3:36 AM, Eli Barzilay wrote: > They are already indexed, but it happens to be a very popular name so > there are tons of results before it. (Try searching for "stxparam" to > see that it works.) Ooops. You are right. I gave up too soon. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Tweaked doc pages
Four hours ago, Matthias Felleisen wrote: > > I like it. It's up now, at docs.racket-lang.org . 8 hours ago, Robby Findler wrote: > What about moving the google search to the search results page, > saying something like "didn't find what you were looking for? Try a > google-based search." instead of having two searches next to each > other in a somewhat confusing way? That would be inconvenient to a point where it won't get used... In any case, the two searches are very different in their nature, so very often you'll want to use either one or the other. 8 hours ago, Pierpaolo Bernardi wrote: > > Neither Racket's search nor Google's one report the racket/format > module, searching for "format". I thought Google would find it, but > it doesn't. (I don't know how Google indexes things...) > It appears that module names are not indexed? Probably they should be? They are already indexed, but it happens to be a very popular name so there are tons of results before it. (Try searching for "stxparam" to see that it works.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
On Mar 6, 2013, at 7:09 PM, Eli Barzilay wrote: > Um, no, I don't think that this is similar. Okay. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
Four hours ago, mikel evins wrote: > > On Mar 6, 2013, at 11:42 AM, Eli Barzilay wrote: > > > > Aha -- in that case, it seems that your image-based workflow is > > not much different from working with just the sources *and* the > > (byte-) compiled files that go with them, right? > > Imagine meeting someone who had never used a REPL, and trying to > explain what its point is. At some point he might say to you, "so a > REPL really isn't much different from just batch-compiling some > sources, is it? After all, in both cases it's just one line of code > after another getting executed, right?" > > [...] > > The same is true of image-based development. It's "not much > different" from just using source files in the same way that using a > REPL is "not much different" from just batch-compiling everything. Um, no, I don't think that this is similar. (And like I said before, I think that if you compare the two features, an interactive REPL is far more useful than images.) The only point that maybe you're trying to make is that I should use images to see what they're useful (and that would be a weak point since I have). Let's take an imaginary world where batch compilation is always very fast -- say that I push a key and the whole source code gets compiled in 50msecs. In this world, an interactive REPL is still not close to compilation + experimentation (for reasons that should be very clear to people on this list). Now, what would be the difference in this world in terms of compilation vs image dumping? One minor difference that I've mentioned is the convenience of a single file. The big difference would be that various things that I played with on the REPL but not in source are included in the image -- and as you've agreed before, such "binary only" objects are not very useful. And just to make things balanced -- dumping an image is not always an immediate process. At least in the lisps that I used, you'd usually want to do some form of tree shaking on the dump. (And IIRC, at least in some environments the tree shaker was a part of the dumping process by default which you'd turn off explicitly if you don't want it.) > I'm not sure why you put scare-quotes on "compilation". [...] You misunderstood me. I used quotes because I didn't mean the actual compilation that you're referring to -- I just equated the `dump-image' functionality with a compilation. IOW, I'm saying that in both developement styles you need to do something to get the distributables, so dumping an image is a kind of a compilation in that sense. > That's possible, but I doubt it. I worked with teams of up to > several dozen people working with image-based systems, and to my > knowledge, none of them ever worked that way. (Actually, I misremembered -- I *did* work in a group that used images, but the images were done very infrequently, and for pretty much all of the day-to-day work we'd use sources.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Tweaked doc pages
I like it. On Mar 6, 2013, at 11:59 AM, Eli Barzilay wrote: > I have the minimal things that I wanted in a working state now: > > * Links to the PDF versions next to the version. > > * A selection box for different versions of documents. > > * A google custom search. > > All of this is now visible on newdocs.racket-lang.org, but the older > versions go to the right place on docs.racket-lang.org so you'll get > to the current version of the pages. > > Unless there are some objections to all of this, I'll make it go on > docs soon. > > > About the google search: I'm not too happy about it -- they have > better layouts for the search which I couldn't get to work properly, > but this sucked enough time that I decided to just hack things to some > acceptable state and leave it at that. If anyone is interested in > improving it, I can tell you how to play with it. (More higher level > comments in a separate followup that I'll post in a few minutes.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >http://barzilay.org/ Maze is Life! > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
On Mar 6, 2013, at 11:42 AM, Eli Barzilay wrote: > 20 minutes ago, mikel evins wrote: >> >> Rather than answer your questions directly, it seems much easier and >> more apropos to address the underlying assumption that images and >> source files are somehow mutually exclusive. They're not. Adding the >> ability to save and load images does not subtract the ability to >> work with source files. I don't know why people seem to think that. > > Aha -- in that case, it seems that your image-based workflow is not > much different from working with just the sources *and* the (byte-) > compiled files that go with them, right? Imagine meeting someone who had never used a REPL, and trying to explain what its point is. At some point he might say to you, "so a REPL really isn't much different from just batch-compiling some sources, is it? After all, in both cases it's just one line of code after another getting executed, right?" I've actually been in that conversation. If the person you're talking with has no experience of working with an interactive environment with a REPL, then it may be hard to convey what it's good for. The other person, attempting to get the point of it, and to understand what it is and what it does, interprets your descriptions in terms he's familiar with, leading to glosses like the one above: yeah, in a strained sense, a REPL isn't much different from just batch-compiling and running some source files. But presumably you know from experience that actually using a REPL is in fact very different from just batch-compiling everything, and leads to a very different experience and a very different workflow. A batch compiler--however fast--is not a substitute for a REPL. The same is true of image-based development. It's "not much different" from just using source files in the same way that using a REPL is "not much different" from just batch-compiling everything. > There are some technical differences like one big file instead of a > bunch of them, and the fact that instead of invoking an external tool > you're doing the "compilation" inside the environment and it becomes > part of the next dump. These obviously make it more convenient than > what I'm talking about -- but at the highlevel it looks similar. This description doesn't sound very much like any work I ever actually did. I've always used both lots of image files and lots of source files. I'm not sure why you put scare-quotes on "compilation". MCL, CCL, SBCL, Lispworks, Allegro, and I'm sure Lisps I'm neglecting to mention all compile to native code in-memory, and can all also produce object files and link them to form executable binaries. All of them can save and load images containing compiled code. MacScheme, like lots of Smalltalk implementations, could do all of that, too, but with bytecode in place of native code. That's just what I need: compilation to efficient portable bytecode and image saving and loading. > Assuming that, the disadvanate that I see is in the disconnection > between the images and the sources: sure you have both, but what if > during my interactions I've somehow managed to get something work > really well "by mistake" -- I can see myself sitting at the computer a > month later being infinitely puzzeled with "how did I get *that* to > work"... > So if I had worked with images, I would probably end up > starting from the plain sources very often since I'd be worried about > work that gets lost this way. That's possible, but I doubt it. I worked with teams of up to several dozen people working with image-based systems, and to my knowledge, none of them ever worked that way. We did build everything from scratch from sources all the time, but we had scripts to do that constantly as part of automated testing. There was little or no need to do it by hand. >> If you aren't interested in images, or don't like them, don't use >> them. I'm not here to convert anybody. [...] > > BTW, I'm not arguing against it -- I have reasons to dislike "proper" > development happening with them. But what you're describing is not > forcing that -- and I wonder what is it exactly that makes this > particular feature so great. (When I worked with images, I used them > only as a distribution tool -- I didn't have experience with them for > actual development with other people, so the target audience would be > people who just run it.) I don't know what to tell you other than what I've already told you. If that's not persuasive, I'm okay with that. You don't have to like or want it just because I do. >> Matthew and Matthias seem to be saying they think platform- >> independent images are probably doable; that's good enough for me, >> for now. If it turns out they're wrong, well, I can work around >> that. There are other options. It'll grow back. > > Well, it would be nice to know how exactly this would look like. So > far, I think that it's roughly a way to dump the current state as a > ki
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
On Mar 6, 2013, at 11:40 AM, Stephen Bloch wrote: > > On Mar 6, 2013, at 11:54 AM, mikel evins wrote: > >> Rather than answer your questions directly, it seems much easier and more >> apropos to address the underlying assumption that images and source files >> are somehow mutually exclusive. They're not. Adding the ability to save and >> load images does not subtract the ability to work with source files. I don't >> know why people seem to think that. > > I don't think anybody has said (or assumed) exactly that. My concern would > be that a workflow involving heavy use of images would TEND towards creating > functionality for which there is no source code. > > In other words, the images don't make it impossible to work with source > files, but they make it possible and tempting to work without source files. > Is there a price to be paid for that, eventually? I honestly don't know. That has not been my experience. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
On Wed, Mar 6, 2013 at 5:40 PM, Stephen Bloch wrote: > > On Mar 6, 2013, at 11:54 AM, mikel evins wrote: > > > Rather than answer your questions directly, it seems much easier and > more apropos to address the underlying assumption that images and source > files are somehow mutually exclusive. They're not. Adding the ability to > save and load images does not subtract the ability to work with source > files. I don't know why people seem to think that. > > I don't think anybody has said (or assumed) exactly that. My concern > would be that a workflow involving heavy use of images would TEND towards > creating functionality for which there is no source code. > > In other words, the images don't make it impossible to work with source > files, but they make it possible and tempting to work without source files. > No, they don't. AFAIK, only in Smalltalk and Interlisp environments developers worked without source files. . In the Symbolics, LMI, and Explorer Lisp Machines, developers always used source files. In the company where I worked, we used images everyday and no one ever thought about not using source files. We also had a development environment (KEE) where methods could be edited either using a sort of code browser similar to the one used in Smalltalk or the regular ZEmacs editor and normal source files. Everybody preferred the second approach. Best, Antonio. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
20 minutes ago, mikel evins wrote: > > Rather than answer your questions directly, it seems much easier and > more apropos to address the underlying assumption that images and > source files are somehow mutually exclusive. They're not. Adding the > ability to save and load images does not subtract the ability to > work with source files. I don't know why people seem to think that. Aha -- in that case, it seems that your image-based workflow is not much different from working with just the sources *and* the (byte-) compiled files that go with them, right? There are some technical differences like one big file instead of a bunch of them, and the fact that instead of invoking an external tool you're doing the "compilation" inside the environment and it becomes part of the next dump. These obviously make it more convenient than what I'm talking about -- but at the highlevel it looks similar. Assuming that, the disadvanate that I see is in the disconnection between the images and the sources: sure you have both, but what if during my interactions I've somehow managed to get something work really well "by mistake" -- I can see myself sitting at the computer a month later being infinitely puzzeled with "how did I get *that* to work"... So if I had worked with images, I would probably end up starting from the plain sources very often since I'd be worried about work that gets lost this way. > If you aren't interested in images, or don't like them, don't use > them. I'm not here to convert anybody. [...] BTW, I'm not arguing against it -- I have reasons to dislike "proper" development happening with them. But what you're describing is not forcing that -- and I wonder what is it exactly that makes this particular feature so great. (When I worked with images, I used them only as a distribution tool -- I didn't have experience with them for actual development with other people, so the target audience would be people who just run it.) > Matthew and Matthias seem to be saying they think platform- > independent images are probably doable; that's good enough for me, > for now. If it turns out they're wrong, well, I can work around > that. There are other options. It'll grow back. Well, it would be nice to know how exactly this would look like. So far, I think that it's roughly a way to dump the current state as a kind of zo file -- extended with the ability to serialize more values, and extended to represent a whole environment rather than a single module or a single piece of data. Note that clarifying that this is more like zo files was important, since it clarifies that the "dump" doesn't have to be a straight *memory* dump. Assuming this, I think that you can start with dumping the current namespace as a zo file -- something like: (define (dump-image file) (call-with-output-file file (λ(o) (s-exp->fasl (current-namespace) o (define (load-image file) (current-namespace (call-with-input-file "i" fasl->s-exp))) This is of course far from working... The first problem is that a namespace cannot be written this way. So there would be some scanner that turns it into something that can, maybe adding some representation layer on top of plain values. Making it work for everything else (including required modules etc) that you can reach from the namespace is probably "the only thing" that is needed... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Tweaked doc pages
On Wed, Mar 6, 2013 at 6:15 PM, Eli Barzilay wrote: > There's no practical way to unify the two searches since they are > implemented in a completely different way all the way to how the end > user interacts with them. Neither Racket's search nor Google's one report the racket/format module, searching for "format". I thought Google would find it, but it doesn't. This caused me to use SRFI/48 some days ago, because I didn't remember where the formatting functions resided. :) It appears that module names are not indexed? Probably they should be? Cheers P. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Tweaked doc pages
What about moving the google search to the search results page, saying something like "didn't find what you were looking for? Try a google-based search." instead of having two searches next to each other in a somewhat confusing way? (I think someone else made this suggestion; apologies if I missed the reply) Robby On Wed, Mar 6, 2013 at 11:46 AM, Eli Barzilay wrote: > A few minutes ago, Danny Yoo wrote: > > > > The other thing that would be nice is if the prior versions of the > > docs also included these updates too, but if that can't happen > > easily, oh well. > > Yes -- they all have that. It's just that the previous versions that > are generated now are inaccessible... Once I switch docs you'll have > them too. > > (Maybe I should do that now? It's a quick flip-of-a-symlink thing...) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
On Mar 6, 2013, at 11:54 AM, mikel evins wrote: > Rather than answer your questions directly, it seems much easier and more > apropos to address the underlying assumption that images and source files are > somehow mutually exclusive. They're not. Adding the ability to save and load > images does not subtract the ability to work with source files. I don't know > why people seem to think that. I don't think anybody has said (or assumed) exactly that. My concern would be that a workflow involving heavy use of images would TEND towards creating functionality for which there is no source code. In other words, the images don't make it impossible to work with source files, but they make it possible and tempting to work without source files. Is there a price to be paid for that, eventually? I honestly don't know. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Tweaked doc pages
A few minutes ago, Danny Yoo wrote: > > The other thing that would be nice is if the prior versions of the > docs also included these updates too, but if that can't happen > easily, oh well. Yes -- they all have that. It's just that the previous versions that are generated now are inaccessible... Once I switch docs you'll have them too. (Maybe I should do that now? It's a quick flip-of-a-symlink thing...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Tweaked doc pages
On Wed, Mar 6, 2013 at 9:59 AM, Eli Barzilay wrote: > I have the minimal things that I wanted in a working state now: > > * Links to the PDF versions next to the version. > > * A selection box for different versions of documents. > > * A google custom search. > > All of this is now visible on newdocs.racket-lang.org, but the older > versions go to the right place on docs.racket-lang.org so you'll get > to the current version of the pages. Sweet. 1+!! The other thing that would be nice is if the prior versions of the docs also included these updates too, but if that can't happen easily, oh well. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Tweaked doc pages
Yesterday, Michael Wilber wrote: > The Google search box seems a bit disorienting to me. Perhaps I just > learned Racket, say yesterday, and it's unclear what it provides > that isn't searched by the search box in the top middle. It might be > nice to integrate that with the results page somehow, like a "Didn't > find what you're looking for? Here are some Google search results > for your query on racket-lang.org, stackoverflow, ..." Yes, I know that it can be confusing -- but I hope that the "Google Custom Search" label clarifies it a little. There's no practical way to unify the two searches since they are implemented in a completely different way all the way to how the end user interacts with them. For example, the google search box has its own completion mechanism while our search box doesn't (and instead does something similar on the search page). Another difference is that our search goes to a specific search page while the google results are shown in-line -- it would be nice for our search to be shown in-line too, but that's impractical since our search is all done on the client rather than on the server, and you don't want all pages to load the huge index. This might improve in the future with a server-backed search that would be used in the on-line version. As for additional searches -- I think that most of them would get covered by the google search. For example, google does index stackoverflow well. The reason that this doesn't happen now is that the google custom search that I made is restricted to only docs.racket-lang.org. It would be good to play with it and use more of their features. They have the concept of "refinments" which, I think, can be used to have a custom search work as it does now, but have links at the top that will show results from all sites, or even add refinments that would show results from stackoverflow etc. So overall, it would be very helpful if someone looks into all of these things. Like I said in the other post -- if anyone wants to play with it I can point you at the general direction... The beginning is simple -- just do a custom search engine and play with it. You can use the "advanced" tab with the following two XML bits which specify my search engine -- the first is the "context" and the second is the "annotations". (Note that both contain labels that are specific to my search, so they'll probably need to be edited to work with a new engine.) --- Racket Documentation Search the most recently released Racket documentation pair --- --- --- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Tweaked doc pages
I have the minimal things that I wanted in a working state now: * Links to the PDF versions next to the version. * A selection box for different versions of documents. * A google custom search. All of this is now visible on newdocs.racket-lang.org, but the older versions go to the right place on docs.racket-lang.org so you'll get to the current version of the pages. Unless there are some objections to all of this, I'll make it go on docs soon. About the google search: I'm not too happy about it -- they have better layouts for the search which I couldn't get to work properly, but this sucked enough time that I decided to just hack things to some acceptable state and leave it at that. If anyone is interested in improving it, I can tell you how to play with it. (More higher level comments in a separate followup that I'll post in a few minutes.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
On Mar 6, 2013, at 8:23 AM, Marijn wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dear Mikel, > > On 06-03-13 04:05, mikel evins wrote: >> >> On Mar 5, 2013, at 12:56 PM, Eli Barzilay >> wrote: >>> But looking at it more deeply I certainly lose something -- I >>> lose the ability to use source code for development, >> >> Come again? How does that happen? It has certainly never happened >> to me. >> >>> which could be a real problem for me if I'm working on some code >>> with someone remote and all we have to communicate are binary >>> images. >> >> Well, sure, if I were suddenly somehow denied access to sources >> and made to communicate with colleagues only through binary images, >> that would be a bad thing, but I'm not losing any sleep over the >> possibility. Matter of fact, it never occurred to me before this >> moment that it could ever be a possibility. > > So how exactly does source code enter into this way of working where > you type code at the REPL and save and load images? Is there a > function that translates images to source code? Otherwise, how do you > prevent losing your code? From source it is easy to get to an image, > right? So what advantage is there to using images over source code for > saving, loading and exchange? Or is what you're describing also > possible using source code instead of images and then looks something > like the ideas of Bret Victor (http://worrydream.com)? Rather than answer your questions directly, it seems much easier and more apropos to address the underlying assumption that images and source files are somehow mutually exclusive. They're not. Adding the ability to save and load images does not subtract the ability to work with source files. I don't know why people seem to think that. Maybe it's because the Smalltalk guys sort of absorbed the filesystem into their images. The fact that it's *possible* to do that doesn't in any way imply that it's *necessary*. I worked with image-based systems daily for years and the effect on my source files was nothing at all, except that maybe having images made it easier to write more working sources faster. Even if you do choose to subsume the filesystem into the image the way the Smalltalk guys did, that still doesn't interfere with your ability to work with source files. Smalltalk guys still build their VMs from plain, ordinary source files. They still have fileIn and fileOut for working with source files from within their images. But, more to the point, there's no reason to subsume the filesystem into the image unless that's what you want to do. If you aren't interested in images, or don't like them, don't use them. I'm not here to convert anybody. I just wanted a sense of how hard it would be to satisfy some project requirements. I mentioned in passing that I think the gradual disappearance of image-based systems is a significant cultural loss, and I still think that. C'est la vie. Matthew and Matthias seem to be saying they think platform-independent images are probably doable; that's good enough for me, for now. If it turns out they're wrong, well, I can work around that. There are other options. It'll grow back. --me _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Trends in Functional Programming 2013: 3rd Call for Papers
CALL FOR PAPERS 14th International Symposium Trends in Functional Programming 2013 Brigham Young University, Utah, U.S.A. May 14-16, 2013 http://faculty.cs.byu.edu/~jay/conferences/2013-tfp/ 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 (see below), described in draft papers submitted prior to the symposium. A formal post-symposium refereeing process then selects a subset of the articles presented at the symposium and submitted for formal publication. Selected papers will be published as a Springer Lecture Notes in Computer Science (LNCS: http://www.springer.com/lncs) volume. TFP 2013 will be the main event of a pair of functional programming events at Brigham Young University. First will be the International Workshop on Trends in Functional Programming in Education and then TFP. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in Edinburgh (Scotland) in 2003, in Munich (Germany) in 2004, in Tallinn (Estonia) in 2005, in Nottingham (UK) in 2006, in New York (USA) in 2007, in Nijmegen (The Netherlands) in 2008, in Komarno (Slovakia) in 2009, in Oklahoma (USA) in 2010, in Madrid (Spain) in 2011, and in St. Andrews (UK) in 2012. For further general information about TFP please see the TFP homepage at http://www.tifp.org/. SCOPE OF THE SYMPOSIUM The symposium recognises that new trends may arise through various routes. As part of the symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles:leading-edge, previously unpublished research work Position Articles:on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles:summarising work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Articles on the following subject areas are particularly welcome: . Functional programming and multicore/manycore computing . Functional programming in the cloud . Functional programming in education . High performance functional computing . Extra-functional (behavioural) properties of functional programs . Dependently typed functional programming . Validation and verification of functional programs . Using functional techniques to verify/reason about imperative/object-oriented programs . Debugging for functional languages . Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. . Interoperability with imperative programming languages . Novel memory management techniques . Program transformation techniques . Empirical performance studies . Abstract/virtual machines and compilers for functional languages . New implementation strategies . Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2013 program chair, Jay McCarthy, at tfp2013 at easychair.org BEST STUDENT PAPER AWARD TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of papers for presentation at the symposium is based on a lightweight screening process of extended abstracts (2 to 10 pages in length) or full papers (max 16 pages). Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings. Latex style files are available from Springer's web page (llncs2e.zip), and are linked below. The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It sho
Re: [racket-dev] using Racket to build an image-based Lisp: feasible?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Mikel, On 06-03-13 04:05, mikel evins wrote: > > On Mar 5, 2013, at 12:56 PM, Eli Barzilay > wrote: >> But looking at it more deeply I certainly lose something -- I >> lose the ability to use source code for development, > > Come again? How does that happen? It has certainly never happened > to me. > >> which could be a real problem for me if I'm working on some code >> with someone remote and all we have to communicate are binary >> images. > > Well, sure, if I were suddenly somehow denied access to sources > and made to communicate with colleagues only through binary images, > that would be a bad thing, but I'm not losing any sleep over the > possibility. Matter of fact, it never occurred to me before this > moment that it could ever be a possibility. So how exactly does source code enter into this way of working where you type code at the REPL and save and load images? Is there a function that translates images to source code? Otherwise, how do you prevent losing your code? From source it is easy to get to an image, right? So what advantage is there to using images over source code for saving, loading and exchange? Or is what you're describing also possible using source code instead of images and then looks something like the ideas of Bret Victor (http://worrydream.com)? Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE3UXgACgkQp/VmCx0OL2wnVQCgl5T/GUJsfkZLiRH6unP/XJgN JrUAninFo55ZtxvE2iIVgmHc/Mz2RHWo =OMuL -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Fwd: [plt] Push #26418: master branch updated
Thanks!
On Wed, Mar 6, 2013 at 7:56 AM, Matthias Felleisen wrote:
>
> This morning build failed like this:
>
> tools.scrbl:782:65: defproc: expected a result contract, found a string
> in: "\n"
>
> So I added a void? contract for the range.
>
>
> Begin forwarded message:
>
> > From: matth...@racket-lang.org
> > Subject: [plt] Push #26418: master branch updated
> > Date: March 6, 2013 8:55:23 AM EST
> > To: dev@racket-lang.org
> >
> > matthias has updated `master' from e6dc9c28b4 to 74c3c130f0.
> > http://git.racket-lang.org/plt/e6dc9c28b4..74c3c130f0
> >
> > =[ One Commit ]=
> > Directory summary:
> > 100.0% collects/scribblings/tools/
> >
> > ~~
> >
> > 74c3c13 Matthias Felleisen 2013-03-06 08:55
> > :
> > | added a void contract to fix setup
> > :
> > M collects/scribblings/tools/tools.scrbl | 2 +-
> >
> > =[ Overall Diff ]===
> >
> > collects/scribblings/tools/tools.scrbl
> > ~~
> > --- OLD/collects/scribblings/tools/tools.scrbl
> > +++ NEW/collects/scribblings/tools/tools.scrbl
> > @@ -779,7 +779,7 @@ Check Syntax is a part of the DrRacket collection,
> but is implemented via the to
> > @defmethod[(syncheck:add-definition-target [source-obj (not/c #f)]
> > [start
> exact-nonnegative-integer?]
> > [finish
> exact-nonnegative-integer?]
> > -[style-name any/c])]{
> > +[style-name any/c]) void?]{
> >
> > }
> >
>
>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] Fwd: [plt] Push #26418: master branch updated
This morning build failed like this:
tools.scrbl:782:65: defproc: expected a result contract, found a string
in: "\n"
So I added a void? contract for the range.
Begin forwarded message:
> From: matth...@racket-lang.org
> Subject: [plt] Push #26418: master branch updated
> Date: March 6, 2013 8:55:23 AM EST
> To: dev@racket-lang.org
>
> matthias has updated `master' from e6dc9c28b4 to 74c3c130f0.
> http://git.racket-lang.org/plt/e6dc9c28b4..74c3c130f0
>
> =[ One Commit ]=
> Directory summary:
> 100.0% collects/scribblings/tools/
>
> ~~
>
> 74c3c13 Matthias Felleisen 2013-03-06 08:55
> :
> | added a void contract to fix setup
> :
> M collects/scribblings/tools/tools.scrbl | 2 +-
>
> =[ Overall Diff ]===
>
> collects/scribblings/tools/tools.scrbl
> ~~
> --- OLD/collects/scribblings/tools/tools.scrbl
> +++ NEW/collects/scribblings/tools/tools.scrbl
> @@ -779,7 +779,7 @@ Check Syntax is a part of the DrRacket collection, but is
> implemented via the to
> @defmethod[(syncheck:add-definition-target [source-obj (not/c #f)]
> [start exact-nonnegative-integer?]
> [finish
> exact-nonnegative-integer?]
> -[style-name any/c])]{
> +[style-name any/c]) void?]{
>
> }
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
