On 8 Sep 2009, at 9:34 pm, John Cowan wrote: > Alaric Snell-Pym scripsit: > >> Some people say "things should be in the standard because it's >> expensive to implement them in a portable manner", an argument I saw >> in the threaded started by an email from John Cowan arguing for >> including case-lambda and parameters and other such things. > > I *deeply* regret ever having said anything of the sort. It was > ONLY to explain why I wasn't including such things as SRFI-1, > despite it being useful, well-implemented, and well-supported. > (I think it's even single-source; has anyone ever built a > fresh implementation of SRFI-1 from scratch?)
Fear not, somebody had to say it; it's a position we need to consider, if even to find it's unfounded. > I quite agree. However, sockets or (tiptoeing around the elephant > in the room) graphics and GUIs *gasp*! He said the G-words! > are not the kind of thing that will > have slow portable implementations. Yeah. Sockets is probably standardisable. GUIs less so... all cross- platform GUI toolkits lack a certain something (and aren't portable to non-GUI environments), while platform-specific GUI toolkits aren't portable at all. However, perhaps something inspired by CLIM can become widespread, either with pluggable back-ends or using some standardised basic-windowing API... >> I can see their point - languages like Java, Python and Ruby tend to >> have this property > > Because they are single-sourced. Java has multiple VM > implementations, > but the class library implementations are tending to converge rather > than diverge -- compatibility with Sun's is what matters, and since > Sun's are now open-source, implementers tend to use them. Yep. This is an advantage to people picking the language up, though (less variables). It's a disadvantage in subtler ways. We like our strength of having multiple implementations, so we need to find a way to pay for it by working on the disadvantages :-) >> they'll lack sockets and so on, but only until somebody >> hooks up an FFI... > > Hmm, yes. Anyone for writing a SRFI standardizing a C FFI? That > was tried, as I recall.... It'd be possible to write a very minimal one, in the vein of dlopen +libffi (even very embedded environments can provide dlopen, by having a compiled-in hardcoded table of libraries and identifiers, and just looking pointers up in them). This wouldn't be as powerful as what implementations such as Chicken can do with inline embedded C, parsing C header files to find out the function prototypes, and so on, but it'd be fairly easily implemented even by interpreters. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
