Scheme is dead, right?
AntonioV
So after the failure of the Scheme WG1 to produce a report within
(more than) a year, and since there has been little activity on the
last months on their public mailing lists I assume we can now say that
Scheme is officially dead, right?
Thanks,
Antonio
Nils M Holm
If so, it's a good thing! FORTH died when it became ANS Forth.
Maybe Scheme can live when The Standard dies. Choose your
implementation and be happy!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
May all beings be happy, peaceful, and free from suffering!
pmarin
Think about C, the current standard is C99 and many people still
prefer C89 for compatibility purpose. C is still the most used
language for system programming tasks like OS or embedded programming
and I don't hear any C programmer crying for a new C standard.
WJ
> AntonioV <antonio...@gmail.com> wrote:
> > So after the failure of the Scheme WG1 to produce a report within
> > (more than) a year, and since there has been little activity on the
> > last months on their public mailing lists I assume we can now say that
> > Scheme is officially dead, right?
>
> If so, it's a good thing! FORTH died when it became ANS Forth.
> Maybe Scheme can live when The Standard dies. Choose your
> implementation and be happy!
I tend to agree with you about ANS Forth.
As for Scheme, for too long the standard was too minimalist.
There wasn't even a function to read a line from a file!
("Write it yourself," they said.) I understand that R6RS
has "get-line". Finally!
And look at all of the SRFI's that seemed to be necessary.
Without SRFI-1, you would have almost no list processing
functions.
Here are some commands from Common Lisp that Scheme should have:
when
incf
push
pushnew
rotatef
dotimes
dolist
destructuring-bind
1+
1-
William D Clinger
You may say whatever you like, but your suggested
conclusion would be premature.
Will
Pascal J. Bourguignon
If that's so, you're all welcomed on comp.lang.lisp.
We promise not to try to make a new Common Lisp standard for at least
ten years.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
William D Clinger
in recent months may want to browse the following web pages:
http://www.scheme-reports.org/
http://www.scheme-reports.org/2010/working-group-1.html
http://trac.sacrideo.us/wg/wiki
http://trac.sacrideo.us/wg/wiki/WG1Ballot2Results
Will
Alex Shinn
The list has been especially silent the last month
because we've been busy editing - there's been a
flurry of activity in the hg repo the past few weeks.
There was an announced one month delay on the first draft,
which looks like it will be delayed another couple of
weeks in no small part to the chair of WG1 having been
caught in the middle of a magnitude 9 earthquake.
--
Alex
AntonioV
D'oh! Too bad! I hope everybody is well!
So if I understand correctly the draft is expected in one and a half/
two months from now?
Kind regards,
Antonio
Alex Shinn
>
> So if I understand correctly the draft is expected in one and a half/
> two months from now?
The one month extension was from the original February 9th
deadline. We're hoping to have the draft out by the end of
this month, and are looking forward to feedback from the
community.
The final draft is still scheduled for September 9th.
--
Alex
Andrew Reilly
> Think about C, the current standard is C99 and many people still prefer
> C89 for compatibility purpose.
C89 is a fairly decent standard, and C99 was adventurous in a couple of
useful but perhaps difficult directions, but the big issue is the sole
elephant in the room that seems to have an "over our dead body" approach
to C99 support (or lack thereof). To be more specific, any C99 feature
that isn't also in C++ is probably dubious for portability, becuase some
suppliers seem to be treating C++ as "the standard", and C as "legacy
support". Things may change if there is ever another C++ standard
released.
> C is still the most used language for
> system programming tasks like OS or embedded programming and I don't
> hear any C programmer crying for a new C standard.
C's model of computation might be just a smidgen too restrictive
(unnecessarily prescriptive and static, in some respects), but it has the
overwhelming advantage of being semantically direct to translate to
almost every processor currently in production. I can't think of any
other language that can claim that. It is a useful property.
Not the only useful property, of course, which is why languages like
scheme still have their niche.
IMO, as a heavy user of C for embedded programming tasks and a sometime
user and enthusiast of scheme...
Cheers,
--
Andrew
Raffael Cavallaro
> Here are some commands from Common Lisp that Scheme should have:
>
> when
> incf
> push
> pushnew
> rotatef
> dotimes
> dolist
> destructuring-bind
> 1+
> 1-
Sign of the Apocalypse! wax man has actually *praised* common lisp!
warmest regards,
Ralph
--
Raffael Cavallaro
kodifik
> > Here are some commands from Common Lisp that Scheme should have:
.
.
> > 1+
> > 1-
Beware (1- x) in Common Lisp means (x-1)
Scheme does have the equivalent "-1+" which besides is much clearer as
notation.
ok
<raffaelcavall...@pas.despam.s.il.vous.plait.mac.com> wrote:
> Sign of the Apocalypse! wax man has actually *praised* common lisp!
Scheme is better than Common Lisp.
And Common Lisp is better than Scheme.
Both of the above is true.
It's only our stupid mind which doesn't get it: we decide in our soul
(remember: we have free will), and not in our brain.
If it would be a decision of our brain, then there would obviously be
a *right* and a *wrong* answer, which could logically/mathematically
be explained.
But this isn't how humans "work"...
P.S. Yes I know that you knew this already; it's meant as
"pontification" to the ignorant...
Mario S. Mommer
kodifik <kod...@eurogaran.com> writes:
>> > Here are some commands from Common Lisp that Scheme should have:
>> > 1-
>
> Beware (1- x) in Common Lisp means (x-1)
> Scheme does have the equivalent "-1+" which besides is much clearer as
> notation.
Heh. Well, obviously it would have been better to call it "+-1". No? I
mean, prefix and stuff...
kodifik
> kodifik <kodi...@eurogaran.com> writes:
> > Beware (1- x) in Common Lisp means (x-1)
> > Scheme does have the equivalent "-1+" which besides is much clearer as
> > notation.
>
> Heh. Well, obviously it would have been better to call it "+-1". No? I
> mean, prefix and stuff...
Yeah. Unfortunately, +- is frequently used for other purposes:
1) Error margin.
2) Square root. (if a=x^2 then x= +-Va)
Pascal J. Bourguignon
Tamas K Papp
I am still looking for a good name for (- 1 x), an operation I end up
using quite frequently. Currently I am using (1m x), but it does not
look that great.
Tamas
Benny Tsai
(inc x) = (+ x 1)
(dec x) = (- x 1)
namekuseijin
> > > Here are some commands from Common Lisp that Scheme should have:
>
> .
> .
> .
>
> > > 1+
> > > 1-
>
> Beware (1- x) in Common Lisp means (x-1)
it's obvious, since it's common in prefixed syntax.
> Scheme does have the equivalent "-1+" which besides is much clearer as
> notation.
never knew that. Sounds bogus, since writing (- x 1) is same size and
clearer than writing (-1+ x)...
namekuseijin
Pascal J. Bourguignon
And both would generate exactly the same code (as (1- x) and (- x 1)
do), but 1- is still useful because it can be used with mapcar without
currying.
Paul Rubin
> I am still looking for a good name for (- 1 x), an operation I end up
> using quite frequently. Currently I am using (1m x), but it does not
> look that great.
Haskell uses succ (successor) and pred (predecessor):
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Prelude> succ 4
5
Prelude> pred 8
7
Rob Warnock
+---------------
| I am still looking for a good name for (- 1 x), an operation I end up
| using quite frequently. Currently I am using (1m x), but it does not
| look that great.
Well, I doubt you're going to get any better. Anything that adds
more meaning is probably going to be more than the two characters
of "1m", and the full CL "- 1" is already only three characters!! ;-}
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403
Robert Maas, http://tinyurl.com/uh3t
> > Scheme does have the equivalent "-1+" which besides is much clearer as
> > notation.
> Heh. Well, <C2> obviously<C2> it would have been better to call
> it "+-1". No? I mean, prefix and stuff...
It would be better if nobody ever used *any* of those functions.
Instead, do as I do: (+ -1 x)
In addition to the clarity of the math, it makes it easier to
change it to (+ -2 x) or (+ -3 x) etc. as needed when tuning an algorithm.
Note: Usually 'x' in this template is really a complicated
expression such as (length pathloc) where putting the compact
negative addend first is advantageous. I.e. this:
(+ 1 (nth (+ -3 (length pathloc)) pathloc))
is easier for humans to understand at a glance than this:
(+ (nth (+ (length pathloc) -3) pathloc) 1)
If it were really literally 'x', a simple one-character variable,
I might write instead (+ x -1).
Robert Maas, http://tinyurl.com/uh3t
> 1- is still useful because it can be used with mapcar without currying.
Agreed. But this may be a strawman to the original gripe because whereas
(-1 x) looks to the eye like it means something other than x-1,
(mapcar #'-1 listofxs) doesn't quite have the same eye-misleadingness,
so in that case the pre-defined function has better cost/benefit ratio,
so I suppose I might use it in that case.
Hmm, one disadvantage of currying like this:
(mapcar #'(lambda (x) (- x 1)) listofxs)
is that it introduces a single-use local parameter 'x', forcing the
human reader to visually make sure that the lambda variable 'x'
matches the reference 'x' in the body of the anonymous function, to
avoid mistakes like changing one of the instances but not the
other, thereby breaking the link between parameter and reference,
like this:
(mapcar #'(lambda (x) (- oneindex 1)) goodindexes)
which is obviously wrong, should read:
(mapcar #'(lambda (oneindex) (- oneindex 1)) goodindexes)
On the other hand, explicitly naming the lambda variable of the
anonymous function sometimes helps the code be self-documentating.
So it's a trade-off whether to introduce use-once variables or not.
IMO the programmer should feel free to do it any way he/she feels
at the moment the code is being written, including this way:
(loop for oneindex in goodindexes collect (- oneindex 1))
or this way:
(loop for oneindex in goodindexes collect (+ -1 oneindex))
In cases where I really do need to curry, I like the syntax of the
loop macro better than mapcar with lambda expression, but like I
said that's the personal preference and state-of-mind of the person
writing the code.
BTW, if any Forth programmers are reading this thread:
x -1
isn't misleading as to what gets subtracted from what.
OTOH
x 1 -
is ambiguous (to the human) unless he/she has memorized which way it works.
Personally I would write:
x -1 +
Now if we programmed graphically, like this:
x -1
\ /
+
or even like this:
x 1
\ /
\ -
\ /
+
instead by strings of text-syntax, we'd all be happier.
pjotr
> C's model of computation might be just a smidgen too restrictive
> (unnecessarily prescriptive and static, in some respects), but it has the
> overwhelming advantage of being semantically direct to translate to
> almost every processor currently in production.
Sorry for being obvious, but this statement, while being quite true until mid
90s or so, is simply incorrect with the advent of superscalar (late 90s) and
multi-core. By now, ISO/ANSI C is semantically direct to translate only to a tiny fraction of almost every processor currently in production!
Andrew Reilly
No, C is deliberately vague with respect to the order of operations,
which is good enough for OOO, but relatively precise with respect to
memory access and placement and operator behaviour. (Signed arithmetic
gets a bit vague for my taste, but it's good enough to be useful most of
the time.) So long as your C isn't doing threads (which C doesn't say
anything useful about anyway) the model is still a good fit to the
hardware.
The main thing that current processors can do that C is not especially
helpful with are the various flavours of vector operation (and their
necessary alignment), but that's sort of an orthogonal issue.
Cheers,
--
Andrew
pjotr
> which is good enough for OOO, but relatively precise with respect to
> memory access and placement and operator behaviour. (Signed arithmetic
> gets a bit vague for my taste, but it's good enough to be useful most of
> the time.)
OOO, being a transparent generalization (unlike vectors & threads), I grant,
is something that still does match original C semantics. However, a simple
investigation into a large application written in C and targeted at most
current processors (Linux kernel) reveals that C alone is insufficient there.
> So long as your C isn't doing threads (which C doesn't say
> anything useful about anyway) the model is still a good fit to the
> hardware.
To a very small fraction of hardware: a single RISC core (my guesstimate that this by now is <10% of the chip). As soon as you take multiple cores/processors with corresponding cache/interconnect in consideration, the model becomes insufficient. Even more so for GPUs, where supposedly portable C in intermixed with loads of memory management crud.
> The main thing that current processors can do that C is not especially
> helpful with are the various flavours of vector operation (and their
> necessary alignment), but that's sort of an orthogonal issue.
Here though, automated vectorization has been quite successful, but is not a panacea. I think the world is still waiting, after all those years, for a automated parallelization/vectorization solution...
Returning back to original discussion, I think that conservative stand that C took is no longer helping: all the C programmers should be crying for replacement of all those OpenWhatNot libraries by a new version of the C standard.