ILC 2014 - International Lisp Conference
"Lisp on the Move"
August 15-17 2014, Université de Montréal, Montréal, Canada
Sponsored by the Association of Lisp Users
In cooperation with: ACM SIGPLAN
h
Alex Shinn scripsit:
> Hmmm... that's upsetting. Python 3 is a notorious dead-end language.
That's a premature judgment (and rather Google-centric). Since Python
3.0 was DOA, the intended five-year transition plan to "Python 3 by
default" ended only a month ago (Python 3.1 was released in June
On Thu, Jul 10, 2014 at 3:51 PM, John Cowan wrote:
> Alex Shinn scripsit:
>
> > The clean way to handle this is to duplicate the useful string
> > APIs for bytevectors. This could be done without code duplication
> > with the use of functors, though compiler assistance may be
> > needed for effi
Yaroslav Tsarko scripsit:
> Why don`t just add *(use utf8)* line explicitly to all the eggs that
> handle strings? That will ultimately fix the problem
> and will clearly indicate that egg performs string manipulations and
> is capable of handling UTF-8 encoding.
That will certainly work, but has
On 09.07.2014 02:15, Oleg Kolosov wrote:
IMO just enable utf8 by default and let them break. Is it's not 80's
anymore, latin1 only software should die.
+ 1.
For specific use cases (backward compatibility, logging or minimizing
runtime size for example) it should be possible to disable multi-b
On 07/03/14 22:49, Shawn Rutledge wrote:
> I found that a couple of days ago; try again with the svn trunk. I
> will have to make a new release soon.
Good to know. I have not tested it yet, because I'm troubleshooting
other obscure Chicken related problem and do not want to change used
components
On Wed, Jul 9, 2014 at 7:00 AM, Alex Shinn wrote:
> However, I don't think that's the real problem. The issue as I
> understand is that although Chicken has both strings and
> bytevectors in the core, historically and for continued simplicity
> strings are abused as bytevectors in many cases. T
On 07/09/14 09:00, Alex Shinn wrote:
> However, I don't think that's the real problem. The issue as I
> understand is that although Chicken has both strings and
> bytevectors in the core, historically and for continued simplicity
> strings are abused as bytevectors in many cases. ...
And this is
On Fri, Jul 11, 2014 at 7:20 AM, Oleg Kolosov wrote:
> On 07/09/14 09:00, Alex Shinn wrote:
> > The clean way to handle this is to duplicate the useful string
> > APIs for bytevectors. This could be done without code duplication
> > with the use of functors, though compiler assistance may be
> >
On Fri, Jul 11, 2014 at 6:53 AM, Michele La Monaca <
mikele.chic...@lamonaca.net> wrote:
>
> Wouldn't be simpler and more effective this other path?
>
> 1) keep current string functions as they are (i.e. byte-oriented) and
> keep "abusers" abusing (and happy)
> 2) provide new utf8/cursor-oriented
10 matches
Mail list logo
