favorite or most important language features?

favorite or most important language features?

Post by Marshall S » Mon, 08 Dec 2003 10:20:06


Hi all,

I'm interested to hear what people on this group consider
their favorite language features, or the ones they consider
most important. If you want to include a description of
why you consider the feature or features important, that
would be great.

I think garbage collection is probably the most useful
feature, even though it's unobtrusive. Life is so much
better when I don't have to manage memory myself,
and live with the associated debugging problems.

My favorite feature is polymorphism. It's just fun.

Anyone?


Marshall
 
 
 

favorite or most important language features?

Post by Christian » Mon, 08 Dec 2003 10:54:23

First class closures.

Reflexivity.

 
 
 

favorite or most important language features?

Post by Bruce Houl » Mon, 08 Dec 2003 13:51:35

In article <9fvAb.320422$9E1.1587785@attbi_s52>,



#1) garbage collection
#2) anonymous functions with lexical scoping and indefinite lifetime.
#3) powerful macros, preferably pattern-rewriting and hygienic,
but elisp/CL style with gensym will do in a pinch.

Given the above you can efficiently implement just about anything else
you might want.

Next come non-local exits, a type system and (optional) declarations,
and generic functions.

-- Bruce
 
 
 

favorite or most important language features?

Post by robert.wil » Tue, 09 Dec 2003 06:52:28

I don't have primarly fun with the language, but with the problems
solved. Huge and complex problems are best and the require simple
languages.

I consider Contracts the most important feature and I'm currently
writing an article on why.

The next thing are naming and recursion. These are in fact the most
basic features and without them you can't do anything (supposing we
haven't loops and gotos, which I both consider unnecessary). And
function application.

To protect contracts, you need modular scope (which when made good
implies abstract data types and in OO languages even allows
polymorphism, which again profits from contracts).

The language feature of the future is refinement. Algorithmic
refinement to replace loops. (See E.C.R.Hehner: "do considered od: a
Contribution to the Programming Calculus", Acta Informatica, v.11,
1979, p.287-304) And refinement of Modules to do firm and efficient
software design. (See one of the books on B,
http://www.yqcomputer.com/ @INRETS/B-Bibliography/B-Bibliography002.html.)


Yes, I'm really some kind of purist, but I want to have have with
programming languages and solve problems. Features only get into the
way.

Bob.
 
 
 

favorite or most important language features?

Post by Marshall S » Tue, 09 Dec 2003 09:28:42


I assume you mean nested functions that can operate on
variables defined in the enclosing scope. By "indefinite
lifetime" I assume you mean that they can be returned
from their enclosing scope and still be invoked.

There's an aspect of that that bothers me, which is what
happens to variables declared in the enclosing scope.
If the values they contain persist, then this feature means
you necessarily have "static local" (to use C terminology)
variables. That is, functions can have encapsulated state.

Is that behavior an important part of anonymous functions
for you?



That's pretty broad. Can you say what aspects of non-local
exits matter? Or, what do you consider good examples?


Marshall
 
 
 

favorite or most important language features?

Post by chri » Tue, 09 Dec 2003 09:53:02


HOFs, concurreny, continuations and pattern matching. GC is nice too.
I also like state.
 
 
 

favorite or most important language features?

Post by mwotto » Tue, 09 Dec 2003 10:11:40

On Mon, 08 Dec 2003 00:53:02 +0000, chris posted:


Mutable state, you mean? A language without any state at all is, well, limited.

mrak

--
realise your life was only bait for a bigger fish
-- aesop rock
 
 
 

favorite or most important language features?

Post by Joachim Du » Tue, 09 Dec 2003 10:54:45


I always regarded state as mutable by definition.

Regards,
Jo
 
 
 

favorite or most important language features?

Post by Bruce Houl » Tue, 09 Dec 2003 14:46:51

In article <_APAb.331165$ao4.1111718@attbi_s51>,






Absolutely. But not it's not a single static variable like C, but one
per instance of the closure. (actually it's hard to say what C would
do, since it doens't have nested functions in the first place)



A block of code can declare a function that, when called, will exit the
block and provide a value (or values) for the block. The function can
be called from anywhere with the dynamic extent of the block (not just
the lexical extent), which means that you also have to be able to pass
it as an argument, and store it in a data structure.

I'm happy if it becomes invalid after you call it, or if you return from
the block in which it was created, but if a language wants to provide a
more general form that's OK too.

Given the above, you can build C's "return", "break", "continue" (or
Perl's "next", "last") as special cases with lexical scoping, but you
can also do what C programmers would normally use longjmp for in
exception handling.

-- Bruce
 
 
 

favorite or most important language features?

Post by Marshall S » Tue, 09 Dec 2003 15:13:49


Yeah, that's the part that bugs me: it turns functions into objects.

To keep this from turning functions into objects, the captured
variables (once the enclosing scope has exited) have to be
either persistent and immutable, or transient and mutable.
That is, once the scope exits, the captured variables then
either become contants, a la partial application, or they
become locals of the closure, reinitialized when the function
is called again.

Does either option appeal?


Marshall
 
 
 

favorite or most important language features?

Post by Fergus Hen » Tue, 09 Dec 2003 16:08:06

"Marshall Spight" < XXXX@XXXXX.COM > writes:


I think my favourite would have to be run-time safety, in the sense that
problems such as array bounds errors, invalid pointer dereferences,
or equivalent should result in run-time errors rather than arbitrary
data corruption.

--
Fergus Henderson < XXXX@XXXXX.COM > | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: < http://www.yqcomputer.com/ ~fjh> | -- the last words of T. S. Garp.
 
 
 

favorite or most important language features?

Post by Bruce Houl » Tue, 09 Dec 2003 17:38:27

In article <xEUAb.466589$Fm2.457419@attbi_s04>,



You say that like it's a *bad* thing.



That is OK some of the time, but I'd prefer not, unless you're in a
langauge where mutation is severely frowned upon. (I like to minimise
mutation, but you do want it sometimes)

I'm not sure that a restriction on mutation (as in Java, where variables
referred to by "inner classes" must be "final") in an otherwise
freely-mutating language has much point. It's at once annoying, and
trivial (but tedious) to get around, by making the variable you want to
mutate a one-element array instead. I find that ugly, although it seems
to be standard practrise in, say, OCaml.



No.

For a start, it would make syntax-transforming macros *far* less useful.

For example:

define macro while
{ while (?:expression) ?:body end }
=> { begin
local method loop ()
if (?expression)
?body;
loop();
end;
end;
loop();
end }
end;


begin
let t = 0;
let n = 100;
while (n > 0)
t := t + n;
n := n - 1;
end;
t;
end


You couldn't do that if you weren't allowed to modify the closure
variables, or they didn't persist between invocations.

Of course purist functional programmers would prefer to have n and t be
arguments to the tail-recursive function, but that's not relevent to the
present discussion. The compiler might well transform the code, and I
could if required show another macro that achieves that, using syntax
like...

for(t = 0 then t + n,
n from 100 to 1 by -1)
finally
t
end


In summery: unless you deprecate assignment in general, I don't think
you should deprecate assignment to closure variables.

-- Bruce
 
 
 

favorite or most important language features?

Post by Marcin 'Qr » Tue, 09 Dec 2003 18:06:53


Closures (not restricted to passing them down) require garbage collection.
These variables live as long as closures need them.

--
__("< Marcin Kowalczyk
\__/ XXXX@XXXXX.COM
^^ http://www.yqcomputer.com/ ~qrczak/
 
 
 

favorite or most important language features?

Post by Marcin 'Qr » Tue, 09 Dec 2003 18:09:36


That's good! A function is a very convenient notation for an object with
one method. Usually more convenient than constructs of traditional OO
languages.

--
__("< Marcin Kowalczyk
\__/ XXXX@XXXXX.COM
^^ http://www.yqcomputer.com/ ~qrczak/
 
 
 

favorite or most important language features?

Post by gt5163 » Tue, 09 Dec 2003 18:44:12

Marcin 'Qrczak' Kowalczyk < XXXX@XXXXX.COM > once said:


This is how closures work in most languages with closures, but I don't
think it necessarily ought to be considered an absolute. Closures could
capture references without altering the lifetimes of variables (meaning
that you may end up with "dangling references" (and associated run-time
errors or crashes) if the closures outlast the variables). Or closures
can just capture "copies" (rather than references). In a language like
C++ (which doesn't have closures or GC), both of these techniques are
sometimes employed when creating "function objects".

I think I would say "closures require GC _if_ they capture references
and they cannot creating dangling references". (Or maybe I am just
arguing terminology--perhaps you would not call it a "closure" if it
didn't capture-by-reference or if it created the possibility of
dangling references.)

--
Brian M. McNamara XXXX@XXXXX.COM : I am a parsing fool!
** Reduce - Reuse - Recycle ** : (Where's my medication? ;) )