[Chicken-users] [TFP'15] final call for papers - deadline extended march 31 -
- L A S TA L L F O R P A P E R S - TFP 2015 === 16th Symposium on Trends in Functional Programming June 3-5, 2015 Inria Sophia Antipolis, France http://tfp2015.inria.fr/ 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). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. The selected revised papers will be published as a Springer Lecture Notes in Computer Science (www.springer.com/lncs) volume. TFP 2015 will be the main event of a pair of functional programming events. TFP 2015 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 2nd. 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; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * and in Soesterberg (The Netherlands) in 2014. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/). == INVITED SPEAKERS == TFP is pleased to announce talks by the following two invited speakers: * Laurence Rideau is a researcher at INRIA and is interested in the semantics of programming languages , the formal methods, and the verification tools for programs and mathematical proofs. She participated in the beginnings of the Compcert project (certified compiler), and is part of the Component Mathematical team in the MSR-INRIA joint laboratory, who performed the formalization of the Feit-Thompson theorem successfully. Thirty years ago, computers barged in mathematics with the famous proof of the Four Color Theorem. Initially limited to simple calculation, their role is now expanding to the reasoning whose complexity is beyond the capabilities of most humans, as the proof of the classification of finite simple groups. We present our large collaborative adventure around the formalization of the Feit-Thompson theorem (http://en.wikipedia.org/wiki/Feit%E2%80%93Thompson_theorem) that is a first step to the classification of finite groups and that uses a palette of methods and techniques that range from formal logic to software (and mathematics) engineering. * Anil Madhavapeddy == SCOPE == The symposium recognizes 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: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling 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 analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for
Re: [Chicken-users] Cryptic SSAX error message
Hi, Peter-- On Tue, Mar 17, 2015 at 2:13 AM, Peter Bex airh...@users.sourceforge.net wrote: On Mon, Mar 16, 2015 at 09:27:36PM -0600, Matt Gushee wrote: I was building a new blog with Coq au vin, which uses Civet to process templates, which in turn uses SSAX ... and one of my XHTML templates caused [an] error. [error elided] Now that's a helpful error message. It turns out the problem was the inline JavaScript in my template (which contained the = operator). Since I was using the XHTML Transitional doctype, that's allowed per W3C specs, and it simply hadn't occurred to me that it was likely to result in non-well-formed XML. You shouldn't parse HTML with an XML parser. Not in general, no. But wouldn't you agree that, regardless of what is wrong with the input file and why it is wrong, it would be good if SSAX output something that would actually be useful in troubleshooting? That was my main point. And of course, as I mentioned, I'm well aware that desirable != doable, but I didn't (and don't) know if this is a known issue, so I thought I should say something. Since you're using CHICKEN, you could try the html-parser CHICKEN egg, which is more permissive. But that's not the goal. Perhaps you recall this discussion from 2 years ago? [Matt] Finally, an idea has occurred to me. What about a templating system where what actually gets used at runtime is SXML, but designers could create templates in XHTML, then when they are satisfied with the design, use a preprocessing tool to convert them to SXML? That would at least ensure well-formed markup. [Peter] Yep, that would be good. Representation and surface syntax don't neccessarily need to be equivalent, though the Lisper in me disagrees about that being a good idea :) REF: http://lists.nongnu.org/archive/html/chicken-users/2013-03/msg00058.html So Civet is the templating system I created pursuant to that conversation. The templates are supposed to be well-formed XML (in practice, mainly XHTML), and presumably created by a developer who knows what they're doing - though the current issue may call that into question ;-). I certainly don't believe my approach is ideal from a purely technical standpoint. But given that the meta-goal of my projects is to use Scheme to create web development tools that might be used by people who don't know Scheme (as opposed to use Scheme to develop websites), I think it's about as good a compromise as can be expected. If I were creating Civet today, I think I would look for a different approach - but mainly because it is now clear (maybe it was in 2013 and I just didn't know it) that HTML5 (in non-XML syntax) is becoming dominant, and the never-popular XHTML is dying, if not dead. But I still stand by the fundamental reasoning that led to Civet as it is (and BTW, it works pretty well within its limitations - you should try it ;-) I *think* XHTML Strict is a proper XML application, but I'm not 100% sure, I'm not 100% sure either, but if the W3C says it's XML, they most likely mean it is completely well-formed. One thing I know is that it prohibits inline CSS and JavaScript - and now I understand why. -- Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
