Ralf Laemmel and Erik Meijer take a head-on jump into xml object mismatch. More (or less) data binding.
I still haven't gotten to look microformats and wonder if I need to.
This Scala XML documentation needs some updating.
Some time ago, Kathleen Dollard showed how to generate classes from an XML Schema using XSLT. I dislike both schema and XSLT, but I would understand why someone would need to use both technologies and have respect for everybody that plunges in that hell. However all those technologies together might serve to describe the problem rather than the solution
This pull parsing stuff ultimately looks better than all other APIs, because all the other ones can be implemented on top of this one.
What would types be good for? There's all those "message-not-understood" (and so on), but there is also fancier stuff like Session types for channels, or regexp-like types for semistructured data.
Castagna provides an account on overloading in the publication that came out of his thesis, titled
"Object-Oriented Programming: A Unified Foundation". The thing with overloading is that it might give a more precise type to pattern matching statements, an idea that haunts me since ages.
One of the typing experts sitting int the committee, Cormac Flanagan, has worked on SAGE: Practical Hybrid type checking for Expressive Types and Specifications[pdf]
John C. Mitchell. Foundations for Programming Languages. ISBN 0-262-13321-0The style and notation of this book are of a beauty that makes me want to read it over and over again. Although I don't really have spare cycles to do more foundational stuff, the proofs are spelled out in a very clear, yet concise manner and it is inspiring.
Benjamin Pierce, ed. Advanced Topics in Types and Programming Languages. ISBN 0-262-16228-8 Here, I started with the chapter of typed assembly language, also with an implementation actually. Wouldn't it be useful to have a low-level VM for iron that interprets typed assembly code? and have an x86 backend at some point.
When chatting with my chap about my final project, I was surprised how rational I could tell him the objectives and problems that I am facing, things I have been trying to find out for a long time. And there I am just communicating it as if I had known it all the time. My reluctance to use *the language*, the advantages of using HTML for user interfaces, the insights into GWT and the architectural sketch and constraints of the system.
When receiving another chap's email I'm surprised at his argument for dynamic typing having become more differentiated, preferring LISP over Python. And it somehow makes sense, because uniform containers (like sequences and hashtables) seems to be what most of my obsession with iron is about as well. His CLOS speak is beyond me but I recall from the book that I forgot to mention that setting up some object system in those languages is not very difficult.
Abelson and Sussman. Structure and Interpretation of Computer Programs. ISBN 0-262-51087-1 Never made it to those later chapters, where writing a scheme compiler is given as an exercise. Opening this book again is due to my interest in doing dynamic typing via tags. However it just clashes with the idea of doing static checking for regular expression types. What gives? There should be some program analysis and type inference.
Benjamin Pierce. Types and Programming Languages. ISBN 0-262-16209-1 There's something about recursive types that makes me return to this book. It stems from my obsession of regular expression types for sequences. The iron language is supposed to have sequences as primitives, and do some type-checking for an xsd-extension based object-class system. Also, the type inference idea mentioned above can be nourished from this book.
<%@ taglib uri="/WEB-INF/tld/struts-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/tld/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/tld/struts-logic.tld" prefix="logic" %>
<html:form action="/loginlogout/login" focus="username">
<TABLE WIDTH="<bean:message key="block.size.x"/>"
No, no, some other I may have done this to you myself a long time ago, but not again.
Joel is right, so facade elements with attributes and ognl and tapestry style it shall be.
editable, viewable, maybe even validatable and bindable. No use to go over the top with WebObjects.
OTOH, one can get a nice language, XML capabilities and leverage the whole Java shebang using the Scala language. However, the whole backend-multiplexing thing is missing as of yet.
Once again scanning the web for frameworks, I got lost in Apache MyFaces and Tapestry and of course Google Web Toolkit the new kid on the block.
- ▼ July (3)