From: KT
Subject: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <4fb5c28e-f8fb-44c1-9cf0-31c366bdb320@e4g2000hsg.googlegroups.com>
I figured that many of you might be interested

Video of Steele talking at JAOO and slides.

http://www.infoq.com/presentations/fortress-steele

From: Frank Buss
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <sn0741p8glti.p8qppcrhk6lw.dlg@40tude.net>
KT wrote:

> I figured that many of you might be interested
> 
> Video of Steele talking at JAOO and slides.
> 
> http://www.infoq.com/presentations/fortress-steele

The video works only for the first third part, then stops. But why do you
think a Lisp programmer would be interested in a statically typed language?
Fortress sounds a bit like a mix of Haskell and Java, with some nice
additional features, like extending the syntax, but this is possible with
Lisp macros, too. Maybe a good idea is to use a mathematical syntax, but
then operator overloading doesn't work very well with the Lisp philosophy
of dynamic typing and explicit programming (you write what you mean, e.g.
(concatenate 'string foo bar)), vs. implicit programming ((+ foo bar), and
then searching the type of foo and bar, and the meaning of #'+ in other
parts of the source code).

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Pascal Costanza
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <5v96soF1lakddU1@mid.individual.net>
Frank Buss wrote:
> KT wrote:
> 
>> I figured that many of you might be interested
>>
>> Video of Steele talking at JAOO and slides.
>>
>> http://www.infoq.com/presentations/fortress-steele
> 
> The video works only for the first third part, then stops. But why do you
> think a Lisp programmer would be interested in a statically typed language?
> Fortress sounds a bit like a mix of Haskell and Java, with some nice
> additional features, like extending the syntax, but this is possible with
> Lisp macros, too. Maybe a good idea is to use a mathematical syntax, but
> then operator overloading doesn't work very well with the Lisp philosophy
> of dynamic typing and explicit programming (you write what you mean, e.g.
> (concatenate 'string foo bar)), vs. implicit programming ((+ foo bar), and
> then searching the type of foo and bar, and the meaning of #'+ in other
> parts of the source code).

Fortress is indeed targeted more at Java programmers than at users of 
more advanced programming languages, but nevertheless, it has some 
interesting ideas. Nothing earth-shattering, but nevertheless, I 
wouldn't dismiss it too quickly...


Pascal

-- 
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/

My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: KT
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <2ea00ef1-258e-4704-91f8-89b5ba89ef1e@i29g2000prf.googlegroups.com>
On Jan 17, 4:26 pm, Pascal Costanza <····@p-cos.net> wrote:
> Fortress is indeed targeted more at Java programmers than at users of
> more advanced programming languages, but nevertheless, it has some
> interesting ideas. Nothing earth-shattering, but nevertheless, I
> wouldn't dismiss it too quickly...
>
> Pascal

Fortran: "To Do for Fortran What Java Did for C" is their motto. It is
targeted exclusively to Fortran programmers and scientific
supercomputing applications. I think the main interest is how Steele
and Co are going to succeed in integrating language features into
coherent whole. But if there is one person who has experience with
this kind of work, it is Steele.

The presentation is IMHO really good. Main themes I piked:

- Growing the language by experts using libraries, core fortress is
really small: objects and traits.

- Modularity. You can take out reals from core library and replace it
with your own implementation. It should still work with the rest of
the core library.

- Efficient abstractions with static and dynamic optimizations, type
inference.

- Parallelism is default (My first impression is that they are aiming
at MapReduce kind of functionality in the language level).

- They are going to experiment with mathematical syntax (emphasis on
experiment).


--
From: smallpond
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <d9439e2f-d9b4-44cb-9ff7-35c095e70179@k39g2000hsf.googlegroups.com>
On Jan 17, 10:02 am, KT <······@gmail.com> wrote:
> - They are going to experiment with mathematical syntax (emphasis on
> experiment).
>
> --


It looks like I can dust off my APL keyboard.
From: Frank Buss
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <cwg19hli51n8.1a599sr1e25ub$.dlg@40tude.net>
Pascal Costanza wrote:

> Fortress is indeed targeted more at Java programmers than at users of 
> more advanced programming languages, but nevertheless, it has some 
> interesting ideas. Nothing earth-shattering, but nevertheless, I 
> wouldn't dismiss it too quickly...

I watched the rest of the video (streaming worked after some hours again)
and looks like there are really some interesting ideas. I like the idea of
using a very small compiler and providing as much as possible in libraries,
with an integrated versioning system and allowing the programmer to replace
libraries with ones with higher performance or better memory usage etc. The
libraries even helps how to compile things like the reducers etc. at
runtime.

Sounds a bit complicated how it is interweaved, but I hope they'll release
the source code of anything to take a look at it.

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: KT
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <dab4253b-b6b1-4752-908f-ae2cc82c48a3@i3g2000hsf.googlegroups.com>
On Jan 17, 10:26 pm, Frank Buss <····@frank-buss.de> wrote:
> but I hope they'll release
> the source code of anything to take a look at it.
>
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de

svn checkout http://fortress.sunsource.net/svn/fortress/trunk fortress
--username username

--
From: dr2chase
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <7d2dacaf-ed97-42d9-b6c9-2b1362c255b5@n20g2000hsh.googlegroups.com>
On Jan 17, 5:06 pm, KT <······@gmail.com> wrote:
> On Jan 17, 10:26 pm, Frank Buss <····@frank-buss.de> wrote:
>
> > but I hope they'll release
> > the source code of anything to take a look at it.

This link is far more current:

svn checkout http://projectfortress.sun.com/svn/Community/trunk PFC

It's a Trac project

http://projectfortress.sun.com/Projects/Community/wiki
From: Pertti Kellomäki
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <fmnoet$bci$1@news.cc.tut.fi>
Frank Buss wrote:
>  But why do you
> think a Lisp programmer would be interested in a statically typed language?

Some of us are interested in what the author of "Common Lisp,
the Language" is up to nowadays.
-- 
Pertti
From: Frank Buss
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <1k143beuf5q8w$.1d3iudo6h4v4s$.dlg@40tude.net>
Pertti Kellom�ki wrote:

> Some of us are interested in what the author of "Common Lisp,
> the Language" is up to nowadays.

Maybe he has learned something from the mistakes of the past and now
develops statically typed languages with type inference, like Haskell :-)

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Pascal J. Bourguignon
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <7c8x2ol86z.fsf@pbourguignon.anevia.com>
Frank Buss <··@frank-buss.de> writes:

> Pertti Kellom�ki wrote:
>
>> Some of us are interested in what the author of "Common Lisp,
>> the Language" is up to nowadays.
>
> Maybe he has learned something from the mistakes of the past and now
> develops statically typed languages with type inference, like Haskell :-)

Or maybe he just couldn't find a CL job, and is happy to have landed a
job in the statically typed world, like most of us?  :-)

-- 
__Pascal Bourguignon__
From: Rainer Joswig
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <joswig-1FE1F6.18353117012008@news-europe.giganews.com>
In article <··············@pbourguignon.anevia.com>,
 ···@informatimago.com (Pascal J. Bourguignon) wrote:

> Frank Buss <··@frank-buss.de> writes:
> 
> > Pertti Kellom�ki wrote:
> >
> >> Some of us are interested in what the author of "Common Lisp,
> >> the Language" is up to nowadays.
> >
> > Maybe he has learned something from the mistakes of the past and now
> > develops statically typed languages with type inference, like Haskell :-)
> 
> Or maybe he just couldn't find a CL job, and is happy to have landed a
> job in the statically typed world, like most of us?  :-)

He is a language designer. Besides his work on Scheme and Common Lisp,
he is known for a lot of things:

* co-wrote a book on C
* was involved in the ANSI C standard
* worked on High Performance Fortran (HPF)
* worked on Java, co-wrote the Java Spec
* worked on ECMAScript (JavaScript)

and more

For Lisp-interested people particularly interesting is
the Hacker's Dictionary (the Steele version from 1983).

http://jargon-file.org/archive/jargon-1.5.0.dos.txt
From: Ken Tilton
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <478fd57f$0$11561$607ed4bc@cv.net>
Rainer Joswig wrote:
> In article <··············@pbourguignon.anevia.com>,
>  ···@informatimago.com (Pascal J. Bourguignon) wrote:
> 
> 
>>Frank Buss <··@frank-buss.de> writes:
>>
>>
>>>Pertti Kellom�ki wrote:
>>>
>>>
>>>>Some of us are interested in what the author of "Common Lisp,
>>>>the Language" is up to nowadays.
>>>
>>>Maybe he has learned something from the mistakes of the past and now
>>>develops statically typed languages with type inference, like Haskell :-)

That would explain the quote about Java having dragged people away from 
C++. Towards Lisp. PWUAHAHAHAHHAHAAA!

>>
>>Or maybe he just couldn't find a CL job, and is happy to have landed a
>>job in the statically typed world, like most of us?  :-)

Traitors all! To yourselves and to mankind, who needs Lisp! Starbucks is 
hiring, programming is to sacred to compromise over.

> 
> 
> He is a language designer. Besides his work on Scheme and Common Lisp,
> he is known for a lot of things:
> 
> * co-wrote a book on C
> * was involved in the ANSI C standard
> * worked on High Performance Fortran (HPF)
> * worked on Java, co-wrote the Java Spec
> * worked on ECMAScript (JavaScript)

And Constraints, a godawful mess as bad as Java.

kt

-- 
http://www.theoryyalgebra.com/

"In the morning, hear the Way;
  in the evening, die content!"
                     -- Confucius
From: jimka
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <b1e57bcd-c4f3-4460-9ed2-55fd88fd9721@i7g2000prf.googlegroups.com>
steele makes a very interesting claim.  He says that operator
overloading
in C++ failed because there are not enough operators.  Fortress allows
operator overloading but encourages using traditional notation using
the seemingly limitless set of unicode characters.
There are 50 years of computer programming notation evolution, but
there are 500
years of mathematical notation evolution.

most of our current notation comes from fortran, and fortran was first
done on keyboards designed for business, not for mathematics.  Before
Fortran, Stelle said that the * character was used only once anywhere
in mathematics in one paper he could find.  But Fortran convinced
us that * means multiply ... Whereas tradition dictates that
juxtaposing
is the traditional notation for multiplication.

He also distinguishes binding, from updating, from looping.

x := means i cannot change the variable
x = means updating a variable
x <-  (actually the Unicode arrow) means streaming from a sequence
but order independent.

I must admit that the code samples he shows in the video are very
intuitive to read.
From: Tamas
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <0a1fa901-3044-4dcb-9185-bab31d024779@i7g2000prf.googlegroups.com>
On Jan 17, 7:23 pm, jimka <·····@rdrop.com> wrote:
> steele makes a very interesting claim.  He says that operator
> overloading
> in C++ failed because there are not enough operators.  Fortress allows
> operator overloading but encourages using traditional notation using
> the seemingly limitless set of unicode characters.
> There are 50 years of computer programming notation evolution, but
> there are 500
> years of mathematical notation evolution.
>
> most of our current notation comes from fortran, and fortran was first
> done on keyboards designed for business, not for mathematics.  Before
> Fortran, Stelle said that the * character was used only once anywhere
> in mathematics in one paper he could find.  But Fortran convinced
> us that * means multiply ... Whereas tradition dictates that
> juxtaposing
> is the traditional notation for multiplication.
>
> He also distinguishes binding, from updating, from looping.
>
> x := means i cannot change the variable
> x = means updating a variable
> x <-  (actually the Unicode arrow) means streaming from a sequence
> but order independent.
>
> I must admit that the code samples he shows in the video are very
> intuitive to read.

I watched 20 minutes of that video, and now I am afraid I will have
nightmares when I go to bed.

A lot effort is spent on notation, only to come up with a really
baroque system.  Version control in the libraries? (if I understood
that right).  Seen on a slide at 21:57: "Repeat the success of the
Java Virtual Machine."  Indeed.

This seems like another language designed for "somebody else" by a
committee; in this case the audience seems to be engineers who use
Fortran.  But that misses the point: very few people use Fortan
because they love it so much, they use it because a lot of (legacy)
code and reasonably good compilers are available, and it is the status
quo anyway in some communities.  Yeah, static type checking of
physical units is the thing we have been missing all these years.

About math: mathematical notation is great, but most of it is ad hoc
and context-dependent (compare the role of the superscripts in
\sin^2(x)+\cos^2(x)=1 and \cos^{-1}(x)), that is one reason it is so
useful: you can write it quickly, and the context is usually obvious
for humans who understand the semantics behind the syntax.  But for
programming, math notation becomes a nightmare.

Tamas
From: tim Josling
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <13p06v2o3m7hp36@corp.supernews.com>
On Thu, 17 Jan 2008 17:31:34 -0800, Tamas wrote:

> About math: mathematical notation is great, but most of it is ad hoc
> and context-dependent (compare the role of the superscripts in
> \sin^2(x)+\cos^2(x)=1 and \cos^{-1}(x)), that is one reason it is so
> useful: you can write it quickly, and the context is usually obvious
> for humans who understand the semantics behind the syntax.  But for
> programming, math notation becomes a nightmare.
> 
> Tamas

Yes, and I don't want code to be as hard to read as math texts or papers.
One-character variable names, etc...

Tim Josling
From: Sohail Somani
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <HSWjj.6280$vp3.5074@edtnps90>
On Fri, 18 Jan 2008 03:24:18 +0000, tim Josling wrote:

> Yes, and I don't want code to be as hard to read as math texts or
> papers. One-character variable names, etc...

Fortran code is full of one character variable names. One time I was 
reading some code and was convinced it was computer generated as there 
was no way a human could follow that. I asked around and sure enough, it 
was hand written.

So Fortran programmers would be right at home!

-- 
Sohail Somani
http://uint32t.blogspot.com
From: Geoffrey Summerhayes
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <37bfd15a-e994-42d9-aada-7f65c895acd2@e10g2000prf.googlegroups.com>
On Jan 18, 12:33 am, Sohail Somani <······@taggedtype.net> wrote:
> On Fri, 18 Jan 2008 03:24:18 +0000, tim Josling wrote:
> > Yes, and I don't want code to be as hard to read as math texts or
> > papers. One-character variable names, etc...
>
> Fortran code is full of one character variable names. One time I was
> reading some code and was convinced it was computer generated as there
> was no way a human could follow that. I asked around and sure enough, it
> was hand written.

You missed an interesting era. We weren't trying to be obscure,
just trying to fit the damn programs onto 80-column punch cards.
Nothing like tripping and playing a game of 52-pickup * 1000.

> So Fortran programmers would be right at home!

:)
--
Geoff
From: viper-2
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <4a94b236-9100-46c6-841c-a9af414635d6@i7g2000prf.googlegroups.com>
On Jan 18, 12:33 am, Sohail Somani <······@taggedtype.net> wrote:
> On Fri, 18 Jan 2008 03:24:18 +0000, tim Josling wrote:
> > Yes, and I don't want code to be as hard to read as math texts or
> > papers. One-character variable names, etc...
>
> Fortran code is full of one character variable names. One time I was
> reading some code and was convinced it was computer generated as there
> was no way a human could follow that. I asked around and sure enough, it
> was hand written.
>
> So Fortran programmers would be right at home!
>
> --
> Sohail Somanihttp://uint32t.blogspot.com


I don't think that FORTRAN is unreadable. It's just that we have
become so inured to Lisp's ability to be self-documenting that we have
lost patience with perceived "lesser" languages. :-)

Here are a couple of simple FORTRAN subroutines (included here not for
the code value but in reference to the readability issue) from my 1983
Engineering Honours thesis "Interactive Computer Package
Demonstrating: Sampling Convolution and the FFT":

	SUBROUTINE AFUN(F1,F2,K,AT)
	COMMON NB,NP,T,M,P,TL,Y
	DIMENSION F(1024), F1(1024), F2(1024), AT(1024)
	CHARACTER*24 TP,A
4	IF (K.EQ.1) TP="TIME FUNCTION"
	IF (K.EQ.2) TP="TIME FUNCTION1"
2	CALL GETPRM(TP,A,R)
	IF(A.EQ."J") 	CALL SI(NB,Y,T,F,AT,£1)
	IF(A.EQ."K") 	CALL CO(NB,Y,T,F,AT,£1)
	IF(A.EQ."L") 	CALL TRI(NB,NP,T,P,F,AT,M,TL,£1)
	IF(A.EQ."M") 	CALL RECT(NB,NP,T,P,F,AT,M,TL,£1)
	IF(A.EQ."N") 	CALL EXPO(NB,T,F,AT,£1)
	IF(A.EQ."O") 	CALL STEP(0,NB,T,F,AT,£1)
	IF(A.EQ."P") 	CALL RAMP(NB,T,F,AT,£1)
	PRINT,"ERROR!!CODE NOT IN EXPECTED RANGE. TRY AGAIN."
	IF (K.LE.2)	GOTO 4
	IF (K.LE.3)	GOTO 5
1	CONTINUE
	DO 10 I = 1,NB
	IF (K.LE.2)	F1(I)=F(I)
		IF (K.LE.2)		PRINT,F1(I)
	IF (K.EQ.3)	F2(I)=F(I)
		IF (K.EQ.3)		PRINT,F2(I)
10	CONTINUE
	K=K+1
	IF (K.EQ.2)	GOTO 3
	IF (K.EQ.3)	GOTO 5
	IF (K.EQ.4)	GOTO 3
5	TP="TIME FUNCTION2"
	GOTO 2
3	DO 6 I = 1,NB
6	CONTINUE
	RETURN
	END



	SUBROUTINE SI(NB,Y,T,F,AT,*)
	DIMENSION F(1024), AT(1024)
	DO 10 I = 1,NB
	J=I-1
	F(I)=(SIN(Y*J*T))
	AT(I)=J*T
10	CONTINUE
	RETURN1
	END


There seemed to have been no problem with reading the code. In fact,
it was so well read that the "University "in question excluded my
thesis from my academic record, used it to give someone else a PhD,
and apparently exploited my program for commercial use in Europe's
North Sea oil industry. The doctoral award was rescinded only in 2003
in consequence of my submission of evidence of authorship and repeated
demands since my discovery of the fraud in 1996.

In the package, which comprised a main program and 21 subroutines, I
used the Fast Fourier Transform (FFT) to demonstrate the convolution
of signals, which I generated from library functions (e.g. "sin x" as
above) and by subroutines that I authored to generate periodic
triangular, rectangular, and other signals. I also coded a pair of
subroutines to graph the convolution of signals of finite length,
since the project was intended for use as a teaching aid in
communications theory.

I plan, in the near future, to implement features from computer vision
using Lisp interfaced with C or FORTRAN to do the actual number
crunching because of considerations of speed. Naturally, I've been
wondering what offerings Fortress will bring to the table since I have
the (possibly misguided) impression that with the advent of C, people
use FORTRAN mainly because of the huge code bases of that language
already in existence.

The FORTRAN FAQ:

http://www.faqs.org/faqs/fortran-faq/

suggests that the FORTRAN v C debate is aimless, but is it really -
especially with Fortress in sight?

agt
From: John Thingstad
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <op.t4455butut4oq5@pandora.alfanett.no>
P� Fri, 18 Jan 2008 19:28:39 +0100, skrev viper-2  
<········@mail.infochan.com>:

Ugh..
This code looks like it's from the 60's. You know of Fortran77 and beyond?

> Naturally, I've been
> wondering what offerings Fortress will bring to the table since I have
> the (possibly misguided) impression that with the advent of C, people
> use FORTRAN mainly because of the huge code bases of that language
> already in existence.

Not entirely because of the code base. FORTRAN is faster for numerical  
computation on most architectures.
C is optimized for integer computing. All float libraries are of type  
double. This means that if you only need float precision you have to  
convert to double and then back to float. Thus you miss out on the numeric  
processors ability to run small floats in parallel. This can give 30% or  
so speed increase. In general numeric operations are more optimized in  
FORTRAN.

--------------
John Thingstad
From: viper-2
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <21c0b1e3-c56a-44a1-a3a0-6782bef3e781@s8g2000prg.googlegroups.com>
On Jan 18, 3:06 pm, "John Thingstad" <·······@online.no> wrote:
> På Fri, 18 Jan 2008 19:28:39 +0100, skrev viper-2
> <········@mail.infochan.com>:
>
> Ugh..
> This code looks like it's from the 60's. You know of Fortran77 and beyond?

John, this should have been FORTRAN 77.


> Not entirely because of the code base. FORTRAN is faster for numerical
> computation on most architectures.
> C is optimized for integer computing.

Thanks, I'll be looking into the problem of speed - and deciding on
the best approach.

agt
From: tim Josling
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <13p2ntnmapvlm77@corp.supernews.com>
On Fri, 18 Jan 2008 15:56:59 -0800, viper-2 wrote:

> On Jan 18, 3:06 pm, "John Thingstad" <·······@online.no> wrote:
>> På Fri, 18 Jan 2008 19:28:39 +0100, skrev viper-2
>> <········@mail.infochan.com>:
>>
>> Ugh..
>> This code looks like it's from the 60's. You know of Fortran77 and beyond?
> 
> John, this should have been FORTRAN 77.
> 
> 
>> Not entirely because of the code base. FORTRAN is faster for numerical
>> computation on most architectures.
>> C is optimized for integer computing.
> 
> Thanks, I'll be looking into the problem of speed - and deciding on
> the best approach.
> 
> agt

Apart from the issue with double/single precision that were mentioned,
Fortran has assumptions about aliasing that allow for more aggressive
optimization than C is allowed to do. I think C90 has some declarations
that allow the programmer to declare that certain things are not aliases
of each other, but by default the compiler still has to assume that
different parameters to a subroutine may be aliases, which slows things
down a lot.

Tim Josling
From: jimka
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <3c615dd5-ab2a-4699-9d51-7055f0b8839d@i12g2000prf.googlegroups.com>
Another interesting concept seems to be the idea of precedence rules.
As I understand, this is in-the-end left up to the library
implementor,
not as part of the language.  When you define a new operator or
overload an existing one, you can set the precedence to other
operators.   He said this is possible, but won't be the
convention.  It is SUGGESTED that you only use precedence rules
which already exists in tradition.   (indeed curious whether
programmers will obey that guideline)

But there are two new concepts.
1. Precedence rules ARE NOT transative.
If you overload / * and + with / higher than *
and * higher than +, that does not make / automatically
higher than +.

2. The other concept is that not all precedence rules are defined.
Ones that are not explicitly defined are ambiguous and the
compiler will refuse to compile it until you insert the
correct parentheses.
From: Tamas
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <268fa3df-16a8-44c9-a4c2-c47e398d0e63@s12g2000prg.googlegroups.com>
On Jan 19, 5:24 am, jimka <·····@rdrop.com> wrote:
> Another interesting concept seems to be the idea of precedence rules.
> As I understand, this is in-the-end left up to the library
> implementor,
> not as part of the language.  When you define a new operator or
> overload an existing one, you can set the precedence to other
> operators.   He said this is possible, but won't be the
> convention.  It is SUGGESTED that you only use precedence rules
> which already exists in tradition.   (indeed curious whether
> programmers will obey that guideline)
>
> But there are two new concepts.
> 1. Precedence rules ARE NOT transative.
> If you overload / * and + with / higher than *
> and * higher than +, that does not make / automatically
> higher than +.

Looks like debugging errors resulting from precedence rules will
provide hours of good, clean fun for Fortress users.  Unicode makes it
even better, as there are more symbols in it.

Tamas
From: viper-2
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <634fb7d2-32ff-43c2-9c1e-7a95f5277c84@e6g2000prf.googlegroups.com>
On Jan 18, 6:56 pm, viper-2 <········@mail.infochan.com> wrote:
> On Jan 18, 3:06 pm, "John Thingstad" <·······@online.no> wrote:


> > Ugh..
> > This code looks like it's from the 60's. You know of Fortran77 and beyond?
>
> John, this should have been FORTRAN 77.

I should have added that while I have a habit of teaching myself
(sometimes from ancient books :-)) the character data type used in the
third line of subroutine AFUN:

CHARACTER*24 TP,A

was introduced by FORTRAN 77.

This was a tip I picked up, right at the beginning, from the
University's GinoGraf expert that was invaluable for building the
program's interactivity. Thanks again Jim Mitchell!!

agt
From: John Thingstad
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <op.t46lafxtut4oq5@pandora.alfanett.no>
P� Sat, 19 Jan 2008 14:18:17 +0100, skrev viper-2  
<········@mail.infochan.com>:

> On Jan 18, 6:56 pm, viper-2 <········@mail.infochan.com> wrote:
>> On Jan 18, 3:06 pm, "John Thingstad" <·······@online.no> wrote:
>
>
>> > Ugh..
>> > This code looks like it's from the 60's. You know of Fortran77 and  
>> beyond?
>>
>> John, this should have been FORTRAN 77.
>
> I should have added that while I have a habit of teaching myself
> (sometimes from ancient books :-)) the character data type used in the
> third line of subroutine AFUN:
>
> CHARACTER*24 TP,A
>
> was introduced by FORTRAN 77.
>
> This was a tip I picked up, right at the beginning, from the
> University's GinoGraf expert that was invaluable for building the
> program's interactivity. Thanks again Jim Mitchell!!
>
> agt
>
>

You are probibly right.

Take a look at these coding exaples to see how FORTRAN has evolved to it's  
current form
Fortran 2003.

http://en.wikibooks.org/wiki/Fortran/Fortran_examples


--------------
John Thingstad
From: jimka
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <d701de0d-6dde-4e32-9283-02cecbf5de43@m34g2000hsb.googlegroups.com>
> Yes, and I don't want code to be as hard to read as math texts or papers.
> One-character variable names, etc...
>

it seems like from the video that the goal is not to let people
who don't know math all of a sudden be mathematicians.  But rather
let  mathematicians. and physicists  write programs without having
to be programmers.

in languages like lisp and fortran, single variable names cause
difficulty
because their only characteristic is their ascii code.  It seems like
Steele is saying that single character variable names which are
overloaded
with font, size, position (superscription/subscription) and chosen for
a
very large alphabet can actually be more meaningful.

I saw a video where sussman uses the lambda character in his lectures
because
he thought it was more descriptive than writing out LAMBDA every
time.  the symbol
for PI is actually more descriptive that the word "PI" and a italics e
with an
x superscript is more convincing as an exponential then (exp x) or
exp(x)
From: jimka
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <f94cc64c-1a1f-4b05-8034-b45b9db1c31b@d70g2000hsb.googlegroups.com>
> About math: mathematical notation is great, but most of it is ad hoc
> and context-dependent (compare the role of the superscripts in
> \sin^2(x)+\cos^2(x)=1 and \cos^{-1}(x)), that is one reason it is so
> useful: you can write it quickly, and the context is usually obvious
> for humans who understand the semantics behind the syntax.  But for
> programming, math notation becomes a nightmare.
>
> Tamas


I don't think that is the claim he is making... infact just the
opposite.
He says using characters like \sin^2(x)+\cos^2(x)=1 and \cos^{-1}(x))
to represent math is something we got from fortran because it was done
on a limited keyboard of 100 keys or so. from fortran we got the idea
that math should be representable in ascii characters, whereas 500
years of mathematics tradition leads us nowhere near that conclusion.

mathematicians and physicists invent new notation all the time because
it
makes their work easier and clearer.
From: Alex Mizrahi
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <4790ca3f$0$90272$14726298@news.sunsite.dk>
 T> But that misses the point: very few people use Fortan because they
 T> love it so much, they use it because a lot of (legacy) code and
 T> reasonably good compilers are available, and it is the status quo anyway
 T> in some communities.

you have something wrong with your logic.

yes, people HAVE to use FORTRAN because they cannot find language to replace 
it.
but FORTRAN is UGLY.

what should we do? make something that can replace FORTRAN and is less ugly.
seems logical, right?

as for me, i've found Fortress exciting, both syntax and features.

i'm only afraid they won't be able to make a good implementation for it, as 
it appears to be quite complex.. 
From: David Golden
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <Nl9kj.24200$j7.448748@news.indigo.ie>
Alex Mizrahi wrote:

> yes, people HAVE to use FORTRAN because they cannot find language to
> replace it.
> but FORTRAN is UGLY.

Well. It's not the prettiest ever, but do bear in mind that, somewhat
like Lisp vs. LISP of yore, Fortran itself has moved on a bit from the
days of FORTRAN 77. 
From: Pascal Costanza
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <5vbl8sF1m06p3U1@mid.individual.net>
Madhu wrote:
> With all due respect to GLS (and lots due!), I believe his position is
> one of lending credibility to the committees he sits on, based on the
> authority from earlier original work.

I briefly talked to Guy Steele about Fortress at last year's OOPSLA. He 
is definitely convinced that it's a good thing, it's not just politics.

(He was also open in the past about his involvement with Java, which 
apparently was indeed more just a 'job', and not so much a passion.)


Pascal

-- 
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/

My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Alex Mizrahi
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <4790dd1a$0$90269$14726298@news.sunsite.dk>
 M> But he isn't a Language Designer in the sense of Guido, or Stroustup, or
 M> those single implementation languages, whose slice of the market pie Sun
 M> was so keen to bite into :)

let's take another example of great Language Designer who have made the most 
popular language for internets:

----
PHP was written as a set of Common Gateway Interface (CGI) binaries in the C 
programming language by the Danish/Greenlandic programmer Rasmus Lerdorf in 
1994, to replace a small set of Perl scripts he had been using to maintain 
his personal homepage.[3] Lerdorf initially created PHP to display his 
r�sum� and to collect certain data, such as how much traffic his page was 
receiving. Personal Home Page Tools was publicly released on 8 June 1995 
after Lerdorf combined it with his own Form Interpreter to create PHP/FI 
(this release is considered PHP version 2).

Zeev Suraski and Andi Gutmans, two Israeli developers at the Technion IIT, 
rewrote the parser in 1997 and formed the base of PHP 3, changing the 
language's name to the recursive initialism PHP: Hypertext Preprocessor.
----

this guy knew absolutely nothing about language design. he have just hacked 
simpliest interpeter for a perl-like syntax.
semantics were simply shocking weird. 9 years and 4  major version after 
(each version introducing incompatible changes, of course), it still looks 
like an inconsistent and buggy bullshit.
but many people like it..

author's skills were not in effect here. the key to success of PHP was a 
large group of amateur wannabe web programmers who have found a use for a 
small and easy programming language that suited well their unsophisticated 
needs like forums and guestbooks. it's quite understandable that big 
companies and serious people were not addressing needs of this group.

but, you know, mathematicians is quite different group of people. they won't 
be satisfied with some amateurish constructs, and languages with one bright 
feature won't suit them.
programming language for mathematicians working with high performance 
computing should be carefully designed by experienced and sane people. 
From: Christopher Browne
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <60prw0p2gw.fsf@dba2.int.libertyrms.com>
···@informatimago.com (Pascal J. Bourguignon) writes:

> Frank Buss <··@frank-buss.de> writes:
>
>> Pertti Kellom�ki wrote:
>>
>>> Some of us are interested in what the author of "Common Lisp,
>>> the Language" is up to nowadays.
>>
>> Maybe he has learned something from the mistakes of the past and now
>> develops statically typed languages with type inference, like Haskell :-)
>
> Or maybe he just couldn't find a CL job, and is happy to have landed a
> job in the statically typed world, like most of us?  :-)

Um, the primary Steele book that I keep on my desk that gets leafed
thru more often than pretty well anything else is _C - A Reference
Manual_.  Extremely handy when looking for differences between
Unixes...

He is notable in history as a language designer, and has had
considerable involvement with *many* languages of different styles.
-- 
select 'cbbrowne' || ·@' || 'cbbrowne.com';
http://linuxdatabases.info/info/emacs.html
"The  problem might  possibly be  to do  with the  fact that  asm code
written for the x86 environment  is, on other platforms, about as much
use  as  a   pork  pie  at  a  Jewish   wedding."-  Andrew  Gierth  in
comp.unix.programmer
From: Sohail Somani
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <g8Pjj.6157$vp3.2000@edtnps90>
On Thu, 17 Jan 2008 04:49:17 -0800, KT wrote:

> I figured that many of you might be interested
> 
> Video of Steele talking at JAOO and slides.
> 
> http://www.infoq.com/presentations/fortress-steele

Interesting video, thanks for posting it! I imagine he is trying not to 
say "just like Common Lisp."

-- 
Sohail Somani
http://uint32t.blogspot.com
From: Sohail Somani
Subject: Re: Steele: Fortress - programming for supercomputers
Date: 
Message-ID: <G9Pjj.6158$vp3.2830@edtnps90>
On Thu, 17 Jan 2008 04:49:17 -0800, KT wrote:

> I figured that many of you might be interested
> 
> Video of Steele talking at JAOO and slides.
> 
> http://www.infoq.com/presentations/fortress-steele

I just noticed that he said "C standard library" when referring to the C+
+ standard library. Maybe he thinks C = C++.

-- 
Sohail Somani
http://uint32t.blogspot.com