nice-info — Discussions about Nice

Re: [Nice-info] How do I contribute?

[Daniel B. <bo...@us...>]

Hi,

On Thu, Jan 5, 2012 at 2:33 PM, Chadwick K. Boggs
<cha...@gm...> wrote:
> Do I just E-mail in my code changes for the Nice programming language?

If you have patches, please submit them on the website:
https://sourceforge.net/tracker/?group_id=12788&atid=312788 and I will
review them.

The language has been stagnant for several years, especially since I
finished my PhD. Recently this is the second time I'm hearing new
interest around Nice. I received from another contact a quite detailed
document with guiding principles, which looks interesting, though I
still need to analyze it more in details. (I don't copy it now since
it was sent to me personally, but I can check with the author if he
wants to make it more public).

I am now an independent developer and project leader. I have quite a
lot of work, but I am also flexible in my schedule. So if a small
community forms, either to revive Nice or to start a new project
inspired in part by it, I would be happy to be part of that. Let's see
if more people are interested, and what ideas/directions they have.
Things could grow organically from there.

Further thoughts welcome.

Daniel

[Nice-info] How do I contribute?

[Chadwick K. B. <cha...@gm...>]

Do I just E-mail in my code changes for the Nice programming language?

[Nice-info] [ nice-Feature Requests-671444 ] Enhanced Null testing with class or instance variables

[SourceForge.net <no...@so...>]

Feature Requests item #671444, was opened at 2003-01-20 22:52
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362788&aid=671444&group_id=12788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Bryn Keller (xoltar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced Null testing with class or instance variables

Initial Comment:
Background:

Nice currently allows local variables which are of
option types to be tested using simple "if" statements:

?String foo = null;
// ...
if (foo != null) {
   //Here foo is of type String, not ?String.
}

Within the body of a (foo != null) block, foo is
considered to be a String, not a ?String, since it is
known not to be null. 

Feature:

A useful feature would be to extend this behavior to
class and instance variables:

class Foo {
    ?String bar;

    String baz() = bar != null ? bar : "default";
}

However this is not possible due to the fact that bar
may be modified by another thread (set to null) between
the time of the test and the time bar is used where a
(non-null) String is expected.

It would be possible to do this when the variable is
final. For example (thanks to Daniel for the example):

class Name
{
 // Everybody has first and last names.
  final String first;
  final String last;

 // Not everybody has a middle name.
  final ?String middle;

 toString() {
   if (middle != null)
     ...
 }
} 

It might also be safe to do this in the event that a
variable is only ever accessed via methods or code
which is synchronized on the given object...






----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-04-13 22:55

Message:
QJo9wv 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-02-10 23:55

Message:
Logged In: NO 

I should have added that I don't understand this restriction
as any guard can be defeated. If synchronization is poor all
guarantees are void.
e.g. if (x >= 3) {
           // Someone changes x here to 2 in another thread.
           A[x -3] = "abc"; // Whoops();
       }
So why is this a reason not to implement null testing for
class members?




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-01-29 20:05

Message:
Logged In: NO 

Forgive my ignorance, but why is the operation of another
thread an issue here. Surely typing (nullness) is checked at
compile time not at run time?  If it happens at run time
Java already has a perfectly valid mechanism - the program
crashes.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362788&aid=671444&group_id=12788

[Nice-info] Nice analyzed in "Multiple Dispatch in Practice"

[Isaac G. <ig...@ya...>]

"Multiple Dispatch in Practice" 

http://homepages.mcs.vuw.ac.nz/~muscheradu/publications/MuscheviciPotaninTemperoNobleMMSubmitted.pdf


      

Re: [Nice-info] Bjarne Stroustrup: Is multiple dispatch a good thing? - Yes.

[Isaac G. <ig...@ya...>]

--- a4...@gm... wrote:

> On Wed, 16 Apr 2008, Isaac Gouy wrote:
> > "Languages that support multiple dispatch at run time (like Dylan
> > and CLOS) do better and languages (such as C++) that support it at
> > compile time can sometimes help a bit."
> >
> > http://msdn2.microsoft.com/en-us/magazine/cc500572.aspx
> >
> >
> > "Open Multi-Methods for C++"
> >
> > http://research.att.com/~bs/multimethods.pdf
> 
> "That work came too late for C++0x, though."
> 
> So we will have to wait another 5 years until C++ supports multiple 
> dispatch. :-)


When Bjarne Stroustrup says multiple dispatch is a good thing, it
creates another window of opportunity for multiple dispatch languages.


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Nice-info] Bjarne Stroustrup: Is multiple dispatch a good thing? - Yes.

[<a4...@gm...>]

On Wed, 16 Apr 2008, Isaac Gouy wrote:
> "Languages that support multiple dispatch at run time (like Dylan
> and CLOS) do better and languages (such as C++) that support it at
> compile time can sometimes help a bit."
>
> http://msdn2.microsoft.com/en-us/magazine/cc500572.aspx
>
>
> "Open Multi-Methods for C++"
>
> http://research.att.com/~bs/multimethods.pdf

"That work came too late for C++0x, though."

So we will have to wait another 5 years until C++ supports multiple 
dispatch. :-)


Radu

[Nice-info] Bjarne Stroustrup: Is multiple dispatch a good thing? - Yes.

[Isaac G. <ig...@ya...>]

"Languages that support multiple dispatch at run time (like Dylan and
CLOS) do better and languages (such as C++) that support it at compile
time can sometimes help a bit."

http://msdn2.microsoft.com/en-us/magazine/cc500572.aspx


"Open Multi-Methods for C++"

http://research.att.com/~bs/multimethods.pdf


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Nice-info] iterator and tuple with forIterator

[Dan S. <dan...@gm...>]

As an experiment to become more familiar with nice, I decided to try
to build a new forIterator method for maps that allows you to iterate
over a tuple of key values.  The forIterator looks like the following,
and works fine:

<K,V> Iterator<(K,V)> forIterator(Map<K,V> map){
	let entries = map.entrySet().iterator();
	return (() => {
		if(entries.hasNext()){
			let entry = entries.next();
			return (entry.getKey(),entry.getValue());
		}
		return stop();
	}).iterator();
}

However to use the forIterator, I had to place a temporary variable as
the item in the for statement, then pull the values out inside the
loop.
void main(String[] args){

	Map<String,String> mapdata = listToMap([
					("test1","Bla1"),
					("test2","Bla2")
					]);

	//This works
	for(entry :mapdata){
		(String key, String value) = entry;
		println("Map Iteration Test:" key "=" value);
	}

	//Doesn't compile
	for((String key, String value):mapdata)
		println("Map Iteration Test:" key "=" value);

}

Is this a bug, or is there another way to express this without the
temp variable?

Thanks

Dan

BTW: I haven't been able to get buy in to start using nice, but it is
indeed a very nice language to play with

[Nice-info] Nice syntax highligthing for SciTE

[Yauheni A. <ea...@in...>]

	Hi!

Subj is here: http://files.rsdn.ru/46291/N4S.zip
Written by Klapaucius (http://www.rsdn.ru/Users/46291.aspx)

-- 
Regards,
Yauheni Akhotnikau
Senior Programmer
Intervale
e-mail:ea...@in... <mailto:ea...@in...>

Re: [Nice-info] Nice multiple dispatch details

[<a4...@gm...>]

Thanks Daniel, that makes it a lot clearer!

Now, in terms of dynamic (multiple or single) dispatch:
The concept is that at compile time there is a known set of 
alternative method bodies for each call site. At runtime, the most 
appropriate body is chosen from this set, depending on the dynamic 
types of the arguments involved in the call. In some languages, this 
set is called a generic function. In Nice, it is a method 
declaration that has a set of alternative method 
implementations/bodies.

In some languages (at least CLOS, Dylan, Cecil), a method body 
belongs to one generic function. In Nice it can belong to one or 
multiple declarations. 

I hope I got that right, correct me if I'm wrong please ;-)

cheers,
Radu


On Wed, 20 Feb 2008, Daniel Bonniot wrote:
> For clarification: there are two concepts:
>
> 1) method declaration, for instance:
> <T> String toString(!T);
> and
> String toString(Vehicle);
>
> It has a return type, possible a contract, no code.
>
> 2) method implementation (or "method body" or "alternative"), for
> instance toString(Car a) = "...";
>
> It has no return type nor contract, but some code.
>
> A method implementation belongs to one (or several, see below)
> method declaration, for which it represents the code to execute in
> a certain context.
>
> A method declaration m2 can override another method declaration
> m1. This happens when m2 is more specific than m1. It can in
> particular have a more specific return type. In this case, all
> implementations of m2 will also be implementations of m1.
>
> On Feb 19, 2008 11:29 PM,  <a4...@gm...> wrote:
> > There's one thing that I am a bit confused about.
> >
> > The code:
> >         String toString(Vehicle a) = "a vehicle";
> >         toString(Car a) = "a car";
> >
> > gives me this warning:
> >
> > ~/ca/corpus/nice/test1/main.nice: line 23, column 8:
> > warning: This method overrides <T> java.lang.String toString(!T)
> > You should make this explicit, either by omitting the return
> > type or by using the 'override' keyword.
> >
> > What does 'overrides' mean here? If a method overrides another,
> > does it imply that it is part of the same method (dispatch)
> > group? So, in this case, is toString(test1.Vehicle a) part of
> > toString(!T)? Is toString(Car a) part of toString(!T)?
> >
> > Additionally, the compiler seems to create a new method group
> > toString(test1.Vehicle a) with the two alternatives:
> >         toString(test1.Car a)
> >         toString(test1.Vehicle a)
> >
> > >From this, it appears that a method body can be in multiple
> > > method
> >
> > groups. Is this correct?
> >
> > So for this call site:
> >         toString(new Vehicle());
> >
> > the method group would be:
> >         toString(test1.Car a)
> >         toString(test1.Vehicle a)
> >
> >
> > while for this call site:
> >         toString(new java.lang.Object());
> >
> > the method group would be:
> >         toString(!T)
> >         toString(test1.Car a)
> >         toString(test1.Vehicle a)
> >
> > Is this correct?
>
> Yes, this is correct :-)
>
> Daniel
>
> ------------------------------------------------------------------
>------- This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nice-info mailing list
> Nic...@li...
> https://lists.sourceforge.net/lists/listinfo/nice-info

Re: [Nice-info] Nice multiple dispatch details

[Daniel B. <bo...@gm...>]

For clarification: there are two concepts:

1) method declaration, for instance:
<T> String toString(!T);
and
String toString(Vehicle);

It has a return type, possible a contract, no code.

2) method implementation (or "method body" or "alternative"), for instance
toString(Car a) = "...";

It has no return type nor contract, but some code.

A method implementation belongs to one (or several, see below) method
declaration, for which it represents the code to execute in a certain
context.

A method declaration m2 can override another method declaration m1.
This happens when m2 is more specific than m1. It can in particular
have a more specific return type. In this case, all implementations of
m2 will also be implementations of m1.



On Feb 19, 2008 11:29 PM,  <a4...@gm...> wrote:
> There's one thing that I am a bit confused about.
>
> The code:
>         String toString(Vehicle a) = "a vehicle";
>         toString(Car a) = "a car";
>
> gives me this warning:
>
> ~/ca/corpus/nice/test1/main.nice: line 23, column 8:
> warning: This method overrides <T> java.lang.String toString(!T)
> You should make this explicit, either by omitting the return type
> or by using the 'override' keyword.
>
> What does 'overrides' mean here? If a method overrides another, does
> it imply that it is part of the same method (dispatch) group?
> So, in this case, is toString(test1.Vehicle a) part of toString(!T)?
> Is toString(Car a) part of toString(!T)?
>
> Additionally, the compiler seems to create a new method group
> toString(test1.Vehicle a) with the two alternatives:
>         toString(test1.Car a)
>         toString(test1.Vehicle a)
>
> >From this, it appears that a method body can be in multiple method
> groups. Is this correct?
>
> So for this call site:
>         toString(new Vehicle());
>
> the method group would be:
>         toString(test1.Car a)
>         toString(test1.Vehicle a)
>
>
> while for this call site:
>         toString(new java.lang.Object());
>
> the method group would be:
>         toString(!T)
>         toString(test1.Car a)
>         toString(test1.Vehicle a)
>
> Is this correct?

Yes, this is correct :-)

Daniel

Re: [Nice-info] Nice multiple dispatch details

[<a4...@gm...>]

There's one thing that I am a bit confused about.

The code:
	String toString(Vehicle a) = "a vehicle";
	toString(Car a) = "a car";

gives me this warning:

~/ca/corpus/nice/test1/main.nice: line 23, column 8:
warning: This method overrides <T> java.lang.String toString(!T)
You should make this explicit, either by omitting the return type
or by using the 'override' keyword.

What does 'overrides' mean here? If a method overrides another, does 
it imply that it is part of the same method (dispatch) group?
So, in this case, is toString(test1.Vehicle a) part of toString(!T)? 
Is toString(Car a) part of toString(!T)?

Additionally, the compiler seems to create a new method group 
toString(test1.Vehicle a) with the two alternatives:
        toString(test1.Car a)
        toString(test1.Vehicle a)

From this, it appears that a method body can be in multiple method 
groups. Is this correct?

So for this call site:
	toString(new Vehicle());

the method group would be:
        toString(test1.Car a)
        toString(test1.Vehicle a)


while for this call site:
	toString(new java.lang.Object());

the method group would be:
	toString(!T)
        toString(test1.Car a)
        toString(test1.Vehicle a)

Is this correct?

Thanks :)
Radu


On Mon, 18 Feb 2008, a4...@gm... wrote:
> Thanks Daniel for the clarification,
>
> after playing a little with the nice compiler I realized that the
> programmer is actually in control of which method bodies belong to
> a method group. In this example:
>
> 	class Vehicle;
> 	class Car extends Vehicle;
> 	class Driver;
>
> 	String toString(Vehicle a1) = (...);
> 	String toString(Car a1) = (...);
>
> the two toString() methods are not in the same method group (even
> though they have the same name and number of arguments, and the
> argument types are relate by inheritance) because they have
> different declarations.
>
> In contrast:
> 	String toString(Vehicle a1) = (...);
> 	toString(Car a1) = (...);
>
> are in the same method group.
>
> Conversely,
> 	String toString(Vehicle a1) = (...);
> 	toString(Car a1) = (...);
> 	toString(Driver a1) = (...);
>
> are not all 3 in the same method group (only the first 2).
>
> cheers,
> Radu
>
> On Wed, 13 Feb 2008, Daniel Bonniot wrote:
> > Hi,
> >
> > On Feb 7, 2008 8:09 AM,  <a4...@gm...> wrote:
> > > Hi,
> > >
> > > I have a few questions regarding the multiple dispatch
> > > mechanism in Nice and how it compares to other languages
> > > (CLOS, Dylan, Cecil etc.)
> > >
> > > When calling a method, Nice, like other multiple dispatch
> > > languages, has to chose the most appropriate method body from
> > > a set of available definitions (based on the dynamic type of
> > > the supplied arguments, of course).
> > >
> > > What are the criteria of grouping method definitions into a
> > > "dispatch set":
> > > - the method's name (I assume)
> >
> > yes
> >
> > > - the package where the method is defined?
> >
> > they don't have to be in the same package, as long as all
> > packages are visible by being imported
> >
> > > - the number of arguments?
> >
> > yes
> >
> > > - static types of arguments?
> >
> > yes. Precisely, a method will override all other methods when
> > both would be applicable for some same set of arguments, and the
> > overriding methods has more specific types than the overriden
> > one.
> >
> > > In other words....
> > >
> > > * Example1:
> > >         package Car;
> > >         foo(Car a1, Motorcycle a2)
> > >         package Motorcycle;
> > >         foo(Motorcycle a1, Truck a2)
> > > ...will these methods be the same dispatch set?
> >
> > No, given I assume something cannot be both a motorcycle and a
> > truck.
> >
> > But if there was also a foo(Vehicule, Vehicule), then that one
> > would be overridden by both of yours.
> >
> > > * Example2:
> > >         foo(Car a1, Motorcycle a2)
> > >         foo(Car a1, Motorcycle a2, Truck a3)
> > > ...will these methods be in the same dispatch set?
> >
> > No.
> >
> > > * Example3:
> > >         abstract class Vehicle;
> > >         class Car extends Vehicle;
> > >         abstract class Person;
> > >         class Driver extends Person;
> > >
> > >         toString(Car a1) = (...);
> > >         toString(Driver a1) = (...);
> > >
> > >         void main(String[] args) {
> > >                 let d = new Driver();
> > >                 toString(d);
> > >         }
> > > ... will the 2 methods be in the same dispatch set?
> >
> > Yes.
> >
> > > I.e. when calling
> > > toString() with a Driver as an argument, will both method
> > > definitions be considered at runtime? Or is the compiler able
> > > to disambiguate these two, eliminating the need for dynamic
> > > dispatch (in this particular case)?
> >
> > I believe the compiler will avoid the dynamic dispatch in this
> > particular case, but that's an implementation detail (an
> > optimization).
> >
> > You are welcome to write such programs yourself to check the
> > behaviour of the compiler.
> >
> > Cheers,
> >
> > Daniel
> >
> > ----------------------------------------------------------------
> >-- ------- This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Nice-info mailing list
> > Nic...@li...
> > https://lists.sourceforge.net/lists/listinfo/nice-info
>
> ------------------------------------------------------------------
>------- This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nice-info mailing list
> Nic...@li...
> https://lists.sourceforge.net/lists/listinfo/nice-info

Re: [Nice-info] Nice multiple dispatch details

[<a4...@gm...>]

Thanks Daniel for the clarification,

after playing a little with the nice compiler I realized that the 
programmer is actually in control of which method bodies belong to a 
method group. In this example:

	class Vehicle;
	class Car extends Vehicle;
	class Driver;

	String toString(Vehicle a1) = (...);
	String toString(Car a1) = (...);

the two toString() methods are not in the same method group (even 
though they have the same name and number of arguments, and the 
argument types are relate by inheritance) because they have 
different declarations.

In contrast:
	String toString(Vehicle a1) = (...);
	toString(Car a1) = (...);

are in the same method group.

Conversely,
	String toString(Vehicle a1) = (...);
	toString(Car a1) = (...);
	toString(Driver a1) = (...);

are not all 3 in the same method group (only the first 2).

cheers,
Radu


On Wed, 13 Feb 2008, Daniel Bonniot wrote:
> Hi,
>
> On Feb 7, 2008 8:09 AM,  <a4...@gm...> wrote:
> > Hi,
> >
> > I have a few questions regarding the multiple dispatch mechanism
> > in Nice and how it compares to other languages (CLOS, Dylan,
> > Cecil etc.)
> >
> > When calling a method, Nice, like other multiple dispatch
> > languages, has to chose the most appropriate method body from a
> > set of available definitions (based on the dynamic type of the
> > supplied arguments, of course).
> >
> > What are the criteria of grouping method definitions into a
> > "dispatch set":
> > - the method's name (I assume)
>
> yes
>
> > - the package where the method is defined?
>
> they don't have to be in the same package, as long as all packages
> are visible by being imported
>
> > - the number of arguments?
>
> yes
>
> > - static types of arguments?
>
> yes. Precisely, a method will override all other methods when both
> would be applicable for some same set of arguments, and the
> overriding methods has more specific types than the overriden one.
>
> > In other words....
> >
> > * Example1:
> >         package Car;
> >         foo(Car a1, Motorcycle a2)
> >         package Motorcycle;
> >         foo(Motorcycle a1, Truck a2)
> > ...will these methods be the same dispatch set?
>
> No, given I assume something cannot be both a motorcycle and a
> truck.
>
> But if there was also a foo(Vehicule, Vehicule), then that one
> would be overridden by both of yours.
>
> > * Example2:
> >         foo(Car a1, Motorcycle a2)
> >         foo(Car a1, Motorcycle a2, Truck a3)
> > ...will these methods be in the same dispatch set?
>
> No.
>
> > * Example3:
> >         abstract class Vehicle;
> >         class Car extends Vehicle;
> >         abstract class Person;
> >         class Driver extends Person;
> >
> >         toString(Car a1) = (...);
> >         toString(Driver a1) = (...);
> >
> >         void main(String[] args) {
> >                 let d = new Driver();
> >                 toString(d);
> >         }
> > ... will the 2 methods be in the same dispatch set?
>
> Yes.
>
> > I.e. when calling
> > toString() with a Driver as an argument, will both method
> > definitions be considered at runtime? Or is the compiler able to
> > disambiguate these two, eliminating the need for dynamic
> > dispatch (in this particular case)?
>
> I believe the compiler will avoid the dynamic dispatch in this
> particular case, but that's an implementation detail (an
> optimization).
>
> You are welcome to write such programs yourself to check the
> behaviour of the compiler.
>
> Cheers,
>
> Daniel
>
> ------------------------------------------------------------------
>------- This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nice-info mailing list
> Nic...@li...
> https://lists.sourceforge.net/lists/listinfo/nice-info

Re: [Nice-info] Overriding == for strings

[Dan S. <dan...@gm...>]

Very cool, thanks.

On Fri, Feb 15, 2008 at 2:39 PM, Daniel Bonniot <bo...@gm...> wrote:
>
> On Fri, Feb 15, 2008 at 8:52 PM, Dan Shryock <dan...@gm...> wrote:
>  > As a simple test, I am trying to override the == operator for string
>  >  comparison.  The problem that I am running into is that I see no way
>  >  to do a reference test once you override the method.  In some
>  >  languages I have seen an === operator that always does a strict
>  >  reference test.  Is there any way to do something similar in nice?
>
>  You can simply give a new name to the == operation:
>
>  override boolean `==`(String s1, String s2) = s1.equals(s2);
>
>  boolean same(Object o1, Object o2) = o1 == o2;
>
>  void main(String[] args) {
>   let s1 = "a", s2 = "ba".substring(1);
>   println(s1 == s2); // true
>   println(same(s1, s2)); // false
>  }
>
>  Daniel
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  _______________________________________________
>  Nice-info mailing list
>  Nic...@li...
>  https://lists.sourceforge.net/lists/listinfo/nice-info
>

Re: [Nice-info] Overriding == for strings

[Daniel B. <bo...@gm...>]

On Fri, Feb 15, 2008 at 8:52 PM, Dan Shryock <dan...@gm...> wrote:
> As a simple test, I am trying to override the == operator for string
>  comparison.  The problem that I am running into is that I see no way
>  to do a reference test once you override the method.  In some
>  languages I have seen an === operator that always does a strict
>  reference test.  Is there any way to do something similar in nice?

You can simply give a new name to the == operation:

override boolean `==`(String s1, String s2) = s1.equals(s2);

boolean same(Object o1, Object o2) = o1 == o2;

void main(String[] args) {
  let s1 = "a", s2 = "ba".substring(1);
  println(s1 == s2); // true
  println(same(s1, s2)); // false
}

Daniel

[Nice-info] Overriding == for strings

[Dan S. <dan...@gm...>]

As a simple test, I am trying to override the == operator for string
comparison.  The problem that I am running into is that I see no way
to do a reference test once you override the method.  In some
languages I have seen an === operator that always does a strict
reference test.  Is there any way to do something similar in nice?

Dan

Re: [Nice-info] Nice syntax highlighting for ViM

[Yauheni A. <ea...@in...>]

On Thu, 07 Feb 2008 19:58:51 +0300, Yauheni Akhotnikau  
<ea...@in...> wrote:

> 	Hi!
>
> I've created the first version of syntax highlighting and file type
> dectection for ViM editor. It could be found at:
> http://www.vim.org/scripts/script.php?script_id=2144
>

Version 0.2 with support for public-read/private-write and  
try-catch-finally is available (at the same URL).

-- 
Regards,
Yauheni Akhotnikau
Senior Programmer
Intervale
e-mail:ea...@in... <mailto:ea...@in...>

Re: [Nice-info] Nice's DbC vs Eiffel DbC

[Yauheni A. <ea...@in...>]

Hi!

On Tue, 12 Feb 2008 19:12:20 +0300, Daniel Bonniot <bo...@gm...>  
wrote:

> Hi,
>
>> I can give full prototype for Derived#test (e.g. public void test(…)).  
>> In
>> such case compiler warns me:
>>
>> D:\home\eao197\tmp\nice\contracts\pre\main.nice: line 12, column 29:
>> warning: This method overrides nice.lang.void test(pre.Base
>> this,java.lang.String value)requires `>`(value.length(), 8):"value must  
>> be
>> at least 8 symbols",
>> You should make this explicit, either by omitting the return type
>> or by using the 'override' keyword
>
> As the message says, you could get rid of the warning by adding the
> override keyword.

It was my mistake: I wrote 'override' before 'public' and compiler  
complained about syntax error. Then I looked into parser.jj and learnt  
that 'override' should be used after visibility indicator.

>> I think, compiler should allow precondition specification in overridden
>> methods.
>
> It does, using this second form.
>
> Regarding execution of pre and post conditions in overriden methods, I
> don't have the details in memory at the moment, but you are welcome to
> test it.

I wrote a small program to test contracts:

enum ConditionType( String value )
   {
     precondition( "PRE" )
   , postcondition( "POST" )
   }

boolean lengthCheck(
   String value,
   ConditionType preOrPost,
   int minimalLength )
   {
     println( "<" preOrPost "# value: " value ", minimalLength: "  
minimalLength ">" );
     return value.length > minimalLength;
   }

class Base
   {
     String str = "";

     public void test( String value )
       requires value.lengthCheck( precondition, 8 ) : "base precondition:  
strong"
       ensures this.str.lengthCheck( postcondition, 8 ) : "base  
postcondition: strong"
       {
         println( "Base#test: value: " value );
         str = value;
       }
   }

class Derived extends Base
   {
     public override void test( String value )
       requires value.lengthCheck( precondition, 0 ) : "derived  
precondition: weak"
       ensures this.str.lengthCheck( postcondition, 10 ) : "derived  
postconditon: stronger"
       {
         println( "Derived#test: value: " value );
         str = value + value;
       }
   }

void main( String[] args )
   {
     let b = new Derived();
     b.test( "hello!" );
   }

// vim:ts=2:sts=2:sw=2:expandtab

and ran it:

java -ea -jar pre_and_post.jar
<precondition# value: hello!, minimalLength: 0>
Derived#test: value: hello!
<postcondition# value: hello!hello!, minimalLength: 10>

You can see that there aren't calls to Base's pre/postconditions. Expected  
behaviour for this example is:

java -ea -jar pre_and_post.jar
<precondition# value: hello!, minimalLength: 8>
<precondition# value: hello!, minimalLength: 0>
Derived#test: value: hello!
<postcondition# value: hello!hello!, minimalLength: 8>
<postcondition# value: hello!hello!, minimalLength: 10>

In the case when b.test is called with argument '0123456789' the expected  
behaviour is:

java -ea -jar pre_and_post.jar
<precondition# value: 0123456789, minimalLength: 8>
Derived#test: value: hello!
<postcondition# value: 0123456789, minimalLength: 8>
<postcondition# value: 0123456789, minimalLength: 10>

In that case precondition in Derived#test doesn't checked because Base's  
precondition is satisfied.

-- 
Regards,
Yauheni Akhotnikau
Senior Programmer
Intervale
e-mail:ea...@in... <mailto:ea...@in...>

Re: [Nice-info] Nice multiple dispatch details

[Daniel B. <bo...@gm...>]

Hi,


On Feb 7, 2008 8:09 AM,  <a4...@gm...> wrote:
> Hi,
>
> I have a few questions regarding the multiple dispatch mechanism in
> Nice and how it compares to other languages (CLOS, Dylan, Cecil
> etc.)
>
> When calling a method, Nice, like other multiple dispatch languages,
> has to chose the most appropriate method body from a set of
> available definitions (based on the dynamic type of the supplied
> arguments, of course).
>
> What are the criteria of grouping method definitions into a "dispatch
> set":
> - the method's name (I assume)
yes

> - the package where the method is defined?
they don't have to be in the same package, as long as all packages are
visible by being imported

> - the number of arguments?
yes

> - static types of arguments?
yes. Precisely, a method will override all other methods when both
would be applicable for some same set of arguments, and the overriding
methods has more specific types than the overriden one.

>
> In other words....
>
> * Example1:
>         package Car;
>         foo(Car a1, Motorcycle a2)
>         package Motorcycle;
>         foo(Motorcycle a1, Truck a2)
> ...will these methods be the same dispatch set?

No, given I assume something cannot be both a motorcycle and a truck.

But if there was also a foo(Vehicule, Vehicule), then that one would
be overridden by both of yours.

> * Example2:
>         foo(Car a1, Motorcycle a2)
>         foo(Car a1, Motorcycle a2, Truck a3)
> ...will these methods be in the same dispatch set?

No.

> * Example3:
>         abstract class Vehicle;
>         class Car extends Vehicle;
>         abstract class Person;
>         class Driver extends Person;
>
>         toString(Car a1) = (...);
>         toString(Driver a1) = (...);
>
>         void main(String[] args) {
>                 let d = new Driver();
>                 toString(d);
>         }
> ... will the 2 methods be in the same dispatch set?
Yes.

> I.e. when calling
> toString() with a Driver as an argument, will both method
> definitions be considered at runtime? Or is the compiler able to
> disambiguate these two, eliminating the need for dynamic dispatch
> (in this particular case)?

I believe the compiler will avoid the dynamic dispatch in this
particular case, but that's an implementation detail (an
optimization).

You are welcome to write such programs yourself to check the behaviour
of the compiler.

Cheers,

Daniel

Re: [Nice-info] Nice's DbC vs Eiffel DbC

[Daniel B. <bo...@gm...>]

Hi,

> I can give full prototype for Derived#test (e.g. public void test(…)). In
> such case compiler warns me:
>
> D:\home\eao197\tmp\nice\contracts\pre\main.nice: line 12, column 29:
> warning: This method overrides nice.lang.void test(pre.Base
> this,java.lang.String value)requires `>`(value.length(), 8):"value must be
> at least 8 symbols",
> You should make this explicit, either by omitting the return type
> or by using the 'override' keyword

As the message says, you could get rid of the warning by adding the
override keyword.

> I think, compiler should allow precondition specification in overridden
> methods.

It does, using this second form.

Regarding execution of pre and post conditions in overriden methods, I
don't have the details in memory at the moment, but you are welcome to
test it.

Cheers,

Daniel

[Nice-info] Nice's DbC vs Eiffel DbC

[Yauheni A. <ea...@in...>]

Hi!

Nice has the special syntax for overriding methods in derived classes:

class Base { public void f() { …  } }
class Derived extends Base { f() { … } }

But, if a method defines precondition then there isn’t a possibility to  
override such method – compiler informs about syntax error:

class Base
	{
		public void test( String value )
			requires value.length > 8 : "value must be at least 8 symbols"
			{
				println( "Base#test: value: " value );
			}
	}

class Derived extends Base
	{
		test( value )
			requires value.length > 0 : "value cannot be empty"
			{
				println( "Derived#test: value: " value );
			}
	}

void main( String[] args )
	{
		let b = new Derived();
		b.test( "hello!" );
	}

D:\home\eao197\tmp\nice\contracts>nicec --jar pre.jar pre
nice.lang: parsing
pre: parsing

D:\home\eao197\tmp\nice\contracts\pre\main.nice: line 13, column 25:
Encountered "requires".
Was expecting one of:
     "{" ...
     "=" ...

compilation failed with 1 error

I can give full prototype for Derived#test (e.g. public void test(…)). In  
such case compiler warns me:

D:\home\eao197\tmp\nice\contracts\pre\main.nice: line 12, column 29:
warning: This method overrides nice.lang.void test(pre.Base  
this,java.lang.String value)requires `>`(value.length(), 8):"value must be  
at least 8 symbols",
You should make this explicit, either by omitting the return type
or by using the 'override' keyword
pre: typechecking
pre: generating code
pre: linking
pre: writing in archive
nice.lang: writing in archive
compilation completed with 1 warning

I think, compiler should allow precondition specification in overridden  
methods.

The same situation is for post-conditions too.

Eiffel’s DesignByContract implementation allows specification of more  
detailed pre- and post-condition in derived classes. But pre- and  
post-conditions in overridden methods work as described bellow:
- base class’s pre-conditions are checked first. Only if they fail  
pre-condition from derived class are checked. It follows convention that  
derived class could relax demands for class users: e.g. user could break  
conditions for base class, but satisfy conditions for derived class. But  
if user satisfies conditions for base class conditions for derived class  
do not matter;
- all post-conditions are checked after method returns. It follows  
convention that derived class cannot relax its own obligations, but could  
make it more strict: e.g. method should guaranteed base class obligations  
(base class’s post-conditions passed) and can provide addition guaranties  
(its own post-conditions passed).

I think that if such behaviour would be implemented in Nice it will make  
Nice DbC more useful.

-- 
Regards,
Yauheni Akhotnikau
Senior Programmer
Intervale
e-mail:ea...@in... <mailto:ea...@in...>

[Nice-info] Nice syntax highlighting for ViM

[Yauheni A. <ea...@in...>]

	Hi!

I've created the first version of syntax highlighting and file type  
dectection for ViM editor. It could be found at:  
http://www.vim.org/scripts/script.php?script_id=2144

-- 
Regards,
Yauheni Akhotnikau
Senior Programmer
Intervale
e-mail:ea...@in... <mailto:ea...@in...>

[Nice-info] Nice multiple dispatch details

[<a4...@gm...>]

Hi,

I have a few questions regarding the multiple dispatch mechanism in 
Nice and how it compares to other languages (CLOS, Dylan, Cecil 
etc.)

When calling a method, Nice, like other multiple dispatch languages, 
has to chose the most appropriate method body from a set of 
available definitions (based on the dynamic type of the supplied 
arguments, of course).

What are the criteria of grouping method definitions into a "dispatch 
set":
- the method's name (I assume)
- the package where the method is defined?
- the number of arguments?
- static types of arguments?

In other words....

* Example1:
	package Car;
	foo(Car a1, Motorcycle a2)
	package Motorcycle;
	foo(Motorcycle a1, Truck a2)
...will these methods be the same dispatch set?

* Example2:
	foo(Car a1, Motorcycle a2)
	foo(Car a1, Motorcycle a2, Truck a3)
...will these methods be in the same dispatch set?

* Example3:
	abstract class Vehicle;
	class Car extends Vehicle;
	abstract class Person;
	class Driver extends Person;

	toString(Car a1) = (...);
	toString(Driver a1) = (...);

	void main(String[] args) {
		let d = new Driver();
		toString(d);
	}
... will the 2 methods be in the same dispatch set? I.e. when calling 
toString() with a Driver as an argument, will both method 
definitions be considered at runtime? Or is the compiler able to 
disambiguate these two, eliminating the need for dynamic dispatch 
(in this particular case)?

...Thanks a lot!
Radu.

[Nice-info] My first real-world Nice experience: impressions and proposals

[Yauheni A. <ea...@in...>]

Hi!

I’ve done my first Nice program which performs real-world task. It is a  
quick and dirty program written for solving one of unexpected problem in  
my work. The program reads log of SMPP data exchanges from the standard  
input, searches log records for SMS exchanges, analyzes SMS bodies and  
detects bad message bodies. I implemented the same task some time ago in D  
1.0 (with Tango library) and Eiffel (with EiffelStudio 6.0). So it is  
interesting to compare solutions on different languages. My Nice  
implementation could be found here:  
http://eao197.narod.ru/better_language/test_tasks/decode_7bit_bodies/decode_7bit_bodies.nice.html

Here I want to tell about some my impressions and make some proposals for  
Nice language and its standard library.

First of all I want to express my admiration about Daniel Bonniot and  
others Nice’s contributor’s work – you’ve made very attractive and usable  
language! Thanks for your efforts!

My Nice solution is very similar to D’s one. These languages propose  
similar set of features for user. D language is more actively developed  
now and has bigger community than Nice. However Nice is more attractive  
for me because it offers some features which I miss in D (for example,  
option types, multi methods) and provides access to large set of Java  
libraries. So I can say that Nice is more attractive language for every  
day programming for me than D.

However there are some small drawbacks which I’ve met during development.

= Drawbacks =

== Nice compiler’s error reporting ==

At first it is error reporting of the Nice compiler. I use VIM editor and  
run compilation from it. But, unfortunately VIM doesn’t understand format  
of Nice compiler error messages even with ‘--editor‘ argument. So I think  
it is good to have yet another format of such messages in the form:

<file>:<line>:<column>: <error description>

For example:

test/main.nice:1:1: undefined symbol X

Such format is already supported by several languages/compilers/tools  
(e.g. C/C++, D, Ruby) and because of that many editors already have  
support of that format.
And Nice compiler shouldn’t tell anything except errors/warning in this  
mode, i.e. no errors/warnings – no output.

== An absence of switch statement ==

The next is an absence of switch statement in the language. I know that  
value dispatch mechanism allows write code which illuminates need of  
switch. But sometimes switch requires much less coding, than using  
overloaded methods. For example I needed to parse escape sequences in a  
string. With switch such operation requires simple and obvious switch:

if( ‘\\’ == c )
   switch( line[ i + 1 ] ) {
     case ‘r’ : // ‘\r’ processing
     case ‘t’ : // ‘\t’ processing
     …
     case ‘x’: // ‘\xXX’ processing.
   }

But without switch I need to write some top-level overloaded methods for  
each kind of escape sequence:

SomeRetType onChar(current_char, line, index) { … }
onChar( ‘r’, line, index) { … }
onChar( ‘t’, line, index) { … }
…
onChar( ‘x’, line, index) { … }
…
if( ‘\\’ == c )
   … = onChar( line[i + 1], line, i+1);

or write sequence of if-else-if statements:

if( ‘\\’ == c ) {
   let next = line[i+1];
   if( ‘r’ == next ) …
   else if( ‘t’ == next ) …
…
}

I think that support of value dispatch for local functions could help  
there, because if allows to write less code then in the case of top-level  
overloaded methods:

if( ‘\\’ == c ) {
   void onChar( char ch ) { … }
   onChar( ‘r’ ) { … }
   onChar( ‘t’ ) { … }
   …
   onChar( line[i+1] );
}

== Error reporting in getopt library ==

The next is a error reporting in nice.getopt library. When  
nice.getopt.parse finds unknown option it prints error messages on the  
standard error stream and continues argument parsing. But such approach  
not always desirable. I think it is necessary to have mode in which  
nice.getopt.parse raises exception on unknown option.

== No source file name/line number in the exception stack trace ==

I use Nice 0.9.13 under Windows and on exception I have that:

java.lang.ArrayIndexOutOfBoundsException: 0
         at t1.fun.main(Unknown Source)
         at t1.dispatch.main(Unknown Source)

for the program:

void main( String[] args )
   {
     try
       {
         println( args[ args.length ] );
       }
     catch( Exception x )
       {
         x.printStackTrace();
       }
   }

May be it is a bug?

= Some proposals =

== A kind of Ruby/SmallTalk’s code blocks in Nice ==

Nice already has syntax sugar for methods with ()->void as last argument:

void f( ()-> void action ) { …; action(); … }
f() { bla-bla-bla }

And may be Nice could support such sugar for other types of lambdas. For  
example:

void g( (A, B, C)-> void action ) {
   …;
   action( p1, p2, p2 );
   …
}
g() { |a, b, c|
   …
}

where a, b and c will have types A, B and C.
It could allow writing less code. For example, I created helper function

String formatHelper( PrintStream => void printAction ) {
   … let ps = new PrintStream( … );…
   printAction( ps );
   … return …
}

which was used like this:

formatHelper( PrintStream printer => { … some actions … } );

Repeating “PrintStream printer =>” on every formatHelper invocation was a  
boring task. So the form:

formatHelper() { |printer| …some actions…}

looks more attractive.

== Ranges in the form [low,high) ==

AFAIK, Nice provides Range only in the form [low, high] (each limit  
included). Because of that sometimes I need to write:

for( i : 0..(array.length-1) ) …

I think it would be useful if there would be Ranges in the form [low,  
high) (excluding upper limit). Like in Ruby `…` operator could create such  
Range:

for( i : 0…array.length ) …

== Helper method eachLine in the standard library ==

The standard library contains readLine method. And I know from Ruby that  
such eachLine could be very useful sometimes:

void eachLine ( InputStream from, String->void action )
   {
     let reader = new BufferedReader( new InputStreamReader( from ) );
     var line = readLine( reader );
     while( line != null )
       {
         action( line );
         line = readLine( reader );
       }
   }

== Helper method sprintf in the standard library ==

Sometimes it is necessary to create description of something in the  
program (for example before raising exception). In that case the following  
sprintf method could help:

String sprintf( String formatString, Object[] args )
   {
     let buffer = new ByteArrayOutputStream();
     let printer = new PrintStream( buffer );
     printer.printf( formatString, args );
     return buffer.toString();
   }

Example of usage:

throw new IllegalValue( sprintf( “value ‘%d’ is out range [%d,%d]”,  
[ value, low, high ] ) );


--
That’s all now. Thanks for patience.
I’ll investigate Nice language further.


-- 
Regards,
Yauheni Akhotnikau
Senior Programmer
Intervale
e-mail:ea...@in... <mailto:ea...@in...>

Re: [Nice-info] Operator overloading in Nice

[Yauheni A. <ea...@in...>]

Hi!

On Thu, 31 Jan 2008 15:16:24 +0300, Daniel Bonniot <bo...@us...>  
wrote:

>> But I didn't see any mention about that in the Nice manual. Is operator
>> overloading is an official feature of the language? Or it is a part of
>> implementation and souldn't be used in user code.
>
> You can use it in user code.

Cool! This is yet another advantage of Nice over Java! So the short  
summary about Nice could be:

"New object-oriented programming language based on Java, with the  
following advanced features: parametric types, anonymous functions,  
multi-methods, tuples, optional parameters and operator overloading. Nice  
also detects more errors during compilation (null pointers, casts)."

:)

-- 
Regards,
Yauheni Akhotnikau
Senior Programmer
Intervale
e-mail:ea...@in... <mailto:ea...@in...>