A bit more of a toy than Vault or Cyclone, but worth a look.  Note the incorporation of rational numbers and the term 'real' -- both of which I advocated in these pages.  Note also that like Vault, Nickle has first-class functions.  -M.

http://www.nickle.org/ http://www.nickle.org/usenix-nickle.pdf

"Nickle is a vaguely C-like programming language for numerical applications, useful both as a desk calculator and as a prototyping and implementation language for numerical and semi-numerical algorithms. Nickle abstracts a number of useful features from a wide variety of other programming languages, particularly functional languages. Nickle's design principles and implementation pragmatics mesh nicely to form a language filling a useful niche in the UNIX software environment. The history of Nickle is also an instructive example of the migration of an application from an idea to a freely-available piece of software."

The most interesting thing for D that it has is the Rational datatype.  It's two integers, with an implicit division.

1 / 3  is stored as a 1 and a 3

2 * 5 / (3 * 7) is stored as a 10 and a 21

1 / 3 + 1 / 2  is stored as 2 / 6 + 3 / 6 = 5 / 6

They can be freely converted to floating point, at which time the actual division is performed.  I'm sure there are some other issues but the idea sounds nice.

Sean

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b2vd4c$25nk$1@digitaldaemon.com...
> A bit more of a toy than Vault or Cyclone, but worth a look.  Note the incorporation of rational numbers and the term 'real' -- both of which I advocated in these pages.  Note also that like Vault, Nickle has
first-class
> functions.  -M.
>
> http://www.nickle.org/ http://www.nickle.org/usenix-nickle.pdf
>
> "Nickle is a vaguely C-like programming language for numerical applications, useful both as a desk calculator and as a prototyping and implementation language for numerical and semi-numerical algorithms. Nickle abstracts a number of useful features from a wide variety of other programming languages, particularly functional languages. Nickle's design principles and implementation pragmatics mesh nicely to form a language filling a useful niche in the UNIX software environment. The history of Nickle is also an instructive example of the migration of an application from an idea to a freely-available piece of software."

Sean L. Palmer says...
>
>The most interesting thing for D that it has is the Rational datatype.  It's two integers, with an implicit division.

No, the most interesting thing for D is that Nickle offers first-class
functions. Rational numbers are a sidelight.
Mark

Yes, it's really inereseting. For 2 reasons:
 - it makes rethink division operators in D;
 - it would be good for performance, since division is slow.

However, it faces folowing problems:
 - it need not be stored as 2 integers. Implementation should be able to change its storage into int/real, real/int, real/real, since when a rational is multiplied/divided by a real, the type of one of its parts becomes real, and the other stays as it was. Type conversion without an operation could be slow (?) since it would requiere loading and unloading a value to FPU anyway (???).

BTW, extended is quite an inconvenient type for stack and memory. How about a compiler switch/ pragma which would favor the intermediate type to double, in cases where precision is not wanted, and also set FPU precision do double? It's an implemenation detail though, and thus now unimportant.

-i.

Sean L. Palmer wrote:
> The most interesting thing for D that it has is the Rational datatype.  It's
> two integers, with an implicit division.
> 
> 1 / 3  is stored as a 1 and a 3
> 
> 2 * 5 / (3 * 7) is stored as a 10 and a 21
> 
> 1 / 3 + 1 / 2  is stored as 2 / 6 + 3 / 6 = 5 / 6
> 
> They can be freely converted to floating point, at which time the actual
> division is performed.  I'm sure there are some other issues but the idea
> sounds nice.
> 
> Sean

I personally do not care much whether rational numbers will
 be there or not. But if they would be introduced, I would expect
 them to behave like this:
1) only integer / natural number is a rational number
2) int/real, real/int, real/real; these numbers are real and not
   rational anymore
3) the good rational type should take care so that it does not
   overflow when not necessary -> leads to searches of biggest
   common denominator
4) comparisons will require searches of smallest common
    multiply

... so it will not be quick and probably there are more interesting
 features to introduce

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b33nro$4in$1@digitaldaemon.com...
> Yes, it's really inereseting. For 2 reasons:
>   - it makes rethink division operators in D;
>   - it would be good for performance, since division is slow.
>
> However, it faces folowing problems:
>   - it need not be stored as 2 integers. Implementation should be able
> to change its storage into int/real, real/int, real/real, since when a
> rational is multiplied/divided by a real, the type of one of its parts
> becomes real, and the other stays as it was. Type conversion without an
> operation could be slow (?) since it would requiere loading and
> unloading a value to FPU anyway (???).
>
> BTW, extended is quite an inconvenient type for stack and memory. How about a compiler switch/ pragma which would favor the intermediate type to double, in cases where precision is not wanted, and also set FPU precision do double? It's an implemenation detail though, and thus now unimportant.
>
> -i.
>
> Sean L. Palmer wrote:
> > The most interesting thing for D that it has is the Rational datatype.  It's two integers, with an implicit division.
> >
> > 1 / 3  is stored as a 1 and a 3
> >
> > 2 * 5 / (3 * 7) is stored as a 10 and a 21
> >
> > 1 / 3 + 1 / 2  is stored as 2 / 6 + 3 / 6 = 5 / 6
> >
> > They can be freely converted to floating point, at which time the actual division is performed.  I'm sure there are some other issues but the idea sounds nice.
> >
> > Sean
>

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b30v4o$mvu$1@digitaldaemon.com...
> Sean L. Palmer says...
> >
> >The most interesting thing for D that it has is the Rational datatype.  It's two integers, with an implicit division.
>
> No, the most interesting thing for D is that Nickle offers first-class functions. Rational numbers are a sidelight.

I probably do agree about this with you, but can you enlighten me
 and point out what more features I can get from native first-class
 function implementations compared with delegates or functors?

I try to point out what I see myself:

delegates (well I do not know D delegates so I will write about C#
 delegates expecting that it would be the same as D):
1) they can take advantage of an anonymous function (because one
   cand create a delegate only from a named function in C#)
2) they need not to be explicitly created (C# delegate must be
   explicitly created usig new)
3) they would be able to grab local scope of the fuction automaticaly
   (in C# there is no local scope - only object atributes when the
   delegate is a member method)
4) they would not be synchronized with windows message queue
   (ie probably much quicker)

... I would tell delegates are first class functions from all the other
 points of view. By suporting them we would get rid of the 4
 disadvantages above. Number of code lines: C# delegates
 do require 2 lines more (delegate signature declaration and
 explicit delegate creation).

templated functors:
1) they must be resolved in compile time - I'm not sure whether
   this is really a problem - looks like not
2..99) IT'S PAIN IN ASS TO CREATE THEM

... native first-class function support would lead to a much smaller
 number of lines of code.

"Peter Hercek" <vvp@no.post.spam.sk> wrote in message news:b34e2e$n83$1@digitaldaemon.com...
> ... native first-class function support would lead to a much smaller
>  number of lines of code.

Can you elucidate just what the requirements of first class function support are? I've done some googling around, and have found lots of confusion <g>.

Well I'm not a big specialist in the field of compilers and languages,
 but I can try to write down what I know about possible requirements of
 first class functions.

First class function only menas that functions do represnet a type,
 which is of "first-class". A language supports some data type as
 "first-class" when the objects of the type can be created and used
 as data at run time. "First-class" data can be created, kept in
 variables, and passed to and returned from functions. In dynamically
 typed languages, "first-class" data can also have its type examined
 at run-time.

In fact there are two extremes:
1) pure functional languages which do not know assignmenet; they keep
 all the state information on stack (input output arguments of
 mutually called functions); one needs quite complex data (eg lists
 which can contain lists or leaf items without restrictions) to make
 something usefull with this, so actually one pusts only references
 on the stack
2) pure procedural language, procedures do work only over global
 variables (no function arguments, no return value)

We are somewhere in the middle typically. Probably no language supports
 only the extremes.

I try to comment on my delegates example. They pretty good fit the
 requirements for first class objects. They have only one of these
 two non-trivial problems (it is enough to solve one of them):
1) they need to capture the local context of the delegate creation
 and detach it from future program run; this has two parts: stack
 frame (if referenced) and the state of the object, from which
 delegate was created (if referenced or aplicable)
2) they need to take values passed to them at the time of creatin
 (take them "by value") and pass them further as part of a composed
 result; no external contenx (initial stack frame, oject atributes)
 would be allowed

I mentioned that C# delegates do miss properties in the point one.
 One can make workaround for this, by creating a separate object
 for each delegate and put the local context to the object state.
 But you have one line more for each object creation (this is
 already 3 lines overhead for each creation and you must have the
 object defined somewhere too).

Alternative 2 looks much more reasonable (and probably also easier
 to implement). You would return a delegate composition tree like
 structure - each node containing local state of the function
 creating the delegate and pointers to the lover level delegates.
 Any node which does not contain references to delegates could
 be considered as a reaf. Then calling the resulting first class
 function is only calling the top level delegate with its required
 arguments.

For all this you can do a workaround when the language does not
 support it, but it costs you more lines :(

Although, intorducing some support for aspect oriended programming
 can be more interesting compared to first-class functions, which
 are only one of ways how to achieve some polymorfic behavior IMHO.



"Walter" <walter@digitalmars.com> wrote in message news:b39h08$2fio$2@digitaldaemon.com...
>
> "Peter Hercek" <vvp@no.post.spam.sk> wrote in message news:b34e2e$n83$1@digitaldaemon.com...
> > ... native first-class function support would lead to a much smaller
> >  number of lines of code.
>
> Can you elucidate just what the requirements of first class function support are? I've done some googling around, and have found lots of confusion <g>.

Thanks, I think I understand now.