Most of you are probably also on the icon-group mailing list and have enjoyed the recent exchange about adding features to Icon. In this message I comment on Frank's feature requests other than OOP, which Unicon has.
I disagree with [EMAIL PROTECTED]'s suggestion that adding new capabilities to Icon automatically implies lowering it to the level of other languages. Icon's history is a long one in which many new capabilities were added, often in a way that is nicer than facilities found in other languages. There are good reasons not to add anything, but ernobe's comment amounts to "let's not make bad additions just for the sake of making additions". I agree with that position. Now for some specifics: A better loadfunc() is an excellent idea. A dedicated volunteer in our user community has been working vigorously on improving loadfunc(), and I will let him speak for himself if he wishes. His work appears to complement this request. But let's consider Frank's suggestion further: he wants to be able to generate the "stub" function that interfaces to C directly in Icon. Writing the C stub functions has proven a deterrent for most users. I see no reason why Frank's idea can't be done, it just needs some clever design and then a volunteer to do the implementation. In addition to constructing the "procedure block", this new stub function generator would need to associate C type information for parameters, possibly through a hungarian naming convention or other insidious means in the procedure block. The relationship between existing loadfunc() and this proposed extension needs to be thought out. If anyone builds this, I would love to add it to Unicon. Unicode support will take more work. I have pretty nearly concluded it should be done in addition (and in parallel) to the regular string type, analogous to large integers in parallel with regular integers. It needs also a "large cset" type in parallel with the cset type. The cset type needs to be sparse, requiring more complexity than for regular csets. All the string functions would have to be modified to handle Unicode types, similar to how arithmetic handles large integers. A moderate amount of work would be required to implement, e.g. string scanning functions for Unicode. Most platforms still lack Unicode I/O facilities, and some ability to "see" Unicode on-screen and input Unicode from the keyboard would have to be found in a free portable C library somewhere, or developed from scratch. To sum up: it is a big job. It will take funding or a saint somewhere to make it happen anytime soon. The whole project could be prototyped in Unicon, and that might be a tractable start a volunteer could do. I would love to see Unicode in Unicon. Scripting. Ability to execute sources without a visible compile step can't be that hard; we can just compile and link to memory (or a temp file) upon invocation of the virtual machine if it is given source code instead of VM code. This is the easiest of Frank's requests to implement. It has been on the Unicon wish list for over a year. :-) Now for a twist. I have added a new section "Unicon Project Feature Funds" to the Jeffery Books web page at http://www.zianet.com/jeffery/books/. In addition to providing one-stop shopping for Icon and Unicon books and consulting services, we will maintain accounts and coordinate work on user-requested features. And members of the community can do the work and be paid for it to the extent they are able to marshall community interest and support for the feature. Of course, I expect glory, honor, and the added value of the language to continue to be the primary forms of payment I and the rest of the volunteers receive for the forseeable future. One thing I don't want these funds to do is slow the pace of free volunteer work; if a volunteer needs a feature they go ahead and do it, without waiting for some community fund to work its way up to some hostage funding level. But for things that can't be done on that basis, the Unicon Project Feature Funds may be a useful alternative. Please give me your feedback on whether you think this is a good idea, and whether you think I need to change how I am proposing we go about it. Cheers, Clint [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
