Re: Re: Questions: Roadmap, Publicity/Groovy, Regexps

>>   (x,y) = "123-4567" ~ /\(.*\)-\(.*\)/
>>
>> That is, the compiler sees in the regexp that there are two groups, 
>> and so the matching expression returns a couple.
> 
> 
> I must admit I don't quite get that. How does having builtin regular 
> expressions help there? I'm assuming that the ~ operator on string 
> returns two results, and the language supports ignoring the second 
> result, or is that some kind of funky overloading based on return types?

The compiler could analyse the regexp \(.*\)-\(.*\) and see that there are two 
\(...\) groups, which makes the expression return two results. That's why 
compiler support would be needed.

> Hmm, ok, so you overload the Regexp.new to be a cache lookup, so the 
> string is an inlined constant right, so the cost is just the hash table 
> lookup + the first time regexp creation, seems pretty efficient, and it 
> is transparent to the programmer, they just call Regexp.new. Since you 
> return an immutable object there's no problem with the client modifying 
> the returned object.

Great, that's easy ;-)

It should not be hard to create such method on top of an existing Java regexp 
library. Do you want to give it a try?

> I appologise for the repeated use of Ruby syntax and idioms, it is a 
> while since I tried using Nice and I forgot the syntax --- particularly 
> for constructors. Are there named constructors like in Nice like in Eiffel?

new Regexp("...")

Although you could also create a toplevel method, which means you could use 
the lighter syntax:

regexp("...")

> Oh an while I'm asking questions (and being tempted to try out nice 
> again), Does Nice have closures/blocks/lambda expression so you can do 
> the proverbial:
> 
> File.open("words", "r") { |file| do_something_with(file); }
> 
> which opens and closes the file. It closes the file even if an exception 
> is raised which is pretty handy because it avoids loosing file handles 
> (at least loosing them until the garbage collector comes along).

Yes, Nice does have closures, so you could write the open method in Nice. The 
syntax is   File f => do_something_with(file)

Other features that could come handy are expression-local variables (defining 
a binding inside an expression) and block syntax for no-arg closures (both 
introduced in nice 0.9.6). With those, you can write a small library that 
would let you do:

   using(let f = open("words")) {
     ....
   }

Bryn also has a nice.io package under development, which should bring some 
pretty neat features.

>> In a compiled language, you can actually consider generating the 
>> matcher at compile time (provided the regexp is known), if you have 
>> language support. The question is, is there a strong demand for regexp 
>> support in Nice? Otherwise, what I can see as a more generic 
>> enhancement, in the future, is support for macros/templates/staged 
>> compilation, which would be a way to make it possible to implement 
>> such features, and others, without hard-wiring them in the compiler. I 
>> know Bryn Keller has given some thought to this, maybe he will comment.
> 
> 
> That's a cool feature of Nice I had forgotten about, that macro 
> subsystem. I guess though that from a user perspective the distinction 
> between standard macro extensions (i.e. macro extensions that have kind 
> of become standard because everyone is using them) and the compiler is 
> blured because many programmers would shy away from writing their own 
> macro extensions in a effort to write code according to the standardised 
> idioms of the language.

You missed the "in the future" part. The kind of "macros" that is present at 
the moment is more limited (it's used to implement core operators like ==, +, 
... that generate bytecode directly, without a method call overhead), and 
indeed it's not really target at end users (but I can explain the system if 
somebody needs it).

Even with a polished macro system, I agree not every programmer will want to 
use it extensively, but some library writers definitely would. This also means 
that you can implement more things in separate packages, with obvious benefits 
in terms of choice, independant development and not confusing those who don't 
need the feature at all.

Daniel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click