On May 11, 4:55 pm, rump...@web.de wrote: > On 10 Mai, 10:40, Paul Rubin <http://phr...@nospam.invalid> wrote:> Andreas > Rumpf <rump...@web.de> writes: > > > I invented a new programming language called "Nimrod" that combines > > > Python's readability with C's performance. Please check it out: > > >http://force7.de/nimrod/Anyfeedback is appreciated. > > > Looks nice in many ways. You also know about PyPy and Felix > > (felix.sf.net)? > > Nimrod has very different goals from PyPy, I cannot comment on Felix. > > > It seems a little bit hackish that the character type is a byte. > > Python did something like that but it ended up causing a lot of > > hassles when dealing with real Unicode. I think you have to bite > > the bullet and have separate byte and char types, where char=unicode. > > I am dissatisfied with Python's (or Java's) Unicode handling: > 1) IO overhead to convert UTF-8 (defacto standard on UNIX) into > UTF-16. > 2) For simple tasks the output file will be in the same encoding as > the input file automatically. > 3) Most text files have no header specifying the encoding anyway. How > should the programm/programmer know? And often he does not need to > know anyway. > 4) UTF-16 (or 32) use more memory. > 5) In particular using UTF-16 internally does not make sense: It just > encourages programmers to ignore surrogates. Unicode has more than > 2^16 characters nowadays. > > > It scares me a little about how there are references that can have > > naked pointers, escape the gc, etc. It would be good if the type > > system were powerful enough to guarantee the absence of these effects > > in some piece of data, unless the data is somehow marked with an > > "unsafe" type. > > Well "ptr" is unsafe, "ref" is not; mixing the two requires a "cast". > Basically "cast" is the only unsafe feature. > > > I'd like to see ML-like algebraic types with pattern matching, not > > just tuple unpacking. > > Me too. > > > The generic system should be able to analyze the AST of type > > parameters, e.g. iterator<T> would be able to automatically generate > > an iterator over a list, a tree, or some other type of structure, by > > actually figuring out at compile time how T is constructed. > > Interesting idea. Right now the generic iterator is named "items" and > can be overloaded for user-defined types. > > > It's sort of surprising that the compiler is written in a Pascal > > subset. Why not implement in Nimrod directly, and bootstrap through C? > > That is already the case: The Pascal version is translated to Nimrod > and than compiles itself. Bootstrapping works. > > > The language and library are missing arbitrary precision integer > > arithmetic, using GMP or something like that. > > True, but currently not a high priority for me.
Too bad. That makes Nimrod officially "worthless", i.e., of no value to me. > > > It would be good to also be able to have value serialization and > > deserialization to both human readable (nested lists, etc) and binary > > (for IPC) formats. > > Yes. Planned for version 0.9.0. > > > It's not obvious from the blurbs whether simple functional programming > > is supported, e.g. how would you implement a function like "map" or > > "filter"? What would the types be of those two functions? > > proc map[T, S](data: openarray[T], op: proc(x: T): S): seq[S] = > result = @[] > for d in items(data): result.add(op(d)) > > Or - if you don't want the "openarray[T]" restriction: > proc map[T, S, U](data: T, op: proc(x: U): S): seq[S] = > result = @[] > for d in items(data): result.add(op(d)) > > > The roadmap says you might implement threading with transactional > > memory. How will the transactional memory interact with mutable data? > > Are you going to use OS threads, lightweight threads, or both? > > Probably both. Lightweight threads could be done using coroutines and > explicit task switching. OS threads with transactional memory. The > plan is to use LLVM as a backend and perhapshttp://tinystm.org/. Of > course, this is only wishful thinking. ;-) -- http://mail.python.org/mailman/listinfo/python-list
