• Mark Evans (16/16) Feb 18 2003 A bit more of a toy than Vault or Cyclone, but worth a look. Note the
• Sean L. Palmer (12/28) Feb 19 2003 The most interesting thing for D that it has is the Rational datatype. ...
• Mark Evans (4/6) Feb 19 2003 No, the most interesting thing for D is that Nickle offers first-class
• Peter Hercek (27/33) Feb 20 2003 I probably do agree about this with you, but can you enlighten me
• Walter (4/6) Feb 22 2003 Can you elucidate just what the requirements of first class function sup...
• Peter Hercek (52/58) Feb 24 2003 Well I'm not a big specialist in the field of compilers and languages,
• Walter (1/1) Mar 01 2003 Thanks, I think I understand now.
• Ilya Minkov (17/31) Feb 20 2003 Yes, it's really inereseting. For 2 reasons:
• Peter Hercek (14/45) Feb 20 2003 I personally do not care much whether rational numbers will

Mark Evans <Mark_member pathlink.com> writes:

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" <seanpalmer directvinternet.com> writes:

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."

Mark Evans <Mark_member pathlink.com> writes:

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

"Peter Hercek" <vvp no.post.spam.sk> writes:

"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 expecting that it would be the same as D):
1) they can take advantage of an anonymous function (because one


   explicitly created usig new)
3) they would be able to grab local scope of the fuction automaticaly

   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

 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.

"Walter" <walter digitalmars.com> writes:

"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>.

"Peter Hercek" <vvp no.post.spam.sk> writes:

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


 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>.

"Walter" <walter digitalmars.com> writes:

Thanks, I think I understand now.

Ilya Minkov <midiclub 8ung.at> writes:

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

"Peter Hercek" <vvp no.post.spam.sk> writes:

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