[Lisp] Hej

[Sunnan]

Jag hänger i vanliga fall i nyhetsgruppen c.l.scheme, men nyligen var
det en lång off-topic-diskussion som dessutom crosspostades till c.l.lisp.

Då fick jag ett brev som tipsade mig om den här listan.

För något år sedan (ett och ett halvt, kanske?) hängde jag i både cls
och cll, men så slutade jag programmera och då orkade jag inte hänga i
nyhetsgrupperna heller.

När jag började igen började jag bara att hänga i cls, eftersom många i
cll var så rabiata och ilskna, och envisades med att den nyhetsgruppen
bara var till för CL, inte för andra lispar.

Jag använder CL ibland och tycker att många implementationer verkar
ganska robusta, med en bra REPL där man kan inspect:a och sånt, det
verkar bra. Men jag tycker mer om scheme och använder det mycket oftare.

[Lars Brinkhoff]

Sunnan skrev:
> För något år sedan (ett och ett halvt, kanske?) hängde jag i både cls
> och cll, men så slutade jag programmera och då orkade jag inte hänga i
> nyhetsgrupperna heller.

Välkommen! Jag har fått ett intryck av att CL är mest populärt på
denna listan, men jag tror att både CL:arse och Schemare kan samsas
här.

[Något helt annat: Fick "Practical Common Lisp" i brevlådan i fredags.
Kanske första exemplaret i Sverige?]

[Sunnan]

Lars Brinkhoff wrote:

>Sunnan skrev:
>
>
>>För något år sedan (ett och ett halvt, kanske?) hängde jag i både cls
>>och cll, men så slutade jag programmera och då orkade jag inte hänga i
>>nyhetsgrupperna heller.
>>
>>
>
>Välkommen! Jag har fått ett intryck av att CL är mest populärt på
>denna listan, men jag tror att både CL:arse och Schemare kan samsas
>här.
>
>
>
Jag läste lite i arkivet och såg att en gammal nätbekant, Björn, som jag
har tappat kontakt med hänger här. DKJA.

>[Något helt annat: Fick "Practical Common Lisp" i brevlådan i fredags.
>Kanske första exemplaret i Sverige?]
>
>
Obs, obs: Den finns även på nätet, som man kan läsa medan man väntar på
att den ska komma.

Obs, obs, pt. 2; Jag har en fråga om LOOP.
Kan man, med en enda loop, uttrycka nästlade loopar eller bara parallella?

T.ex. med srfi-42 kan man göra:
(list-ec (: i 7) (: j 3) (list i j)) =>
((0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2) (3 0) (3 1) (3 2)
(4 0) (4 1) (4 2) (5 0) (5 1) (5 2) (6 0) (6 1) (6 2))

Hur skulle man uttrycka detta med LOOP, om det går?
I regel föredrar jag srfi-42 över LOOP (när man inte använder tail calls
eller do-varianter), men "it's standing on the shoulders of giants" -
srfi-42 är ju ganska mycket yngre än LOOP.

[Ingvar]

Sunnan skriver:
> Lars Brinkhoff wrote:
>
> >Sunnan skrev:
> >
> >
> >>För något år sedan (ett och ett halvt, kanske?) hängde jag i både cls
> >>och cll, men så slutade jag programmera och då orkade jag inte hänga i
> >>nyhetsgrupperna heller.
> >>
> >>
> >
> >Välkommen! Jag har fått ett intryck av att CL är mest populärt på
> >denna listan, men jag tror att både CL:arse och Schemare kan samsas
> >här.
> >
> >
> >
> Jag läste lite i arkivet och såg att en gammal nätbekant, Björn, som jag
> har tappat kontakt med hänger här. DKJA.
>
> >[Något helt annat: Fick "Practical Common Lisp" i brevlådan i fredags.
> >Kanske första exemplaret i Sverige?]
> >
> >
> Obs, obs: Den finns även på nätet, som man kan läsa medan man väntar på
> att den ska komma.

Jupps, jag har till och med korrläst och fått svar tillbaka.

> Obs, obs, pt. 2; Jag har en fråga om LOOP.
> Kan man, med en enda loop, uttrycka nästlade loopar eller bara parallella?

"Mnja..." :) Oftast vill man nog nästla sina loop-uttryck, så att
loopar-i-loopar syns enkelt i koden.

> T.ex. med srfi-42 kan man göra:
> (list-ec (: i 7) (: j 3) (list i j)) =>
> ((0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2) (3 0) (3 1) (3 2)
> (4 0) (4 1) (4 2) (5 0) (5 1) (5 2) (6 0) (6 1) (6 2))
>
> Hur skulle man uttrycka detta med LOOP, om det går?
> I regel föredrar jag srfi-42 över LOOP (när man inte använder tail calls
> eller do-varianter), men "it's standing on the shoulders of giants" -
> srfi-42 är ju ganska mycket yngre än LOOP.

Absolut enklast med nästlade LOOP-uttryck:
(loop for i below 7
append (loop for j below 3
collect (list i j)))

((0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2) (3 0) (3 1) (3 2) (4 0)
(4 1) (4 2) (5 0) (5 1) (5 2) (6 0) (6 1) (6 2))

Man kan, antagligen, bygga det i en enda loop, men det riskerar att bli
*tokfult*, så man slipper nog helst.

Den "naiva" översättningen:
(loop for i below 7
for j below 3
collect (list i j))
ger
((0 0) (1 1) (2 2))

[ dvs, om minst ett av loop-uttrycken indikerar terminering så terminerar
loopen ]

Man kan (ibland) få rätt bra resultat med en av de andra
accumuleringsmetoderna (MAX, SUM, MIN), så att allt ser hyfsat lättläst ut.

//Ingvar

[Martin ``rydis'' Rydstr|m]

On Sun, Apr 24, 2005 at 05:06:46PM +0100, Ingvar wrote:
> Sunnan skriver:
> > Lars Brinkhoff wrote:
> >
> > >Sunnan skrev:
> > >
> > >
> > >>För något år sedan (ett och ett halvt, kanske?) hängde jag i både cls
> > >>och cll, men så slutade jag programmera och då orkade jag inte hänga i
> > >>nyhetsgrupperna heller.
> > >>
> > >>
> > >
> > >Välkommen! Jag har fått ett intryck av att CL är mest populärt på
> > >denna listan, men jag tror att både CL:arse och Schemare kan samsas
> > >här.
> > >
> > >
> > >
> > Jag läste lite i arkivet och såg att en gammal nätbekant, Björn, som jag
> > har tappat kontakt med hänger här. DKJA.
> >
> > >[Något helt annat: Fick "Practical Common Lisp" i brevlådan i fredags.
> > >Kanske första exemplaret i Sverige?]
> > >
> > >
> > Obs, obs: Den finns även på nätet, som man kan läsa medan man väntar på
> > att den ska komma.
>
> Jupps, jag har till och med korrläst och fått svar tillbaka.
>
> > Obs, obs, pt. 2; Jag har en fråga om LOOP.
> > Kan man, med en enda loop, uttrycka nästlade loopar eller bara parallella?
>
> "Mnja..." :) Oftast vill man nog nästla sina loop-uttryck, så att
> loopar-i-loopar syns enkelt i koden.
>
> > T.ex. med srfi-42 kan man göra:
> > (list-ec (: i 7) (: j 3) (list i j)) =>
> > ((0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2) (3 0) (3 1) (3 2)
> > (4 0) (4 1) (4 2) (5 0) (5 1) (5 2) (6 0) (6 1) (6 2))
> >
> > Hur skulle man uttrycka detta med LOOP, om det går?
> > I regel föredrar jag srfi-42 över LOOP (när man inte använder tail calls
> > eller do-varianter), men "it's standing on the shoulders of giants" -
> > srfi-42 är ju ganska mycket yngre än LOOP.
>
> Absolut enklast med nästlade LOOP-uttryck:
> (loop for i below 7
> append (loop for j below 3
> collect (list i j)))
>
> ((0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2) (3 0) (3 1) (3 2) (4 0)
> (4 1) (4 2) (5 0) (5 1) (5 2) (6 0) (6 1) (6 2))
>
> Man kan, antagligen, bygga det i en enda loop, men det riskerar att bli
> *tokfult*, så man slipper nog helst.

Mnja. Inte /tokfult/ men rätt mycket manuellt. (Det är mer en PROG än en LOOP,
egentligen. ;)

Jag håller med om att det blir snyggast och enklast med nästlade LOOP:ar.

(loop with i = 0 and j = 0 until (= i 7)
if (= (incf j) 3)
do (incf i)
(setf j 0)
collect (list i j))

> Den "naiva" översättningen:
> (loop for i below 7
> for j below 3
> collect (list i j))
> ger
> ((0 0) (1 1) (2 2))
>
> [ dvs, om minst ett av loop-uttrycken indikerar terminering så terminerar
> loopen ]
>
> Man kan (ibland) få rätt bra resultat med en av de andra
> accumuleringsmetoderna (MAX, SUM, MIN), så att allt ser hyfsat lättläst ut.

(sort (loop for i below (* 7 3)
collect (list (mod i 7) (mod i 3)))
#'< :key #'car)

... fast då sker saker i en annan ordning; huruvida det spelar roll är väl
olika.

Eventuellt letar Sunnan mer efter något i stil med ITERATE (eller
SERIES) än LOOP.

'mr

--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_

[Martin ``rydis'' Rydstr|m]

On Sun, Apr 24, 2005 at 06:37:03PM +0200, Martin ``rydis'' Rydstr|m wrote:
> Mnja. Inte /tokfult/ men rätt mycket manuellt. (Det är mer en PROG än en LOOP,
> egentligen. ;)
>
> Jag håller med om att det blir snyggast och enklast med nästlade LOOP:ar.
>
> (loop with i = 0 and j = 0 until (= i 7)
> if (= (incf j) 3)
> do (incf i)
> (setf j 0)
> collect (list i j))

Jag flyttade om utan att kolla så att resultatet blev detsamma. I
själva verket menade jag förstås

(loop with i = 0 and j = 0 until (= i 7)
collect (list i j)
if (= (incf j) 3)
do (incf i)
(setf j 0))

'mr

--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_

[Peter Lewerin]

>Man kan, antagligen, bygga det i en enda loop, men det riskerar att bli
>*tokfult*, så man slipper nog helst.

(do ((i 0)
(j 0)
(res ()))
((>= i 7) (nreverse res))
(if* (< j 3) then
(push (list i j) res)
(incf j)
else
(incf i)
(setf j 0)))

eller

(let (i j res)
(tagbody
(setf i 0 j 0)
loop
(when (>= j 3)
(go outer))
(push (list i j) res)
(incf j)
(go loop)
outer
(when (>= i 7)
(go end))
(incf i)
(setf j 0)
(go loop)
end)
(nreverse res))

Jag överlåter åt läsaren att avgöra om dessa båda exempel motsäger eller
bekräftar Ingvars antagande... ;-)

[d***@nada.kth.se]

>
>>Man kan, antagligen, bygga det i en enda loop, men det riskerar att bli
>>*tokfult*, så man slipper nog helst.
>
> (do ((i 0)
> (j 0)
> (res ()))
> ((>= i 7) (nreverse res))
> (if* (< j 3) then
> (push (list i j) res)
> (incf j)
> else
> (incf i)
> (setf j 0)))

> Jag överlåter åt läsaren att avgöra om dessa båda exempel motsäger eller
> bekräftar Ingvars antagande... ;-)

Bekräftar -- men bara för att du använder if-stjärna.

:-)


Björn

[Peter Lewerin]

>Bekräftar -- men bara för att du använder if-stjärna.

Personligen gör jag nästan vad som helst för att slippa skriva PROGN i
publik kod. Oftast skriver jag om IF till COND isf, dock (detta var
faktiskt första gången jag använt IF*!) Jag tycker iaf att man kan påstå
att tillfället krävde det :-)

[d***@nada.kth.se]

>
>>Bekräftar -- men bara för att du använder if-stjärna.
>
> Personligen gör jag nästan vad som helst för att slippa skriva PROGN i
> publik kod. Oftast skriver jag om IF till COND isf, dock (detta var
> faktiskt första gången jag använt IF*!) Jag tycker iaf att man kan påstå
> att tillfället krävde det :-)

Jag tänkte förstås elda på litet i debatten, eftersom IF* ju är ett
kontroversiellt ämne. Förmodligen är lisp-se alldeles för snällt för att
det skall lyckas, dock. :-)

Jag håller med om att IF med PROGN är olämpligt. Bättre då att använda
COND i sådana fall.


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Jag tänkte förstås elda på litet i debatten, eftersom IF* ju är ett
>kontroversiellt ämne. Förmodligen är lisp-se alldeles för snällt för att
>det skall lyckas, dock. :-)
>
>Jag håller med om att IF med PROGN är olämpligt. Bättre då att använda
>COND i sådana fall.
>
>
Jag ser inte det olämpliga i IF* (även om keywordsen är en smell) eller
i PROGN. Berätta gärna.

Är inte PROGN ung. motsv. schemes begin?

Jag använder oftast if och begin om det är ett val mellan två saker,
cond om det är ett val mellan tre eller mer.

[d***@nada.kth.se]

> d95-***@nada.kth.se wrote:
>
>>Jag tänkte förstås elda på litet i debatten, eftersom IF* ju är ett
>>kontroversiellt ämne. Förmodligen är lisp-se alldeles för snällt för att
>>det skall lyckas, dock. :-)
>>
>>Jag håller med om att IF med PROGN är olämpligt. Bättre då att använda
>>COND i sådana fall.
>>
>>
> Jag ser inte det olämpliga i IF* (även om keywordsen är en smell) eller
> i PROGN. Berätta gärna.

Det var en stor kontrovers i c.l.l. kring IF*. Bakgrunden är att John
Foderaro på Franz skrev diverse öppen källkod-program, främst AllegroServe
för att (gissar jag) marknadsföra Allegro. Dessa var förvisso öppen
källkod, men intimt knutna till Allegroimplementationen, så de gick inte
att utan vidare använda på andra implementationer. Därför skrevs så
småningom ett kompatibilitetslager, men det är en annan histora. Nåväl,
John Foderaro råkar föredra IF* framför andra villkorsoperatorer, så detta
makro används genomgående i AllegroServekoden. Många tycker att det är
dumt att använda en icke-standardoperator, eftersom det gör koden mer
svårläst för utomstående. Framförallt som det skulle vara öppen källkod.
Själva kontroversen eskalerade nog framför allt för att John själv i ett
försök att försvara sig gjorde några ganska dumma inlägg.

(IF* kommer ursprungligen från en IF i vissa gamla lispar, bland annat
gamla Franz Lisp (före CLs tid). IF i CL kunde kommit att se ut på detta
sätt.)

Själv ställer jag mig utanför debatten, men konstaterar att jag ogillar IF*.

> Är inte PROGN ung. motsv. schemes begin?
>
> Jag använder oftast if och begin om det är ett val mellan två saker,
> cond om det är ett val mellan tre eller mer.

De flesta menar nog att det är mer idiomatiskt i CL att använda COND om
någon av villkorsgrenarna har flera formar, även om det bara finns två
alternativ. Alltså

(cond (test do-this do-that)
(t something-else))

föredras framför

(if test
(progn
do-this
do-that)
something-else)


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Det var en stor kontrovers i c.l.l. kring IF*.
>
Men hjälp, vad det ofta är kontroverser i denna stormiga nyhetsgrupp!
Jag läste just en entrevue med författaren till _Higher Order Perl_ som
hasplade ur sig att Lisp-användarskaran var "dysfunctional".

>De flesta menar nog att det är mer idiomatiskt i CL att använda COND om
>någon av villkorsgrenarna har flera formar, även om det bara finns två
>alternativ. Alltså
>
>
Jag tror att det gäller i Scheme-kretsar också; åtminstone av
litteraturen att döma. Där är det bara cond från morgon till kväll. Men
jag tycker om if, kanske på grund av dess likhet med Cs ternary conditional.

[d***@nada.kth.se]

> d95-***@nada.kth.se wrote:
>
>>Det var en stor kontrovers i c.l.l. kring IF*.
>>
> Men hjälp, vad det ofta är kontroverser i denna stormiga nyhetsgrupp!
> Jag läste just en entrevue med författaren till _Higher Order Perl_ som
> hasplade ur sig att Lisp-användarskaran var "dysfunctional".

Det kan han ju tycka. I själva verket är det Perl-skaran som är
dysfunktionell.


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Det kan han ju tycka. I själva verket är det Perl-skaran som är
>dysfunktionell.
>
>
Att perl i sig är dysfunktionellt är ju inte direkt en nyhet.
Lika så dessa suspekta hobbier som golfande och dylikt.

Men hur menar du att skaran är dysfunktionell? Jag har inte sett i
närheten av lika mycket kontroverser, gräl och politik hos perlfolk (men
jag har inte kollat lika mycket på perlkretsar som jag har på
lispkretsarna).

Perlskaran har i alla fall hasplat ur sig en fungerande CPAN och en
intressant språkdesignprocess för perl 6.
Hur har det gått med CLRFI och liknande grejer? (Läs inte "hur har det
gått, åt helvete inte sant?" utan läs "Hur har det gått, jag har inte
hängt med?")

[Arthur Lemmens]

> Hur har det gått med CLRFI

CLRFI was announced in September last year (by Nick Levine at a Lisp
meeting in Amsterdam). So far, nothing much seems to have happened.
But that's not surprising, because all obvious stuff is already in
ANSI CL, and all the non-obvious stuff (defsystem, multithreading, ...)
is very hard to get right. ("Right" meaning: good enough to reach
some kind of community consensus.)

Arthur

PS. Sorry for the English. I read Swedish, but don't write it well enough.

[Lars Brinkhoff]

Arthur Lemmens <***@xs4all.nl> writes:
> > Hur har det gått med CLRFI
> CLRFI was announced in September last year. So far, nothing much
> seems to have happened.

Tydligen har CLRFI-kommitten lite för ont om tid för att behandla
inkomna förslag:

http://groups.google.co.in/groups?selm=V0B2e.63$***@typhoon.nyu.edu

(Eller, med det nya (försämrade?) gränssnittet:
http://groups-beta.google.com/group/comp.lang.lisp/msg/11dd21b02cd561a4)

> But that's not surprising, because all obvious stuff is already in
> ANSI CL, and all the non-obvious stuff is very hard to get right.

Jag tror det finns några vanliga små hjälpmedel, t ex WITH-GENSYMS,
som skulle kunna gå att komma överens om.

[Arthur Lemmens]

Lars Brinkhoff wrote:

> Tydligen har CLRFI-kommitten lite för ont om tid för att behandla
> inkomna förslag:
>
> http://groups.google.co.in/groups?selm=V0B2e.63$***@typhoon.nyu.edu

Ah yes, I forgot that one. My impression is that they just need to be
prodded a bit to remind them of their existence. Swift communication
with 'the public' doesn't seem to be the strongest part of the ALU, and
maybe the CLRFI committee has the same problem.

> Jag tror det finns några vanliga små hjälpmedel, t ex WITH-GENSYMS,
> som skulle kunna gå att komma överens om.

Yeah, I agree with that. Some of the CLIKI utilities at
http://www.cliki.net/Common%20Lisp%20Utilities
might be good candidates for going through the CLRFI process.

If you really care about this kind of stuff (for me personally, it's not
important enough to spend much time on), you could try submitting a CLRFI
yourself. But my impression is that, if you want to do it right, it takes
more time than most Lispers are prepared to invest in something like this.

Arthur

[Lars Brinkhoff]

Arthur Lemmens <***@xs4all.nl> writes:
> Lars Brinkhoff wrote:
>> Tydligen har CLRFI-kommitten lite för ont om tid för att behandla
>> inkomna förslag:
>> http://groups.google.co.in/groups?selm=V0B2e.63$***@typhoon.nyu.edu
> Ah yes, I forgot that one. My impression is that they just need to be
> prodded a bit to remind them of their existence.

I så fall hoppas jag COMPILED-FILE-P-förslaget är under behandling.

>> Jag tror det finns några vanliga små hjälpmedel, t ex WITH-GENSYMS,
>> som skulle kunna gå att komma överens om.
> Yeah, I agree with that. Some of the CLIKI utilities at
> http://www.cliki.net/Common%20Lisp%20Utilities
> might be good candidates for going through the CLRFI process.

Ja, och om ingen annan gör det, kanske jag skickar in några av dem
till CLRFI.

> If you really care about this kind of stuff (for me personally, it's
> not important enough to spend much time on), you could try
> submitting a CLRFI yourself.

Jag kontaktade dem i slutet av förra året om WITH-GENSYMS, och de
verkade positivt inställda, men sedan dess har jag inte gjort något.
Med lite tur blir jag arbetslös på måndag, och då får jag tid över. :)

(Mitt förslag skulle nog bli som
http://www.cliki.net/WITH-UNIQUE-NAMES
fast omdöpt till WITH-GENSYMS.)

[Arthur Lemmens]

Lars Brinkhoff wrote:

> Ja, och om ingen annan gör det, kanske jag skickar in några av dem
> till CLRFI.

Sounds like a good idea to me. It looks as if they'll try to form
a group of editors at the ILC in June. So it would be nice if you
could submit something before that, just to keep them motivated to
actually do this.

> Jag kontaktade dem i slutet av förra året om WITH-GENSYMS, och de
> verkade positivt inställda, men sedan dess har jag inte gjort något.

So you didn't actually submit a CLRFI yet, right?

> Med lite tur blir jag arbetslös på måndag, och då får jag tid över. :)

Every cloud has a silver lining ;-)

> (Mitt förslag skulle nog bli som
> http://www.cliki.net/WITH-UNIQUE-NAMES
> fast omdöpt till WITH-GENSYMS.)

[Personally I prefer WITH-UNIQUE-NAMES, but I won't start a fight about
that ;-)]

I suppose the CLIKI page is a good start, but you'll need a bit more than
that. Quoting the CLRFI site:

It must list related standards and CLRFIs, including dependencies,
conflicts, and replacements. It must also list current practice, both
among implementors and in commercial and/or freely available libraries.

It must begin with an abstract. This will be fewer than 200 words long.
It will outline the need for, and design of, the proposal.

It must contain a detailed rationale. This will typically be 200-500 words
long and will explain why the proposal should be incorporated as a standard
feature in Common Lisp implementations. If there are other standards which
this proposal will replace or with which it will compete, the rationale
should explain why the present proposal is a substantial improvement.

The rationale must include a cost of adoption and a cost of non-adoption
assessment.

Not a trivial job, even for WITH-UNIQUE-NAMES, but doable.

Arthur

[d***@nada.kth.se]

> Lars Brinkhoff wrote:

>> (Mitt förslag skulle nog bli som
>> http://www.cliki.net/WITH-UNIQUE-NAMES
>> fast omdöpt till WITH-GENSYMS.)
>
> [Personally I prefer WITH-UNIQUE-NAMES, but I won't start a fight about
> that ;-)]

Ärligt talat begriper jag inte vitsen med att "standardisera" sådana
triviala saker. Vartenda lispare har väl ett WITH-GENSYMS-makro i sin
verktygslåda? Om jag skriver ett program somär avsett att vara fristående,
så stoppar jag bara in de egna små verktygsmakron och -funktioner jag
använder, och får då precis den funktion och semantik jag tänkt mig.

För att ta det aktuella exemplet så finns det ju en uppsjö olika varianter
av WITH-GENSYMS, WITH-UNIQUE-NAMES, REBINDING, m.m. Alla med litet olika
semantik och funktion.

Jag kan se värdet av att standardisera större saker, som kanske dessutom
kräver stöd i implementationen, men inte triviala femradersmakron.


Björn

[Arthur Lemmens]

Björn wrote:

> Ärligt talat begriper jag inte vitsen med att "standardisera" sådana
> triviala saker.

One of the advantages is that you get a common vocabulary.

> Vartenda lispare har väl ett WITH-GENSYMS-makro i sin verktygslåda?

That's exactly the kind of stuff that you want to standardize, I would
think. Stuff that everybody is using anyway and that's not too controversial.

> Om jag skriver ett program somär avsett att vara fristående,
> så stoppar jag bara in de egna små verktygsmakron och -funktioner jag
> använder, och får då precis den funktion och semantik jag tänkt mig.

If it's not standardized, maybe the "funktion och semantik jag tänkt mig"
is not exactly the functionality and semantics that /I/ would expect when
reading your program.

> För att ta det aktuella exemplet så finns det ju en uppsjö olika varianter
> av WITH-GENSYMS, WITH-UNIQUE-NAMES, REBINDING, m.m. Alla med litet olika
> semantik och funktion.

That's exactly the problem.

> Jag kan se värdet av att standardisera större saker, som kanske dessutom
> kräver stöd i implementationen, men inte triviala femradersmakron.

If the ANSI CL designers had thought the same way, they could have left
an awful lot (e.g. WHEN, UNLESS, CONSTANTLY, just to name a few obvious
candidates) out of the standard. Do you think that would have been better?

Personally, I think that would have been worse. I like to have a big,
well-defined vocabulary. That makes it easier to communicate with the
compiler, with other programmers and even with myself at a later stage.

The Schemers on this list will feel differently about this, I suppose ;-)

Arthur

[d***@nada.kth.se]

> Björn wrote:
>
>> Ärligt talat begriper jag inte vitsen med att "standardisera" sådana
>> triviala saker.
>
> One of the advantages is that you get a common vocabulary.

Det håller jag med om.

>> Vartenda lispare har väl ett WITH-GENSYMS-makro i sin verktygslåda?
>
> That's exactly the kind of stuff that you want to standardize, I would
> think. Stuff that everybody is using anyway and that's not too
> controversial.
>
>> Om jag skriver ett program somär avsett att vara fristående,
>> så stoppar jag bara in de egna små verktygsmakron och -funktioner jag
>> använder, och får då precis den funktion och semantik jag tänkt mig.
>
> If it's not standardized, maybe the "funktion och semantik jag tänkt mig"
> is not exactly the functionality and semantics that /I/ would expect when
> reading your program.

Visst, men när det gäller 3-5-radersmakron är risken stor att jag ändå
använder mina egna, om den fastslagna standarden inte överensstämmer med
mina preferenser.

>> För att ta det aktuella exemplet så finns det ju en uppsjö olika
>> varianter
>> av WITH-GENSYMS, WITH-UNIQUE-NAMES, REBINDING, m.m. Alla med litet olika
>> semantik och funktion.
>
> That's exactly the problem.
>
>> Jag kan se värdet av att standardisera större saker, som kanske dessutom
>> kräver stöd i implementationen, men inte triviala femradersmakron.
>
> If the ANSI CL designers had thought the same way, they could have left
> an awful lot (e.g. WHEN, UNLESS, CONSTANTLY, just to name a few obvious
> candidates) out of the standard. Do you think that would have been
> better?

Nej. Tvärtom, jag hade gärna sett fler saker i standarden, som någon
WITH-GENSYMS t.ex. Men det är skillnad. Implementationer måste
implementera hela ANSI om de vill vara ANSI. Jag tror inte att
CLRFI-processen kan få ens i närheten av samma genomslag.

> Personally, I think that would have been worse. I like to have a big,
> well-defined vocabulary. That makes it easier to communicate with the
> compiler, with other programmers and even with myself at a later stage.

Jag med. När jag tänker efter tror jag att skillnaden i våra åsikter är
att du hyser större förhoppningar om CLRFI:s genomslag än jag gör. Sedan
är jag rädd för att CLRFI-förslagen får mycket lägre kvalitet än det som
är i ANSI, och då /vill/ jag helst inte att de får något genomslag. Som
ett exempel kan vi ta SPLIT-SEQUENCE som var tänkt att bli ett slags
standard. Personligen gillar jag nämligen inte
SPLIT-SEQUENCE-gränssnittet, och tenderar därför att använda egna, mer
specialiserade funktioner.

> The Schemers on this list will feel differently about this, I suppose ;-)

Säkerligen. Men detta är väl en Lisplista? ;-)


Björn

[Arthur Lemmens]

Björn wrote:

> Jag med. När jag tänker efter tror jag att skillnaden i våra åsikter är
> att du hyser större förhoppningar om CLRFI:s genomslag än jag gör.

Actually, I'm rather skeptical about it. The big stuff will be too difficult
too standardize and the small stuff may not be worth the trouble. Still, I
think it's a brave and interesting experiment and it's not impossible that
something good will come out of it.

It's just not something that I personally want to spend much time on. I'd
rather organize Lisp meetings. ;-) If we Lispers want to get away from the
"lonely hacker syndrome" and start earning some money in the real world,
we should get to know each other. For me that's much more important than
standardizing WITH-GENSYMS or whatever.

>> The Schemers on this list will feel differently about this, I suppose ;-)
>
> Säkerligen. Men detta är väl en Lisplista? ;-)

Are you implying that Scheme is not a Lisp? ;-))

Arthur

[d***@nada.kth.se]

> Björn wrote:
>
>> Jag med. När jag tänker efter tror jag att skillnaden i våra åsikter är
>> att du hyser större förhoppningar om CLRFI:s genomslag än jag gör.
>
> Actually, I'm rather skeptical about it. The big stuff will be too
> difficult
> too standardize and the small stuff may not be worth the trouble. Still,
> I
> think it's a brave and interesting experiment and it's not impossible that
> something good will come out of it.

Jupp.

> It's just not something that I personally want to spend much time on. I'd
> rather organize Lisp meetings. ;-) If we Lispers want to get away from
> the
> "lonely hacker syndrome" and start earning some money in the real world,
> we should get to know each other. For me that's much more important than
> standardizing WITH-GENSYMS or whatever.

Och att organisera möten är du verkligen bra på, måste jag säga. :-)


Björn

[Sunnan]

Arthur Lemmens wrote:

> Actually, I'm rather skeptical about it. The big stuff will be too
> difficult
> too standardize and the small stuff may not be worth the trouble.
> Still, I
> think it's a brave and interesting experiment and it's not impossible
> that
> something good will come out of it.

I schemevärlden har SRFI-processen varit en stor framgång.

> Are you implying that Scheme is not a Lisp? ;-))

Vissa schemare påstod själva att Scheme inte var en Lisp på åttiotalet,
för att slippa tjafset med Common Lisp-standardiseringsprocessen. DKJIA,
jag tycker att den lätt är en lisp.

[Arthur Lemmens]

Sunnan wrote:

> I schemevärlden har SRFI-processen varit en stor framgång.

Well, they had a lot more to standardize of course ;-)

>> Are you implying that Scheme is not a Lisp? ;-))
>
> Vissa schemare påstod själva att Scheme inte var en Lisp på
> åttiotalet, för att slippa tjafset med Common Lisp-
> standardiseringsprocessen. DKJIA, jag tycker att den lätt är
> en lisp.

This question has been the source of countless flamewars over the
years. That's why I added a smiley. Personally, I think Scheme
is a Lisp but I don't really care either way.

What does DKJIA mean, by the way?

Arthur

[Sunnan]

Arthur Lemmens wrote:

> Sunnan wrote:
>
>> I schemevärlden har SRFI-processen varit en stor framgång.
>
>
> Well, they had a lot more to standardize of course ;-)

Of course, and I think the SRFI-process is a very good way to do it
(from a democracy/process-theory standpoint).

> What does DKJIA mean, by the way?


"Detta kan jag inte acceptera" - "This I can not accept"

[Sunnan]

Arthur Lemmens wrote:

> Personally, I think that would have been worse. I like to have a big,
> well-defined vocabulary. That makes it easier to communicate with the
> compiler, with other programmers and even with myself at a later stage.
>
> The Schemers on this list will feel differently about this, I suppose ;-)

Jag tycker om att ha sådana grejer i bibliotek, inte i själva
språkstandarden.
Varenda schemare använder väl srfi-1 någon gång, men kanske inte hela tiden.

[Elias Martenson]

fre 2005-04-29 klockan 13:24 +0200 skrev Sunnan:
> Arthur Lemmens wrote:
>
> > Personally, I think that would have been worse. I like to have a big,
> > well-defined vocabulary. That makes it easier to communicate with the
> > compiler, with other programmers and even with myself at a later stage.
> >
> > The Schemers on this list will feel differently about this, I suppose ;-)
>
> Jag tycker om att ha sådana grejer i bibliotek, inte i själva
> språkstandarden.
> Varenda schemare använder väl srfi-1 någon gång, men kanske inte hela tiden.

Ungefär som Java då, där man har en enorm mängd återanvändningsbara
bibliotek som alla kan använda. Om man behöver en funktionalitet så
lockar man hem ett bibliotek som (kanske) gör det man vill så slipper
man implementera det själv. Jag skulle vilja påstå att det är detta som
gör Java (mer) användbart (än andra språk).

Det är väl detta behov som CPAN uppfyller i Perl-

[d***@nada.kth.se]

> fre 2005-04-29 klockan 13:24 +0200 skrev Sunnan:
>> Arthur Lemmens wrote:
>>
>> > Personally, I think that would have been worse. I like to have a
>> big,
>> > well-defined vocabulary. That makes it easier to communicate with the
>> > compiler, with other programmers and even with myself at a later
>> stage.
>> >
>> > The Schemers on this list will feel differently about this, I suppose
>> ;-)
>>
>> Jag tycker om att ha sådana grejer i bibliotek, inte i själva
>> språkstandarden.
>> Varenda schemare använder väl srfi-1 någon gång, men kanske inte
>> hela tiden.
>
> Ungefär som Java då, där man har en enorm mängd återanvändningsbara
> bibliotek som alla kan använda. Om man behöver en funktionalitet så
> lockar man hem ett bibliotek som (kanske) gör det man vill så slipper
> man implementera det själv. Jag skulle vilja påstå att det är detta
> som
> gör Java (mer) användbart (än andra språk).

Det är definitivt Javas styrka. Den stora skillnaden är att Sun ligger
bakom Javabiblioteken, vilket fyller två funktioner:

1) Det etablerar en standard.

2) Det tillser att biblioteken håller en rimligt god kvalitet.

> Det är väl detta behov som CPAN uppfyller i Perl-världen.

CPAN uppfyller (1) ovan, men knappast (2). CL börjar informellt få en stor
gemensam kodbas, bl.a. genom common-lisp.net, ASDF, etc. Alla dessa
bibliotek är av god kvalitet.


Björn

[Elias Martenson]

fre 2005-04-29 klockan 14:36 +0200 skrev d95-***@nada.kth.se:
> Det är definitivt Javas styrka. Den stora skillnaden är att Sun ligger
> bakom Javabiblioteken, vilket fyller två funktioner:
>
> 1) Det etablerar en standard.
>
> 2) Det tillser att biblioteken håller en rimligt god kvalitet.
>
> > Det är väl detta behov som CPAN uppfyller i Perl-världen.
>
> CPAN uppfyller (1) ovan, men knappast (2). CL börjar informellt få en stor
> gemensam kodbas, bl.a. genom common-lisp.net, ASDF, etc. Alla dessa
> bibliotek är av god kvalitet.

Detta är inte riktigt sant. Det finns en stor mängd fria bibliotek, den
mest kända samligen är väl de som produceras via Apache-projektet,
speciellt commons.

Dock skall det sägas att Apache Commons (och fria bibliotek i allmänhet)
lider av exakt samma problem som CPAN, 95% är ren dynga. Dock så är de
kvarvarande 5% mycket bra, och definitvt något jag inte skulle vilj
avara utan.

Hur jag hittar mostvarande i Lisp-världen vet jag inte. Antag t.ex. att
jag vill skapa PDF-dokument från ett Lisp-program, finns det någonstans
jag kan leta fö

[Arthur Lemmens]

Elias Martenson wrote:

> Hur jag hittar mostvarande i Lisp-världen vet jag inte.

Try http://common-lisp.net and http://www.cliki.net
They cover about 80% of the interesting stuff out there.

> Antag t.ex. att jag vill skapa PDF-dokument från ett Lisp-program, finns
> det någonstans jag kan leta för att hitta ett färdigt bibliotek för detta?

Try the CL-PDF link at http://www.fractalconcept.com

Arthur

[Sunnan]

Elias Martenson wrote:

>Hur jag hittar mostvarande i Lisp-världen vet jag inte. Antag t.ex. att
>jag vill skapa PDF-dokument från ett Lisp-program, finns det någonstans
>jag kan leta för att hitta ett färdigt bibliotek för detta?
>
>
Vet inte hur det är med CL men jag som schemare skulle först och främst
kolla på bibliotekssidan för min implementation, i andra hand skulle jag
söka efter det via någon sökmotor för www och usenet, i tredje hand
kolla efter C-bibliotek som jag kan använda via FFI, i fjärde hand
skriva från scratch i Scheme och släppa fritt, i femte hand (om det var
någon stor uppgift, svårare än att göra pdf-bibliotek) kolla i
CL-världen om jag kan porta det till Scheme.

Antar att jag, om jag var CL:are, skulle göra som ovan fast med Scheme
och CL utbytt mot varandra. Fast mycket av asdf-grejerna finns som
debianpaket så en apt-cache search skulle ligga nära till hands.

[Sunnan]

d95-***@nada.kth.se wrote:

> CL börjar informellt få en stor gemensam kodbas, bl.a. genom
> common-lisp.net, ASDF, etc. Alla dessa bibliotek är av god kvalitet.

Sådant vill jag uppmuntra.

[d***@nada.kth.se]

> fre 2005-04-29 klockan 13:24 +0200 skrev Sunnan:
>> Arthur Lemmens wrote:
>>
>> > Personally, I think that would have been worse. I like to have a
>> big,
>> > well-defined vocabulary. That makes it easier to communicate with the
>> > compiler, with other programmers and even with myself at a later
>> stage.
>> >
>> > The Schemers on this list will feel differently about this, I suppose
>> ;-)
>>
>> Jag tycker om att ha sådana grejer i bibliotek, inte i själva
>> språkstandarden.
>> Varenda schemare använder väl srfi-1 någon gång, men kanske inte
>> hela tiden.
>
> Ungefär som Java då, där man har en enorm mängd återanvändningsbara
> bibliotek som alla kan använda. Om man behöver en funktionalitet så
> lockar man hem ett bibliotek som (kanske) gör det man vill så slipper
> man implementera det själv. Jag skulle vilja påstå att det är detta
> som
> gör Java (mer) användbart (än andra språk).

Det är definitivt Javas styrka. Den stora skillnaden är att Sun ligger
bakom Javabiblioteken, vilket fyller två funktioner:

1) Det etablerar en standard.

2) Det tillser att biblioteken håller en rimligt god kvalitet.

> Det är väl detta behov som CPAN uppfyller i Perl-världen.

CPAN uppfyller (1) ovan, men knappast (2). CL börjar informellt få en stor
gemensam kodbas, bl.a. genom common-lisp.net, ASDF, etc. Alla dessa
bibliotek är av god kvalitet.


Björn

[d***@nada.kth.se]

> fre 2005-04-29 klockan 13:24 +0200 skrev Sunnan:
>> Arthur Lemmens wrote:
>>
>> > Personally, I think that would have been worse. I like to have a
>> big,
>> > well-defined vocabulary. That makes it easier to communicate with the
>> > compiler, with other programmers and even with myself at a later
>> stage.
>> >
>> > The Schemers on this list will feel differently about this, I suppose
>> ;-)
>>
>> Jag tycker om att ha sådana grejer i bibliotek, inte i själva
>> språkstandarden.
>> Varenda schemare använder väl srfi-1 någon gång, men kanske inte
>> hela tiden.
>
> Ungefär som Java då, där man har en enorm mängd återanvändningsbara
> bibliotek som alla kan använda. Om man behöver en funktionalitet så
> lockar man hem ett bibliotek som (kanske) gör det man vill så slipper
> man implementera det själv. Jag skulle vilja påstå att det är detta
> som
> gör Java (mer) användbart (än andra språk).

Det är definitivt Javas styrka. Den stora skillnaden är att Sun ligger
bakom Javabiblioteken, vilket fyller två funktioner:

1) Det etablerar en standard.

2) Det tillser att biblioteken håller en rimligt god kvalitet.

> Det är väl detta behov som CPAN uppfyller i Perl-världen.

CPAN uppfyller (1) ovan, men knappast (2). CL börjar informellt få en stor
gemensam kodbas, bl.a. genom common-lisp.net, ASDF, etc. Alla dessa
bibliotek är av god kvalitet.


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Ärligt talat begriper jag inte vitsen med att "standardisera" sådana
>triviala saker. Vartenda lispare har väl ett WITH-GENSYMS-makro i sin
>verktygslåda?
>

En anledning är för att nya lispare ska få det "gratis", s.a.s.
WITH-GENSYMS är snyggt och viktigt, även om det är lätt att implenterera.

Stora delar av Scheme-standarden är korta makron (även grundläggande
saker som let, cond, and, or).

[Lars Brinkhoff]

Arthur Lemmens <***@xs4all.nl> writes:
> Lars Brinkhoff wrote:
>> Ja, och om ingen annan gör det, kanske jag skickar in några av dem
>> till CLRFI.
> It looks as if they'll try to form a group of editors at the ILC in
> June. So it would be nice if you could submit something before
> that, just to keep them motivated to actually do this.

Ja, fast jag tror de redan har COMPILED-FILE-P att jobba med.

>> Jag kontaktade dem i slutet av förra året om WITH-GENSYMS, och de
>> verkade positivt inställda, men sedan dess har jag inte gjort något.
> So you didn't actually submit a CLRFI yet, right?

Nej.

[d***@nada.kth.se]

> d95-***@nada.kth.se wrote:
>
>>Det kan han ju tycka. I själva verket är det Perl-skaran som är
>>dysfunktionell.
>>
>>
> Att perl i sig är dysfunktionellt är ju inte direkt en nyhet.
> Lika så dessa suspekta hobbier som golfande och dylikt.
>
> Men hur menar du att skaran är dysfunktionell? Jag har inte sett i
> närheten av lika mycket kontroverser, gräl och politik hos perlfolk (men
> jag har inte kollat lika mycket på perlkretsar som jag har på
> lispkretsarna).

Jag tänkte mest på Perlskarans ofta sektaktiga beteende, och extremt
världsfrånvända syn på: programmeringspråk, programmering, mm. Du kanske
invänder att det bara utgör den merst extrema delen av gruppen ifråga, men
detsamma kan naturligtvis sägas om Lispgemenskapen. Helgens eurolispmöte
var i alla avseenden ytterst odysfunktionellt. :-)

> Perlskaran har i alla fall hasplat ur sig en fungerande CPAN och en

Uppriktigt sagt förstår jag inte riktigt uppståndelsen kring CPAN. Mitt
intryck är att det inte finns någon som helst kvalitetskontroll, och att
min st 95% är rent skräp. Det kanske är användbart för folk som egentligen
inte kan programmera, men som vill slänga ihop ett program som i medvind
och nedförsbacke fungerar *nästan* som avsett. Det är i vart fall
ingenting jag skulle vilja använda, och jag är glad att det inte finns
något CPAN för CL.

> intressant språkdesignprocess för perl 6.

He he he. Vilket decennium som helst nu...


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Jag tänkte mest på Perlskarans ofta sektaktiga beteende, och extremt
>världsfrånvända syn på: programmeringspråk, programmering, mm. Du kanske
>invänder att det bara utgör den merst extrema delen av gruppen ifråga,
>

Nej, vi har nog samma definition på "perlskaran". Jag vet dock inte om
jag har upplevt det (sektaktigheten, världsfrånvändheten) som
dysfunktionellt.
Jag tänker att det ord där vi har olika definition är just
"dysfunktionellt".

Jag vet inget språk där skaran har lika mycket bråk, kontroverser och
schismer (CL/Scheme, t.ex.) som lisp. ML kommer kanske på andra plats.
Att språket funnits sedan femtiotalet är kanske en förklaring.

Jag vet ingen programmeringsspråksnyhetsgrupp som är lika lättantändlig
som cll. Jag råkade haspla ur mig lite anti-python-goja i
comp.lang.python och alla bara "äsch då" och "du kanske har rätt"
istället för att bli arga. En väldigt härlig upplevelse!

> men
>detsamma kan naturligtvis sägas om Lispgemenskapen. Helgens eurolispmöte
>var i alla avseenden ytterst odysfunktionellt. :-)
>
>
Det glädjer mig att höra. Jag tänker att det har blivit bättre på sistone.

>>Perlskaran har i alla fall hasplat ur sig en fungerande CPAN och en
>>
>>
>
>Uppriktigt sagt förstår jag inte riktigt uppståndelsen kring CPAN. Mitt
>intryck är att det inte finns någon som helst kvalitetskontroll, och att
>min st 95% är rent skräp.
>

Ja, och jag tror att det är därför processen fungerar så bra. 5% av CPAN
är ändå väldigt mycket kod.

Jag tror att en av nycklarna till en fungerande kodåteranvändning är låg
kvalitetströskel; då kan användarna själva välja vad av materialet de
kan använda, förbättra resp. kasta.

> Det kanske är användbart för folk som egentligen
>inte kan programmera, men som vill slänga ihop ett program som i medvind
>och nedförsbacke fungerar *nästan* som avsett.
>
Det är väl en stor och viktig grupp människor?

>>intressant språkdesignprocess för perl 6.
>>
>>
>
>He he he. Vilket decennium som helst nu...
>
>
Hur menar du? Pugs finns ju.

[d***@nada.kth.se]

> d95-***@nada.kth.se wrote:
>
>>Jag tänkte mest på Perlskarans ofta sektaktiga beteende, och extremt
>>världsfrånvända syn på: programmeringspråk, programmering, mm. Du kanske
>>invänder att det bara utgör den merst extrema delen av gruppen ifråga,
>>
>
> Nej, vi har nog samma definition på "perlskaran". Jag vet dock inte om
> jag har upplevt det (sektaktigheten, världsfrånvändheten) som
> dysfunktionellt.
> Jag tänker att det ord där vi har olika definition är just
> "dysfunktionellt".
>
> Jag vet inget språk där skaran har lika mycket bråk, kontroverser och
> schismer (CL/Scheme, t.ex.) som lisp. ML kommer kanske på andra plats.
> Att språket funnits sedan femtiotalet är kanske en förklaring.

Det är nog helt enkelt så att Lispskaran är väldigt heterogen. Där ryms:

Kommersiella implementationer <--> ÖK-implementationer

ÖK-förespråkare <--> ÖK-*motståndare*

Scheme <--> Lisp

Inget av detta har någon motsvarighet i, säg Python- eller Perlmiljöerna.
Sedan tror jag även att Lispskaran har färre "får", men det kanske bara är
min elitism som skiner igenom.

>>Uppriktigt sagt förstår jag inte riktigt uppståndelsen kring CPAN. Mitt
>>intryck är att det inte finns någon som helst kvalitetskontroll, och att
>>min st 95% är rent skräp.
>>
>
> Ja, och jag tror att det är därför processen fungerar så bra. 5% av CPAN
> är ändå väldigt mycket kod.

Men vilka 5%? Att hitta dem är förmodligen lika mycket jobb som att skriva
själv från grunden.

> Jag tror att en av nycklarna till en fungerande kodåteranvändning är låg
> kvalitetströskel; då kan användarna själva välja vad av materialet de
> kan använda, förbättra resp. kasta.
>
>> Det kanske är användbart för folk som egentligen
>>inte kan programmera, men som vill slänga ihop ett program som i medvind
>>och nedförsbacke fungerar *nästan* som avsett.
>>
> Det är väl en stor och viktig grupp människor?

Nej, tvärtom. De producerar ju bara skräp. Problemet med CPAN, och för all
del Perl som helhet, är att det uppmuntrar ett beteende som resulterar i
undermålig programvara. Jag ser inget värde i det.

>>>intressant språkdesignprocess för perl 6.
>>>
>>>
>>
>>He he he. Vilket decennium som helst nu...
>>
>>
> Hur menar du? Pugs finns ju.

Jag är beredd att sätta åtminstone en symbolisk slant på att Perl 6 aldrig
ser dagens ljus. Åtminstone i så motto att det inte blir Perl 5:s
efterföljare.


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Det är nog helt enkelt så att Lispskaran är väldigt heterogen. Där ryms:
>
>Kommersiella implementationer <--> ÖK-implementationer
>
>ÖK-förespråkare <--> ÖK-*motståndare*
>
>Scheme <--> Lisp
>
>Inget av detta har någon motsvarighet i, säg Python- eller Perlmiljöerna.
>
>
Det finns ju
php <--> perl <--> python <--> ruby
men det är också allt. Det finns inte direkt några frikodsmotståndare
eller ofria implementationer.

>Sedan tror jag även att Lispskaran har färre "får", men det kanske bara är
>min elitism som skiner igenom.
>
>
>
Jag tror att det är så att man alltid ser fler "ofår" i den skara man
själv är närmast.

>>Ja, och jag tror att det är därför processen fungerar så bra. 5% av CPAN
>>är ändå väldigt mycket kod.
>>
>>
>
>Men vilka 5%? Att hitta dem är förmodligen lika mycket jobb som att skriva
>själv från grunden.
>
>
??? Varför ska man vilja tänka "uj, jag vill använda de 5 bästa
procenten av CPAN i det här programmet"?
Snarare tänker man på följande två sätt i kombination:
1) Jag behöver en recdescentparser, jag kollar om CPANs sådana är något
att ha
2) Modul X (t.ex. listbiblioteket) används av många och rekommenderas
varmt av folk jag litar på, den ska jag kolla in.

>>Det är väl en stor och viktig grupp människor?
>>
>>
>
>Nej, tvärtom. De producerar ju bara skräp.
>
Som de behöver för egen del. T.ex. att kunna slänga ihop ett halvpissigt
bokningssystem till en mindre organisation, t.ex. en liten orts studentkår.

Jag tycker att trösken för att börja resan mot att bli en programmerare
ska vara låg.

Det är också IMHO viktigt att intresse för, och kunskap om, UI- och
annan programdesign börjar sprida sig. Det är också en sak som minskar
skräpfaktorn i programmen.

Det känns IMHO mindre skandalöst med några "fula" kodrader hit och dit
(menar saker som alla erfarna programmerare skulle (och fortfarande kan)
refactora bort - typ bruk av strängarrayer där man borde använda records
eller dataklasser - jag menar inte rena buggar som buffertspill) än med
undermåligt designade program.

>Jag är beredd att sätta åtminstone en symbolisk slant på att Perl 6 aldrig
>ser dagens ljus. Åtminstone i så motto att det inte blir Perl 5:s
>efterföljare.
>
>
>
Det beror på vad man menar med efterföljare. Men jag tycker att Pugs
verkar helt säreget på ett bra sätt.

[d***@nada.kth.se]

> d95-***@nada.kth.se wrote:
>
>>Det är nog helt enkelt så att Lispskaran är väldigt heterogen. Där ryms:
>>
>>Kommersiella implementationer <--> ÖK-implementationer
>>
>>ÖK-förespråkare <--> ÖK-*motståndare*
>>
>>Scheme <--> Lisp
>>
>>Inget av detta har någon motsvarighet i, säg Python- eller Perlmiljöerna.
>>
>>
> Det finns ju
> php <--> perl <--> python <--> ruby
> men det är också allt. Det finns inte direkt några frikodsmotståndare
> eller ofria implementationer.

Men dessa konflikter verkar enande snarare än splittrande inom den egna
gruppen.

>>>Det är väl en stor och viktig grupp människor?
>>>
>>>
>>
>>Nej, tvärtom. De producerar ju bara skräp.
>>
> Som de behöver för egen del. T.ex. att kunna slänga ihop ett halvpissigt
> bokningssystem till en mindre organisation, t.ex. en liten orts
> studentkår.

Men det kanske inte är svårare att slänga ihop ett kvartspissigt
bokningsystem? Speciellt om man räknar med underhåll och utökning av
systemet.

> Jag tycker att trösken för att börja resan mot att bli en programmerare
> ska vara låg.

Perl gör förvisso resan lätt, det är bara det att den resan inte går mot
bättre kod eller bättre programmerare.


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Men det kanske inte är svårare att slänga ihop ett kvartspissigt
>bokningsystem? Speciellt om man räknar med underhåll och utökning av
>systemet.
>
>
Det kräver mer förkunskap (speciellt om man ska använda CL!), det är en
annan tröskelsituation.

>>Jag tycker att trösken för att börja resan mot att bli en programmerare
>>ska vara låg.
>>
>>
>
>Perl gör förvisso resan lätt, det är bara det att den resan inte går mot
>bättre kod eller bättre programmerare.
>
>
Då kan man ju byta språk senare.

[Björn Lindberg]

Sunnan <***@handgranat.org> writes:

> d95-***@nada.kth.se wrote:
>
> >Men det kanske inte är svårare att slänga ihop ett kvartspissigt
> >bokningsystem? Speciellt om man räknar med underhåll och utökning av
> >systemet.
> >
> Det kräver mer förkunskap (speciellt om man ska använda CL!), det är
> en annan tröskelsituation.

Skall man inte ha det då? En bagare som inte kan baka komemr att göra
dåligt bröd. Jag ser liksom ingen finess i det.

Sedan är jag inte så säker på att CL måste vara så mycket svårare
heller. Det är /andra saker/ som är svåra förvisso, men typiskt
viktigare saker. Jag menar, Perl är /svårt/. Möjligen kan Perl ge sken
av att inte vara det, och det är möjligen lätt att börja pilla i det
utan att veta vad man gör (för övrigt den typiska inställningen även
hos mer erfarna perlprogrammerare), men för att bemästra Perl måste
man t.ex. bemästra pekare (så kallade referenser), och hålla reda på
de olika kontexter som finns. Att säga att det inte finns någon
endaste människa som fullt ut bemästrar Perlsyntaxen är ett trivialt
påstående, eftersom inte ens tolken självt gör det.

> >>Jag tycker att trösken för att börja resan mot att bli en programmerare
> >>ska vara låg.
> >>
> >
> >Perl gör förvisso resan lätt, det är bara det att den resan inte går mot
> >bättre kod eller bättre programmerare.
> >
> Då kan man ju byta språk senare.

Fast bättre att inte gå fel väg redan från början.


Björn

[Sunnan]

Björn Lindberg wrote:

>Skall man inte ha det då? En bagare som inte kan baka komemr att göra
>dåligt bröd. Jag ser liksom ingen finess i det.
>
>
En bra analogi. Jag ser ett värde i att kunna slänga ihop en limpa. Det
blir inte av sådan kvalitet att jag skulle kunna sälja den. Men jag kan
äta den.

>Sedan är jag inte så säker på att CL måste vara så mycket svårare
>heller.
>
Nej, det är förstås en öppen fråga.

(Som hänger ihop med den ack så flambenägna frågan lisp-1 vs lisp-2. Det
finns fördelar med bådadera men enligt min erfarenhet tycks det vara
mycket enklare att lära sig "bra" saker som closures t.ex. med en
lisp-1. De som i första hand har lärt sig en lisp-2 har helt enkelt en
annan programmeringsstil.) (N.B. att perl är en "lisp-1000", minst.
(nej, men sex i alla fall.))

[Björn Lindberg]

Sunnan <***@handgranat.org> writes:

> Björn Lindberg wrote:
>
> >Skall man inte ha det då? En bagare som inte kan baka komemr att göra
> >dåligt bröd. Jag ser liksom ingen finess i det.
> >
> En bra analogi.

Det finns inga bra liknelser. :-)

> Jag ser ett värde i att kunna slänga ihop en
> limpa. Det blir inte av sådan kvalitet att jag skulle kunna sälja
> den. Men jag kan äta den.

Just det. Men limpan blir bäst om du använder rätt ingredienser och
rätt redskap.

> >Sedan är jag inte så säker på att CL måste vara så mycket svårare
> >heller.
> >
> Nej, det är förstås en öppen fråga.
>
> (Som hänger ihop med den ack så flambenägna frågan lisp-1 vs
> lisp-2. Det finns fördelar med bådadera men enligt min erfarenhet
> tycks det vara mycket enklare att lära sig "bra" saker som closures
> t.ex. med en lisp-1. De som i första hand har lärt sig en lisp-2 har
> helt enkelt en annan programmeringsstil.)

Det tror jag inte alls på. (Ja, din erfarnehet kan jag tro på, men jag
tror inte att det stämmer överlag.) Jag kan heller inte se hur
lisp-1/2 skulle påverka inlärning av omslutningar. Tricket där är ju
att fatta att lexikala variabler är just lexikala, och att de har
obegränsad utsträckning.

> (N.B. att perl är en
> "lisp-1000", minst. (nej, men sex i alla fall.))

Tja, detta har vi förstås diskuterat förut. Vi kan säga att perl är en
perl-6 kanske.


Björn

[Sunnan]

Björn Lindberg wrote:

>Just det. Men limpan blir bäst om du använder rätt ingredienser och
>rätt redskap.
>
>
Men som hemma-limp-bagare kanske jag inte behöver Heavy Duty Industrial
Baking Oven 3000.

(Där jag tänker mig att CL är en svårlärd Heavy Duty Industrial Baking
Oven med tusen features, Perl är en skranglig tv-shops-ugn med tusen
features, Scheme är ett enkelt kvalitetsverktyg som passar både
hemmabagare och professionella, och sed/awk är verktyg främst för
hemmabak. Och PHP hör hemma enbart på soptippen.)

>Det tror jag inte alls på. (Ja, din erfarnehet kan jag tro på, men jag
>tror inte att det stämmer överlag.) Jag kan heller inte se hur
>lisp-1/2 skulle påverka inlärning av omslutningar.
>

Jag tror (nb: tror, inte vet) att en som har vana från att jobba med
lisp-1 oftare använder programmeringstekniker som de i SICP. Funktioner
som returnerar funktioner som returnerar funktioner.

I scheme är det enda man behöver komma ihåg hur en lambda fungerar.

Exempel:

(define (make-grower)
(let ((s 0))
(lambda ()
(set! s (add1 s))
s)))

(define gen-id (make-grower))

Det här går att göra i CL med motsvarande mängd kod, men jag har
FORTFARANDE inte memorerat hur man gör - och i den mån den
programmeringstekniken används är det (tror jag) på grund av schemare
som infört detta till CL, eller CL:are som läst t.ex. SICP.

Jag såg att du hade använt det liknande, klassiska
make-bank-account-exemplet, som är ett exempel på denna
programmeringsteknik. Du valde att göra ett macro för att dölja funcall!

I scheme blir defparameter en vanlig define, defun blir en vanlig
define, funcall behövs inte, send behövs inte... ((konto 'withdraw) 80)
är allt man behöver. (Jag gjorde en gång i tiden ett macro på detta som
gjorde att man kunde skriva (withdraw konto 80) a la clos. Men det är
överkurs.)

CL *går* att lära sig, det går att göra det mesta schemare kan göra, men
det *är* fler saker att minnas, fler saker som ska interagera med varandra.

En älskad vän försvarade Javas dålighet med att "det går ju typ att
använda higher-order-functions-liknande grejer med anonyma
predikatklasser och sånt, det blir ett par rader extra men det går ju
att göra!". Mmm, men om man diskuterar just sakers lätt-att-lära-sig-het
så är det bättre med några få enkla, väldigt flexibla beståndsdelar. Som
Go vs Schack.

> Tricket där är ju
>att fatta att lexikala variabler är just lexikala, och att de har
>obegränsad utsträckning.
>
>
Ja, men det handlar också om hur man kan använda denna egenhet. Genom
att se den användas i praktiken förstår man fördelen med att det funkar
så. Innan jag såg bank-account-exemplet fattade jag inte varför closures
var så ballt.

Obs, obs - "closed" som ordet closure kommer ifrån betyder dessutom en
sak till. Det betyder att saker kan användas med sig själva - cons-par
kan bestå av andra cons-par, *och funktioner kan ta emot och returnera
andra funktioner*. Metacirkeln är sluten.

>Tja, detta har vi förstås diskuterat förut. Vi kan säga att perl är en
>perl-6 kanske.
>
>
Ja, DKJA.

[Björn Lindberg]

Sunnan <***@handgranat.org> writes:

> Björn Lindberg wrote:
>
> >Just det. Men limpan blir bäst om du använder rätt ingredienser och
> >rätt redskap.
> >
> Men som hemma-limp-bagare kanske jag inte behöver Heavy Duty
> Industrial Baking Oven 3000.
>
> (Där jag tänker mig att CL är en svårlärd Heavy Duty Industrial Baking
> Oven med tusen features, Perl är en skranglig tv-shops-ugn med tusen
> features, Scheme är ett enkelt kvalitetsverktyg som passar både
> hemmabagare och professionella, och sed/awk är verktyg främst för
> hemmabak. Och PHP hör hemma enbart på soptippen.)

Perl är att ha tusen prylar som egentligen inte alls har med bakning
tillhands, typ ett par badtofflor, en stekspade, en ask gummisnoddar
och så vidare. :-)

> >Det tror jag inte alls på. (Ja, din erfarnehet kan jag tro på, men jag
> >tror inte att det stämmer överlag.) Jag kan heller inte se hur
> >lisp-1/2 skulle påverka inlärning av omslutningar.
> >
>
> Jag tror (nb: tror, inte vet) att en som har vana från att jobba med
> lisp-1 oftare använder programmeringstekniker som de i
> SICP. Funktioner som returnerar funktioner som returnerar funktioner.

Så kan det säkert vara, men det tror jag har med andra skillnader att
göra, både kulturella och rent dogmatiska. Dels är schemekulturen mer
dogmatisk kring funktionell programmering, rekursion o.dyl., dels har
CL-programmeraren helt enkelt mer i verktygslådan: dynamiska
variabler, CLOS, conditionsystemet, etc. Medan schemeprogrammeraren
funderar på hur han kan bygga om sin iteration till en rekursion har
CL-programmeraren redan skrivit den med DOLIST eller LOOP och gått
vidare. :-)

(Låt mig förekomma invändningen att Scheme visst har alla dessa
verktyg i mer eller mindre exotiska SRFI:er: det fina med CL är inte
bara att alla dessa saker finns till hands, utan även att de passar
ihop så bra med varandra. Summan är större än delarna tillsammans,
liksom. Detta måste nog upplevas för att tillfullo förstås.)

> I scheme är det enda man behöver komma ihåg hur en lambda fungerar.
>
> Exempel:
>
> (define (make-grower)
> (let ((s 0))
> (lambda ()
> (set! s (add1 s))
> s)))
>
> (define gen-id (make-grower))
>
> Det här går att göra i CL med motsvarande mängd kod, men jag har
> FORTFARANDE inte memorerat hur man gör - och i den mån den
> programmeringstekniken används är det (tror jag) på grund av schemare
> som infört detta till CL, eller CL:are som läst t.ex. SICP.

Redan din inställning här förklarar nog till stor del skillnaden. Jag
ser inget egenvärde i att skriva extremt funktionell/applikativ kod om
det inte löser problemet bättre. Det är bara *ett* verktyg i lådan.

(Så här skulle det se ut i CL:

(defun make-grower ()
(let ((s 0))
#'(lambda () (incf s))))
)

> Jag såg att du hade använt det liknande, klassiska
> make-bank-account-exemplet, som är ett exempel på denna
> programmeringsteknik. Du valde att göra ett macro för att dölja
> funcall!

Nej. Makrot var för att man skulle slippa skriva 'meddelande i
anropet. Syntaktiskt socker med andra ord. SEND kunde lika gärna varit
en funktion.

> I scheme blir defparameter en vanlig define, defun blir en vanlig
> define, funcall behövs inte, send behövs inte... ((konto 'withdraw)
> 80) är allt man behöver. (Jag gjorde en gång i tiden ett macro på
> detta som gjorde att man kunde skriva (withdraw konto 80) a la
> clos. Men det är överkurs.)

Scheme har sina brister det med. Inre DEFINE t.ex. eller BEGIN:s olika
semantik i olika situationer.

Två fördelar jag ser med CL:s lisp-2-aktighet:

- Det visar sig att lisp-2 passar väldigt bra med DEFMACRO, och jag
råkar tycka att DEFMACRO är ett väldigt bra sätt att definiera
makron på.

- Symboler i CL är riktiga datastrukturer, istället för att bara
vara namn som de är i Scheme.

> CL *går* att lära sig, det går att göra det mesta schemare kan göra,
> men det *är* fler saker att minnas, fler saker som ska interagera med
> varandra.

Och hur kraftfullt och användbart tror du att ett språk är som man kan
lära sig helt på en vecka? CL tar lång tid att lära sig, men det är i
sammanhanget en styrka. Att "fler saker interagerar med varandra" är,
som jag berör ovan, även det en styrka.

Eftersom vi redan frossar i usla liknelser, så vill jag jämföra att
lära sig att köra skogsrally jämfört med att köra tunnelbanetåg. Det
sistnämnda lär man sig säkert fortare, men man kan inte svänga.

Den dag jag känner att är fullärd på CL så gör jag nog någonting
annat. Det är ju att lära sig nya saker som är det roliga.


Björn

[Sunnan]

Björn Lindberg wrote:

>Perl är att ha tusen prylar som egentligen inte alls har med bakning
>tillhands, typ ett par badtofflor, en stekspade, en ask gummisnoddar
>och så vidare. :-)
>
>
Ja, så kan det säkert vara. Läste du min "hyllning" till perl i cll nyligen?

Message-ID: <iGN8e.134869$***@newsc.telia.net>


>>Jag tror (nb: tror, inte vet) att en som har vana från att jobba med
>>lisp-1 oftare använder programmeringstekniker som de i
>>SICP. Funktioner som returnerar funktioner som returnerar funktioner.
>>
>>
>
>Så kan det säkert vara, men det tror jag har med andra skillnader att
>göra, både kulturella och rent dogmatiska. Dels är schemekulturen mer
>dogmatisk kring funktionell programmering, rekursion o.dyl.,
>
Ja, den stolliga dogmatiken gäller det att stålsätta sig mot. Jag är en
glad set!-användare.

> dels har
>CL-programmeraren helt enkelt mer i verktygslådan: dynamiska
>variabler, CLOS, conditionsystemet, etc. Medan schemeprogrammeraren
>funderar på hur han kan bygga om sin iteration till en rekursion har
>CL-programmeraren redan skrivit den med DOLIST eller LOOP och gått
>vidare. :-)
>
>
När man håller på med sånt tjafs är det ju bara på lek.
OBS OBS OBS! do finns i scheme-standarden och har funnits sedan
sjuttiotalet.
Jag använder sällan rekursion för att uttrycka iteration; oftast
använder jag srfi-42.
Jag använder knappast ens explicit rekursion för rekursion, om det går
att skriva med en variant av fold.
Ibland tycker jag att det kan bli snyggt med att använda rekursion som
iteration, som t.ex. följande funktion som returnerar ett tal i
fibonaccisekvensen varje gång den anropas:

(define (fib)
(let loop ((i 1) (j 1))
(yield j)
(loop (+ j i) i)))

Den skulle man ju kunna göra med iteration om man vill, eftersom det är
en rent iterativ process.

>(Låt mig förekomma invändningen att Scheme visst har alla dessa
>verktyg i mer eller mindre exotiska SRFI:er: det fina med CL är inte
>bara att alla dessa saker finns till hands, utan även att de passar
>ihop så bra med varandra.
>

Men passar de dåligt ihop i scheme, menar du?

>
>
>>I scheme är det enda man behöver komma ihåg hur en lambda fungerar.
>>
>>Exempel:
>>
>>(define (make-grower)
>> (let ((s 0))
>> (lambda ()
>> (set! s (add1 s))
>> s)))
>>
>>(define gen-id (make-grower))
>>
>>Det här går att göra i CL med motsvarande mängd kod, men jag har
>>FORTFARANDE inte memorerat hur man gör - och i den mån den
>>programmeringstekniken används är det (tror jag) på grund av schemare
>>som infört detta till CL, eller CL:are som läst t.ex. SICP.
>>
>>
>
>Redan din inställning här förklarar nog till stor del skillnaden. Jag
>ser inget egenvärde i att skriva extremt funktionell/applikativ kod om
>det inte löser problemet bättre. Det är bara *ett* verktyg i lådan.
>
>(Så här skulle det se ut i CL:
>
> (defun make-grower ()
> (let ((s 0))
> #'(lambda () (incf s))))
>)
>
>
Alltså, mitt exempel hade lika gärna kunnat vara

(define (make-grower)
(let ((s 0))
(lambda ()
(incf s))))

om man så vill, och om man har en incf.

(define-syntax incf
(syntax-rules ()
((_ n)
(set! n (add1 n)))))

Men vad jag fortfarande inte hade memorerat var om huruvida jag skulle använda let eller labels, om jag skulle använda #' eller funcall, om mina growers behöver använda funcall, etc etc.

(defun gen-id (make-grower))
ERROR ERROR ERROR

(setq gen-id (make-grower))
ERROR ERROR ERROR

Efter ett och ett halvt år sedan vi sist talade om detta har det fortfarande inte gått in i min skalle! "Lättlärt?" Inte jämfört med scheme:n.

>>Jag såg att du hade använt det liknande, klassiska
>>make-bank-account-exemplet, som är ett exempel på denna
>>programmeringsteknik. Du valde att göra ett macro för att dölja
>>funcall!
>>
>>
>
>Nej. Makrot var för att man skulle slippa skriva 'meddelande i
>anropet. Syntaktiskt socker med andra ord. SEND kunde lika gärna varit
>en funktion.
>
>
>
>>I scheme blir defparameter en vanlig define, defun blir en vanlig
>>define, funcall behövs inte, send behövs inte... ((konto 'withdraw)
>>80) är allt man behöver. (Jag gjorde en gång i tiden ett macro på
>>detta som gjorde att man kunde skriva (withdraw konto 80) a la
>>clos. Men det är överkurs.)
>>
>>
>
>Scheme har sina brister det med. Inre DEFINE t.ex.
>
Detta ska ändras med R6RS.

>eller BEGIN:s olika
>semantik i olika situationer.
>
>
Ja, verkligen!
Men det handlar inte om scheme vs CL. Det handlar om lisp-1 vs lisp-2.

>Två fördelar jag ser med CL:s lisp-2-aktighet:
>
> - Det visar sig att lisp-2 passar väldigt bra med DEFMACRO, och jag
> råkar tycka att DEFMACRO är ett väldigt bra sätt att definiera
> makron på.
>
>
Problemet med defmacro är namnrymder överlag. Det bör man lösa med något
generellt sätt (modules?), inte med en godtycklig indelning i funktioner
och värden.

Jag har i cls föreslagit en lösning som är defmacro-liknande men där
alla identifiers utom de man explicit anger är i en annan namnrymd,
specifikt för det macrot. Ett stort flamewar inleddes som slutade med
att någon praktiskt implementerade mitt förslag!

> - Symboler i CL är riktiga datastrukturer, istället för att bara
> vara namn som de är i Scheme.
>
>
Det är väl en nackdel, inte en fördel?

>Och hur kraftfullt och användbart tror du att ett språk är som man kan
>lära sig helt på en vecka?
>
Jag tror att det är så in i helvete kraftfullt. Igen, exemplet med go vs
schack.

Jag tror inte att 6.001 (kursen "SICP" på MIT) skulle gå att göra på
samma tid med CL.

[Björn Lindberg]

Sunnan <***@handgranat.org> writes:

> Björn Lindberg wrote:

> Jag använder sällan rekursion för att uttrycka iteration; oftast
> använder jag srfi-42.
> Jag använder knappast ens explicit rekursion för rekursion, om det går
> att skriva med en variant av fold.
> Ibland tycker jag att det kan bli snyggt med att använda rekursion som
> iteration, som t.ex. följande funktion som returnerar ett tal i
> fibonaccisekvensen varje gång den anropas:
>
> (define (fib)
> (let loop ((i 1) (j 1))
> (yield j)
> (loop (+ j i) i)))
>
> Den skulle man ju kunna göra med iteration om man vill, eftersom det
> är en rent iterativ process.

Är yield standard i Scheme?

> >(Låt mig förekomma invändningen att Scheme visst har alla dessa
> >verktyg i mer eller mindre exotiska SRFI:er: det fina med CL är inte
> >bara att alla dessa saker finns till hands, utan även att de passar
> >ihop så bra med varandra.
> >
>
> Men passar de dåligt ihop i scheme, menar du?

Jag erkänner villigt att jag inte har lika stor praktisk erfarenhet av
Scheme, men jag får intrycket att Scheme inte är lika
"sammanhängande". Det finns t.ex. inget välintegrerat
objektsystem. Det finns inget paketsystem. Lisp-1-igheten tvingar fram
bizarra makrolösningar. Och så vidare.

> Men vad jag fortfarande inte hade memorerat var om huruvida jag
> skulle använda let eller labels, om jag skulle använda #' eller
> funcall, om mina growers behöver använda funcall, etc etc.
>
> (defun gen-id (make-grower))
> ERROR ERROR ERROR
>
> (setq gen-id (make-grower))
> ERROR ERROR ERROR
>
> Efter ett och ett halvt år sedan vi sist talade om detta har det
> fortfarande inte gått in i min skalle! "Lättlärt?" Inte jämfört med
> scheme:n.

Skyll inte dina egna tillkortakommanden på språket. Det finns mängder
av CL:are som lärt sig detta, som motbevisar att det skulle vara
någonting överlag svårt. Du kan mer Scheme än jag, men inte tusan
gnäller jag om att Scheme skulle vara svårlärt för det. Jag har ju
bara valt att fokusera mitt intresse på CL.

> >>I scheme blir defparameter en vanlig define, defun blir en vanlig
> >>define, funcall behövs inte, send behövs inte... ((konto 'withdraw)
> >>80) är allt man behöver. (Jag gjorde en gång i tiden ett macro på
> >>detta som gjorde att man kunde skriva (withdraw konto 80) a la
> >>clos. Men det är överkurs.)
> >>
> >
> > Scheme har sina brister det med. Inre DEFINE t.ex.
> Detta ska ändras med R6RS.

Jaså. Hur då?

> >eller BEGIN:s olika
> >semantik i olika situationer.
> >
> Ja, verkligen!
> Men det handlar inte om scheme vs CL. Det handlar om lisp-1 vs lisp-2.
>
> >Två fördelar jag ser med CL:s lisp-2-aktighet:
> >
> > - Det visar sig att lisp-2 passar väldigt bra med DEFMACRO, och jag
> > råkar tycka att DEFMACRO är ett väldigt bra sätt att definiera
> > makron på.
> >
> Problemet med defmacro är namnrymder överlag. Det bör man lösa med
> något generellt sätt (modules?), inte med en godtycklig indelning i
> funktioner och värden.

Det är inte ett problem, enligt min mening. Eftersom man ibland vill
introducera namn med sina makron måste det gå. Visst kan man tycka att
utgångsläget skulle vara det motsatta (att introducerade namn hämtas
från makrodefinitionens lexikala omgivning), men om det måste ske till
priset av att göra defmacro mer komplicerad tycker jag inte att det är
värt det. En van lispare gör aldrig misstag av denna sort.

> Jag har i cls föreslagit en lösning som är defmacro-liknande men där
> alla identifiers utom de man explicit anger är i en annan namnrymd,
> specifikt för det macrot. Ett stort flamewar inleddes som slutade med
> att någon praktiskt implementerade mitt förslag!

Det fanns tydligen ett förslag för Scheme om så kallade syntaktiska
omslutningar. Kanske något i stil med ditt förslag?

> > - Symboler i CL är riktiga datastrukturer, istället för att bara
> > vara namn som de är i Scheme.
> >
> Det är väl en nackdel, inte en fördel?

Nej, det är en fördel.

> >Och hur kraftfullt och användbart tror du att ett språk är som man kan
> >lära sig helt på en vecka?
> >
> Jag tror att det är så in i helvete kraftfullt. Igen, exemplet med go
> vs schack.

Här pratade jag inte om Scheme/CL utan om något primitivare. Om man
skulle lära sig Scheme + CLOS + paketsystem + conditionsystem +
... skulle det ta lika lång tid som CL. Att dessa fantastiska verktyg
/saknas/ har jag svårt att se som en fördel.

Jag tycker förstås inte att inlärningstid är ett viktigt mått på ett
programmeringsspråk. Man lär sig språket endast en gång, men använder
det tusentals gånger, så jag föredrar att optimera för det senare.

> Jag tror inte att 6.001 (kursen "SICP" på MIT) skulle gå att göra på
> samma tid med CL.

Nu är ju den boken väldigt Schemecentrerad.


Björn

[Peter Lewerin]

Björn Lindberg wrote:

>Sunnan <***@handgranat.org> writes:
>
> > Problemet med defmacro är namnrymder överlag. Det bör man lösa med
> > något generellt sätt (modules?), inte med en godtycklig indelning i
> > funktioner och värden.

Jag missunnar dig inte att tycka om Lisp-1, men snälla nån! Indelningen i
funktioner och värden är absolut inte godtycklig, utan naturlig (och
förekommer även utanför programmeringsområdet).

> > Jag tror inte att 6.001 (kursen "SICP" på MIT) skulle gå att göra på
> > samma tid med CL.
>
>Nu är ju den boken väldigt Schemecentrerad.

Man kan t o m säga att Scheme och SICP är konstruerade för att matcha
varandra. :-)

[Björn Lindberg]

Peter Lewerin <***@swipnet.se> writes:

> Björn Lindberg wrote:
>
> >Sunnan <***@handgranat.org> writes:
> >
> > > Problemet med defmacro är namnrymder överlag. Det bör man lösa med
> > > något generellt sätt (modules?), inte med en godtycklig indelning i
> > > funktioner och värden.
>
> Jag missunnar dig inte att tycka om Lisp-1, men snälla nån!
> Indelningen i funktioner och värden är absolut inte godtycklig, utan
> naturlig (och förekommer även utanför programmeringsområdet).

Just så. Och skälet till att defmacro fungerar dåligt i Scheme är ju
just att Scheme inte gör skillnad på funktioner och värden fast de är
olika sorters entiteter. Detta försöker man då lösa på andra sätt, men
det ena är knappast mer "naturligt" eller självklart än det andra.


Björn

[Peter Lewerin]

>Exempel:
>
>(define (make-grower)
> (let ((s 0))
> (lambda ()
> (set! s (add1 s))
> s)))
>
>(define gen-id (make-grower))
>
>Det här går att göra i CL med motsvarande mängd kod,

Mmm.

(defun make-grower ()
(let ((s 0))
(lambda ()
(incf s))))

(defvar gen-id (make-grower))

(loop repeat 10 collect (funcall gen-id))
=> (1 2 3 4 5 6 7 8 9 10)

Snyggt och prydligt.

> men jag har FORTFARANDE inte memorerat hur man gör - och i den mån den
> programmeringstekniken används är det (tror jag) på grund av schemare som
> infört detta till CL, eller CL:are som läst t.ex. SICP.

Tekniken är äldre än såväl Scheme som CL och används inom båda grupperna.

>I scheme blir defparameter en vanlig define, defun blir en vanlig define,
>funcall behövs inte,

Vi *vet*. För dig är det där fördelar med Scheme. För mig, och tror jag
många andra, är det några av anledningarna till att vi undviker Scheme.

[Sunnan]

Peter Lewerin wrote:

>
>> Exempel:
>>
>> (define (make-grower)
>> (let ((s 0))
>> (lambda ()
>> (set! s (add1 s))
>> s)))
>>
>> (define gen-id (make-grower))
>>
>> Det här går att göra i CL med motsvarande mängd kod,
>
>
> Mmm.
>
> (defun make-grower ()
> (let ((s 0))
> (lambda ()
> (incf s))))
>
> (defvar gen-id (make-grower))
>
> (loop repeat 10 collect (funcall gen-id))
> => (1 2 3 4 5 6 7 8 9 10)
>
> Snyggt och prydligt.

I scheme blir det sista (som du säkert vet)
(loop repeat 10 collect (gen-id))
=> (1 2 3 4 5 6 7 8 9 10)

Det vill säga, man behöver inte ha en stor lista utskriven och upptejpad
på väggen som säger vilka identifiers man ska köra funcall på och vilka
som bara är att köra.

>> men jag har FORTFARANDE inte memorerat hur man gör -
>
Obs, obs - här blottar jag min trögfatthet för att visa på lisp-2s
svårlärdhet jämfört med lisp-1. Väldigt skamligt och traumatiskt, detta,
visa lite barmhärtighet.

>> och i den mån den programmeringstekniken används är det (tror jag) på
>> grund av schemare som infört detta till CL, eller CL:are som läst
>> t.ex. SICP.
>
>
> Tekniken är äldre än såväl Scheme som CL och används inom båda grupperna.

Ja, Algol. Men det var GLS och Gerry Sussman som införde detta till
lispvärlden.

>> I scheme blir defparameter en vanlig define, defun blir en vanlig
>> define, funcall behövs inte,
>
>
> Vi *vet*. För dig är det där fördelar med Scheme. För mig, och tror
> jag många andra, är det några av anledningarna till att vi undviker
> Scheme.

Om du tycker att det är acceptabelt att ha id-genererar-funktionen i
värdecellen till identifieraren gen-id, så är din lösning enkel. Tommy
har fortfarande inte fått svar på sin fråga, så vitt jag förstår.

Obs, jag vet att det är ett krystat exempel, CL:are använder kanske en
defparameter *id* som de incf-ar, istället för att göra en closure - men
jag ville ha något enkelt att visa på. Som samtidigt kanske visar att
CL:are använder closures mer sällan.

[Björn Lindberg]

Sunnan <***@handgranat.org> writes:

> > (loop repeat 10 collect (funcall gen-id))
> > => (1 2 3 4 5 6 7 8 9 10)
> >
> > Snyggt och prydligt.
>
> I scheme blir det sista (som du säkert vet)
> (loop repeat 10 collect (gen-id))
> => (1 2 3 4 5 6 7 8 9 10)
>
> Det vill säga, man behöver inte ha en stor lista utskriven och
> upptejpad på väggen som säger vilka identifiers man ska köra funcall
> på och vilka som bara är att köra.

Det är ju bara för att du inte greppat detta (än).

> >> och i den mån den programmeringstekniken används är det (tror jag)
> >> på grund av schemare som infört detta till CL, eller CL:are som
> >> läst t.ex. SICP.
> >
> >
> > Tekniken är äldre än såväl Scheme som CL och används inom båda grupperna.
>
> Ja, Algol. Men det var GLS och Gerry Sussman som införde detta till
> lispvärlden.

Nej, det tror jag inte. Scheme var så vitt jag vet inte den första
lispen med lexikal bindning.

> >> I scheme blir defparameter en vanlig define, defun blir en vanlig
> >> define, funcall behövs inte,
> >
> >
> > Vi *vet*. För dig är det där fördelar med Scheme. För mig, och
> > tror jag många andra, är det några av anledningarna till att vi
> > undviker Scheme.
>
> Om du tycker att det är acceptabelt att ha id-genererar-funktionen i
> värdecellen till identifieraren gen-id, så är din lösning enkel. Tommy
> har fortfarande inte fått svar på sin fråga, så vitt jag förstår.
>
> Obs, jag vet att det är ett krystat exempel, CL:are använder kanske en
> defparameter *id* som de incf-ar, istället för att göra en closure -
> men jag ville ha något enkelt att visa på. Som samtidigt kanske visar
> att CL:are använder closures mer sällan.

Om du prompt vill göra detta, så *kan* du sätta funktionscellen som
någon redan visat. Personligen tycker jag att det är ett sökt exempel.


Björn

[d***@nada.kth.se]

> On Fri, 29 Apr 2005 d95-***@nada.kth.se wrote:
>
>>>> Det kanske är användbart för folk som egentligen
>>>> inte kan programmera, men som vill slänga ihop ett program som i
>>>> medvind
>>>> och nedförsbacke fungerar *nästan* som avsett.
>>>>
>>> Det är väl en stor och viktig grupp människor?
>>
>> Nej, tvärtom. De producerar ju bara skräp. Problemet med CPAN, och för
>> all
>> del Perl som helhet, är att det uppmuntrar ett beteende som resulterar i
>> undermålig programvara. Jag ser inget värde i det.
>
> Perl uppmuntrar hackande, hoppa in huvudet först. Anything goes och du
> måste inte hålla en massa ordning på datatyper. Det är inte dåligt
> egentligen. Det gör att folk kan producera kod i ett rasande tempo och
> lära sig programmera. Problemet är förstås att man efter en tid måste ha
> lite guidning för att inte fastna i träsket av fulhack.

Mitt Lispkodande har litet av yin och yang över sig. Perioder av
entropiökande utforskningar och hackande åtföljs av perioder av
strukturerande, definition av gränssnitt. Perl är väl mest yin.

> Lisp har många av samma styrkor som perl, med interaktivt utvecklande
> och enkla datatyper. Starta en REPL och du är igång.

Skillnaden är att lisp uppmuntrar till och belönar bra kod. Perl gör
tvärtom. När en Perlprogrammerare klappar sig på ryggen och känner sig
riktigt duktig är det för att han/hon just presterat något riktigt fult
eller gräsligt. Alla 'fiffiga' egenskaper hos perl som perlare typiskt är
så stolta över är undantagslöst saker som leder till dålig kod.


Björn

[Lars Brinkhoff]

Sunnan <***@handgranat.org> writes:
> Jag vet ingen programmeringsspråksnyhetsgrupp som är lika lättantändlig
> som cll.

d95-***@nada.kth.se wrote:
> > Helgens eurolispmöte var i alla avseenden ytterst odysfunktionellt. :-)
> Det glädjer mig att höra. Jag tänker att det har blivit bättre på sistone.

Det kanske är en delmängd av comp.lang.lisp som är dysfunktionell,
snarare än lispprogrammerare i allmänhet?

[Sunnan]

Lars Brinkhoff wrote:

>Det kanske är en delmängd av comp.lang.lisp som är dysfunktionell,
>snarare än lispprogrammerare i allmänhet?
>
>
Den formuleringen kan jag köpa, men notera att jag inte talar om
dysfunktionella individer utan om icke-fungerande grupper.

[Peter Lewerin]

>Uppriktigt sagt förstår jag inte riktigt uppståndelsen kring CPAN.

CPAN är ett magnifikt misslyckande EMRM. Under tiden som jag undervisade i
programmering provade jag ett flertal gånger att ta hem moduler därifrån
och använda dem. Nedladdning och insättning gick bra, men sedan började
svårigheterna med att förstå hur modulen skulle användas. Därefter visade
det sig för det mesta snart att modulen inte kunde göra det jag ville. I
slutändan satt jag alltid själv och skrev koden - CPAN hade bara kostat tid
och onödigt anpassningsarbete.

Det går förstås att göra det bättre. ActiveState hade om jag inte minns
fel ett förbättrat modulhanteringssystem med utvalda och föranpassade moduler.

> > intressant språkdesignprocess för perl 6.
>
>He he he. Vilket decennium som helst nu...

Isch. Isch! Perl 6 verkar ungefär lika användarvänligt som stegel och hjul.

[Peter Lewerin]

>Själv ställer jag mig utanför debatten, men konstaterar att jag ogillar IF*.

Mitt värsta IF*-minne är när jag en gång i tiden försökte portera en Lisp
till DOS, och många operatorer fanns i filer som hette detsamma som
operatorns symbol. :-)

[Lars Brinkhoff]

Peter Lewerin <***@swipnet.se> writes:
> (let (i j res)
> (tagbody
...

Inte för att jag vill uppmuntra till det, men här skulle du kunnat
använda "the program feature".

[d***@nada.kth.se]

> Peter Lewerin <***@swipnet.se> writes:
>> (let (i j res)
>> (tagbody
> ...
>
> Inte för att jag vill uppmuntra till det, men här skulle du kunnat
> använda "the program feature".

Låt i så fall mig uppmuntra till det: Använd PROG!


Björn

[Peter Lewerin]

At 19:00 2005-04-27, you wrote:

>Inte för att jag vill uppmuntra till det, men här skulle du kunnat
>använda "the program feature".

Kanske bäst att påpeka att jag på intet sätt är en inbiten
TAGBODY-programmerare :-)

Jag skrev TAGBODYn och smäckte på en LET utanpå utan att tänka på
PROG. Blir rätt ekvivalent hur som helst (förutom BLOCKet).

[d***@nada.kth.se]

> At 19:00 2005-04-27, you wrote:
>
>>Inte för att jag vill uppmuntra till det, men här skulle du kunnat
>>använda "the program feature".
>
> Kanske bäst att påpeka att jag på intet sätt är en inbiten
> TAGBODY-programmerare :-)

Det är förstås inget fel på TAGBODY.


Björn

[Peter Lewerin]

>Det är förstås inget fel på TAGBODY.

Nej, men det finns sammanhang där användning av TAGBODY antyder att
programmeraren antingen inte riktigt förstått uppgiften, eller också är
lite skämtsam.

Annars är det förstås så att CL bokstavligen står och faller med
TAGBODY. Fast oftast inuti makron, då.

[d***@nada.kth.se]

> Lars Brinkhoff wrote:
>
>>Sunnan skrev:
>>
>>
>>>För något år sedan (ett och ett halvt, kanske?) hängde jag i både cls
>>>och cll, men så slutade jag programmera och då orkade jag inte hänga i
>>>nyhetsgrupperna heller.
>>>
>>>
>>
>>Välkommen! Jag har fått ett intryck av att CL är mest populärt på
>>denna listan, men jag tror att både CL:arse och Schemare kan samsas
>>här.
>>
>>
>>
> Jag läste lite i arkivet och såg att en gammal nätbekant, Björn, som jag
> har tappat kontakt med hänger här. DKJA.

Jupp.

>>[Något helt annat: Fick "Practical Common Lisp" i brevlådan i fredags.
>>Kanske första exemplaret i Sverige?]

Säkert. Jag fick min på Lispmötet i Amsterdam i helgen, men den är i
München där jag numer bor. Min är förstås signerad. :-)

> Obs, obs: Den finns även på nätet, som man kan läsa medan man väntar på
> att den ska komma.
>
> Obs, obs, pt. 2; Jag har en fråga om LOOP.
> Kan man, med en enda loop, uttrycka nästlade loopar eller bara parallella?

Bara parallella.

> T.ex. med srfi-42 kan man göra:
> (list-ec (: i 7) (: j 3) (list i j)) =>
> ((0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2) (3 0) (3 1) (3 2)
> (4 0) (4 1) (4 2) (5 0) (5 1) (5 2) (6 0) (6 1) (6 2))
>
> Hur skulle man uttrycka detta med LOOP, om det går?
> I regel föredrar jag srfi-42 över LOOP (när man inte använder tail calls
> eller do-varianter), men "it's standing on the shoulders of giants" -
> srfi-42 är ju ganska mycket yngre än LOOP.

Jag skulle göra:

(loop with result
for i from 0 to 6
do (loop for j from 0 to 2
do (push (list i j) result))
finally (return (reverse result)))

Det är förmodligen vanligare att listorna man vill iterera över redan
finns, och då skulle jag kanske skriva

(let ((list1 '(0 1 2 3 4 5 6))
(list2 '(0 1 2)))

(mapcan #'(lambda (i) (mapcar #'(lambda (j) (list i j))
list2))
list1))


Björn

[Lars Brinkhoff]

d95-***@nada.kth.se writes:
> Jag fick min på Lispmötet i Amsterdam i helgen

Det verkar ha varit ett lyckat möte. Jag ångrar lite att jag inte var
där.

Någon som tänker åka till "2nd European LISP and Scheme Workshop"?

[d***@nada.kth.se]

> d95-***@nada.kth.se writes:
>> Jag fick min på Lispmötet i Amsterdam i helgen
>
> Det verkar ha varit ett lyckat möte. Jag ångrar lite att jag inte var
> där.
>
> Någon som tänker åka till "2nd European LISP and Scheme Workshop"?

Tanken har slagit mig, men jag vet inte än.


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Det är förmodligen vanligare att listorna man vill iterera över redan
>finns, och då skulle jag kanske skriva
>
>(let ((list1 '(0 1 2 3 4 5 6))
> (list2 '(0 1 2)))
>
> (mapcan #'(lambda (i) (mapcar #'(lambda (j) (list i j))
> list2))
> list1))
>
>
>
>
Jag har kunnat städa upp en del av min gamla kod med trefaldigt nästlade
maps med srfi-42. Härligt!

[d***@nada.kth.se]

> d95-***@nada.kth.se wrote:
>
>>Det är förmodligen vanligare att listorna man vill iterera över redan
>>finns, och då skulle jag kanske skriva
>>
>>(let ((list1 '(0 1 2 3 4 5 6))
>> (list2 '(0 1 2)))
>>
>> (mapcan #'(lambda (i) (mapcar #'(lambda (j) (list i j))
>> list2))
>> list1))
>>
>>
>>
>>
> Jag har kunnat städa upp en del av min gamla kod med trefaldigt nästlade
> maps med srfi-42. Härligt!

Ja, hade jag i ett program behov av att göra det ofta skulle jag
naturligtvis abstrahera det med en funktion eller ett makro på några
rader. En kollega till mig som på sistone fipplat litet med ett
bildbehandlingsprogram har ett makro i stil med

(with-rgb *image*
(* r 0.5)
(* g 0.5)
(* b 0.5))

vilket itererar över hela bilden och modifierar bildpunkterna.


Björn

[Sunnan]

d95-***@nada.kth.se wrote:

>Ja, hade jag i ett program behov av att göra det ofta skulle jag
>naturligtvis abstrahera det med en funktion eller ett makro på några
>rader. En kollega till mig som på sistone fipplat litet med ett
>bildbehandlingsprogram har ett makro i stil med
>
>(with-rgb *image*
> (* r 0.5)
> (* g 0.5)
> (* b 0.5))
>
>vilket itererar över hela bilden och modifierar bildpunkterna.
>
>
Jo, jag har haft liknande grejer igång i min gamla spritemotor, som
dessutom sköter deallokering av surfaces och grejer när det inte har
skötts av gc:n.

[Ingvar]

Scripsit Sunnan:
> d95-***@nada.kth.se wrote:
>
> >Det är förmodligen vanligare att listorna man vill iterera över redan
> >finns, och då skulle jag kanske skriva
> >
> >(let ((list1 '(0 1 2 3 4 5 6))
> > (list2 '(0 1 2)))
> >
> > (mapcan #'(lambda (i) (mapcar #'(lambda (j) (list i j))
> > list2))
> > list1))
> >
> >
> >
> >
> Jag har kunnat städa upp en del av min gamla kod med trefaldigt nästlade
> maps med srfi-42. Härligt!

Lite makrohack senare:

* (LIST-COMPREHENSE (:PARALLEL (I 7) (J 3)) (LIST I J))

((0 0) (1 1) (2 2))
* (list-comprehense ((i 7) (j 3)) (list i j))

((0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2) (3 0) (3 1) (3 2) (4 0)
(4 1) (4 2) (5 0) (5 1) (5 2) (6 0) (6 1) (6 2))

[ saknar svenska tecken... ]

Klarar "bara" 0..x och valen "parallellt eller icke".

(defmacro list-comprehense (spec &body body)
(let ((para (eql (car spec) :parallel))
(spec (if (symbolp (car spec))
(cdr spec)
spec)))
(if para
(let ((loopform (loop for (var max) in spec
append (list 'for var 'below max))))
`(loop ,@loopform
collect (progn ,@body)))
(let ((head (car spec))
(tail (cdr spec)))
(if (null (cdr spec))
`(loop for ,(car head) below ,(cadr head)
collect (progn ,@body))
`(loop for ,(car head) below ,(cadr head)
append (list-comprehense ,tail ,@body)))))))

Kodsignatur:

(list-comprehense ([:parallel] (<var> <max>) [(<var> <max>) ...]) <form> ...)

//ingvar

[d***@nada.kth.se]

> fre 2005-04-29 klockan 13:24 +0200 skrev Sunnan:
>> Arthur Lemmens wrote:
>>
>> > Personally, I think that would have been worse. I like to have a
>> big,
>> > well-defined vocabulary. That makes it easier to communicate with the
>> > compiler, with other programmers and even with myself at a later
>> stage.
>> >
>> > The Schemers on this list will feel differently about this, I suppose
>> ;-)
>>
>> Jag tycker om att ha sådana grejer i bibliotek, inte i själva
>> språkstandarden.
>> Varenda schemare använder väl srfi-1 någon gång, men kanske inte
>> hela tiden.
>
> Ungefär som Java då, där man har en enorm mängd återanvändningsbara
> bibliotek som alla kan använda. Om man behöver en funktionalitet så
> lockar man hem ett bibliotek som (kanske) gör det man vill så slipper
> man implementera det själv. Jag skulle vilja påstå att det är detta
> som
> gör Java (mer) användbart (än andra språk).

Det är definitivt Javas styrka. Den stora skillnaden är att Sun ligger
bakom Javabiblioteken, vilket fyller två funktioner:

1) Det etablerar en standard.

2) Det tillser att biblioteken håller en rimligt god kvalitet.

> Det är väl detta behov som CPAN uppfyller i Perl-världen.

CPAN uppfyller (1) ovan, men knappast (2). CL börjar informellt få en stor
gemensam kodbas, bl.a. genom common-lisp.net, ASDF, etc. Alla dessa
bibliotek är av god kvalitet.


Björn

[Tommy Hallgren]

--- d95-***@nada.kth.se wrote:
> Skillnaden är att lisp uppmuntrar till och belönar bra kod. Perl gör
> tvärtom. När en Perlprogrammerare klappar sig på ryggen och känner sig
> riktigt duktig är det för att han/hon just presterat något riktigt fult
> eller gräsligt. Alla 'fiffiga' egenskaper hos perl som perlare typiskt är
> så stolta över är undantagslöst saker som leder till dålig kod.

Synd att Erik Naggum inte längre skriver i cll, han skriver många tänkvärda
saker. T.ex. sa han något i still med att en Perlprogramerare känner sig nöjd
efter en arbetsdag. Många problem blev lösta.

Det som Perlprogrameraren inte har insett är att det är problem som inte skulle
finnas från första början.

Så Perl är bra på att lösa problem som inte borde finnas. Kul va? :-)

Mvh, Tommy - Numera med en Mac

[Peter Lewerin]

>Synd att Erik Naggum inte längre skriver i cll, han skriver många tänkvärda
>saker.

Jag gillar hans kommentar att Perl kanske inte är ett språk för idioter,
men det är i alla fall ett språk som uppmuntrar idioti mer än de flesta
andra gör.

EN skrev mycket som var tänkvärt och läsvärt; okonventionella saker som
slaktade många heliga kor ("XML is a giant step in no direction at all")
och annorlunda visioner om hur "databehandling" (i brist på bättre term)
skulle kunna se ut om vi bara kunde släppa vissa förutfattade meningar.

Jag uppskattade det mesta han skrev, även om det var svårt att tycka om
allt. Tyvärr skapade han samtidigt en hel del bråk på c.l.l., dels genom
sin egen ovänlighet, dels därför att många andra där inte gillade att deras
världsbild, arbetssätt och prestationer ifrågasattes på det sättet.

[Tommy Hallgren]

--- Peter Lewerin <***@swipnet.se> wrote:
>
> >Synd att Erik Naggum inte längre skriver i cll, han skriver många tänkvärda
> >saker.
>
> Jag gillar hans kommentar att Perl kanske inte är ett språk för idioter,
> men det är i alla fall ett språk som uppmuntrar idioti mer än de flesta
> andra gör.

Sant, men just tanken att man är duktig på att lösa problem som inte borde
finnas alls, fascinerande. Många förstår nog inte alls vad han menar, för
"loggfilen är ju i detta formatet".

> EN skrev mycket som var tänkvärt och läsvärt; okonventionella saker som
> slaktade många heliga kor ("XML is a giant step in no direction at all")
> och annorlunda visioner om hur "databehandling" (i brist på bättre term)
> skulle kunna se ut om vi bara kunde släppa vissa förutfattade meningar.
>
> Jag uppskattade det mesta han skrev, även om det var svårt att tycka om
> allt. Tyvärr skapade han samtidigt en hel del bråk på c.l.l., dels genom
> sin egen ovänlighet, dels därför att många andra där inte gillade att deras
> världsbild, arbetssätt och prestationer ifrågasattes på det sättet.

Prova att söka efter "Erik Naggum mental illness" i Google Groups. Haha.

Även på IRC finns det en massa folk som har överdrivet starka åsikter. Ibland
är det nästan löjligt hur fort någon som försöker komma in i gänget blir
renrakad och påstruken saltat rakvatten.

Erik var den som fick mig att titta på Common Lisp. Jag höll på med Scheme och
tyckte utan att veta bättre att Scheme var en renare och modernade dialekt av
Lisp, att Common Lisp var full av gammalt arv osv.

Idag ser jag på det hela mer som att man bör börja med Common Lisp och att
Scheme är mer som ett verktyg man tar fram när det passar. T.ex. för att göra
ett in-game skriptspråk/ssytem.

Mvh, Tommy

[Sunnan]

Tommy Hallgren wrote:

>Erik var den som fick mig att titta på Common Lisp. Jag höll på med Scheme och
>tyckte utan att veta bättre att Scheme var en renare och modernade dialekt av
>Lisp, att Common Lisp var full av gammalt arv osv.
>
>Idag ser jag på det hela mer som att man bör börja med Common Lisp och att
>Scheme är mer som ett verktyg man tar fram när det passar. T.ex. för att göra
>ett in-game skriptspråk/ssytem.
>
>
Jag är glad att jag bytte till Scheme.

[Tommy Hallgren]

--- Sunnan <***@handgranat.org> wrote:
> Jag är glad att jag bytte till Scheme.

Jag blev trött på Scheme för att det i standarden inte fanns saker som
namnrymder, oo och en massa trevliga bekvämligheter som t.ex. loop, format.

Varför är du så glad över att du bytte till Scheme? Vad bytte du ifrån?

Mvh, Tommy

[Sunnan]

Tommy Hallgren wrote:

>--- Sunnan <***@handgranat.org> wrote:
>
>
>>Jag är glad att jag bytte till Scheme.
>>
>>
>
>Jag blev trött på Scheme för att det i standarden inte fanns saker som
>namnrymder, oo och en massa trevliga bekvämligheter som t.ex. loop, format.
>
>
Men om det finns en bsd-licensierad implementation som funkar med de
flesta schemar - som det gör av loop, format, oo - då är väl allt lugnt?
Jag tycker inte att det tillför något att standardisera dessa
kontroversiella områden. Läs t.ex. Gabriels kritik av FORMAT. Jag är
dessutom en inbiten LOOP-hatare.
En bra generell lösning på namnrymdsfrågan skulle dock vara intressant.
Det lutar åt att R6RS har lite good shit på gång där.

>Varför är du så glad över att du bytte till Scheme?
>
Att den inte mucklar med Separation in Function Cells and Value Cells,
som emacs-lisp och CL gör. Det gucket är nog det värsta jag vet i
programmeringsväg. Jag kan nog byta bort mycket annat bara jag slipper
det. (Obs, obs! Jag har förstått att en del tycker om det.)

>Vad bytte du ifrån?
>
>
Emacs-lisp! Ahahahahaha! Även librep hade jag drabbats av.

[Tommy Hallgren]

--- Sunnan <***@handgranat.org> wrote:

Båda Björn och Sunnan har en poäng. Programmeringsstil spelar ju såklart roll
om lisp-2 är opraktiskt eller ej.

När jag var en fan av Scheme kände jag ofta att CL var en gammal harv och att
det fanns så himla många problem med CL.

Idag känner jag att det största problemet är att det inte finns till Windows,
Mac och Linux ett Common Lisp-paket som är open source, har vettiga libraries
för nätverk, trådar, grafik, xml, webb osv.

Common Lisp känns som ett hackerverktyg, du har saker som (disassemble ...) hur
coolt är inte det?

> (define (make-grower)
> (let ((s 0))
> (lambda ()
> (set! s (add1 s))
> s)))
>
> (define gen-id (make-grower))
>
> Det här går att göra i CL med motsvarande mängd kod, men jag har
> FORTFARANDE inte memorerat hur man gör - och i den mån den
> programmeringstekniken används är det (tror jag) på grund av schemare
> som infört detta till CL, eller CL:are som läst t.ex. SICP.

Här håller jag med, jag vet inte hur jag kan skapa en funktion gen-id i Common
Lisp på ett någorlunda rakt sätt. Vet någon?

Kanske:

(defun gen-id ()
(let ((generator (make-grover))
(funcall generator)))

?

> Jag såg att du hade använt det liknande, klassiska
> make-bank-account-exemplet, som är ett exempel på denna
> programmeringsteknik. Du valde att göra ett macro för att dölja funcall!

CLOS. :) Rätt tufft att kunna göra validering i :before och loggning i
:after-metoder.

> I scheme blir defparameter en vanlig define

define i Scheme är bara en pytteliten delmängd av vad defparameter och defvar
är. I Common Lisp markeras variabeln som "special" vilket betyder att den
alltid slås upp i en dynamisk omgivning snarare än den lexikala.

(defparameter *x* 0)

(defun print-x () (print *x*))

(defun test ()
(print-x)
(let ((*x* 666))
(print-x))
(print-x))

Kommer skriva ut 0, 666 och 0.

> CL *går* att lära sig, det går att göra det mesta schemare kan göra, men
> det *är* fler saker att minnas, fler saker som ska interagera med varandra.

Det var lättare för mig, då jag tröttnat på att i Scheme hitta på långa namn,
skapa egna datatyper och predikat för dem, var urttrött på att jobba rekursivt
för triviala saker. Dessutom fick jag ångest av alla implementationer. :)

För mig kändes CL precis som Erik Naggum sa, det är nåt man löser riktiga
problem i och skriver riktiga program i.

> En älskad vän försvarade Javas dålighet med att "det går ju typ att
> använda higher-order-functions-liknande grejer med anonyma
> predikatklasser och sånt, det blir ett par rader extra men det går ju
> att göra!". Mmm, men om man diskuterar just sakers lätt-att-lära-sig-het
> så är det bättre med några få enkla, väldigt flexibla beståndsdelar. Som
> Go vs Schack.

Haha, visst är det så, bara för ett språk är turningkomplett betyder ju inte
det att det går att göra snygga lösningar på svåra problem i det.

Mvh, Tommy

[Lars Brinkhoff]

Tommy Hallgren <***@yahoo.com> writes:
> --- Sunnan <***@handgranat.org> wrote:
>> (define gen-id (make-grower))
> jag vet inte hur jag kan skapa en funktion gen-id i Common Lisp på
> ett någorlunda rakt sätt. Vet någon?
>
> Kanske:
>
> (defun gen-id ()
> (let ((generator (make-grover))
> (funcall generator)))
>
> ?

Kanske

(setf (symbol-function 'gen-id) (make-grover))

?

[Sunnan]

Tommy Hallgren wrote:

>--- Sunnan <***@handgranat.org> wrote:
>
>Båda Björn och Sunnan har en poäng. Programmeringsstil spelar ju såklart roll
>om lisp-2 är opraktiskt eller ej.
>
>
Och så här tänker jag, som inbiten sapir-whorf:are, att en som använt
mycket lisp-1 säkert kan slå upp hur man gör lisp-1-iga grejer med CL,
men en som är uppfödd på lisp-2 inte skulle stumbla på lisp-1-iga
programmeringstekniker av misstag direkt. Man behöver en dos av SICP
eller dylikt.

>Idag känner jag att det största problemet är att det inte finns till Windows,
>Mac och Linux ett Common Lisp-paket som är open source, har vettiga libraries
>för nätverk, trådar, grafik, xml, webb osv.
>
>
Det kommer kanske.

>Common Lisp känns som ett hackerverktyg, du har saker som (disassemble ...) hur
>coolt är inte det?
>
>
Ja, det finns mycket som är otroligt coolt med CL och jag drömmer om att
mina älsklings-scheme-implementationer ska få de grejerna.

>
>
>>Jag såg att du hade använt det liknande, klassiska
>>make-bank-account-exemplet, som är ett exempel på denna
>>programmeringsteknik. Du valde att göra ett macro för att dölja funcall!
>>
>>
>
>CLOS. :) Rätt tufft att kunna göra validering i :before och loggning i
>:after-metoder.
>
>
Mmm, det går väl med tinyclos också, eller hur?

>define i Scheme är bara en pytteliten delmängd av vad defparameter och defvar
>är. I Common Lisp markeras variabeln som "special" vilket betyder att den
>alltid slås upp i en dynamisk omgivning snarare än den lexikala.
>
>(defparameter *x* 0)
>
>(defun print-x () (print *x*))
>
>(defun test ()
> (print-x)
> (let ((*x* 666))
> (print-x))
> (print-x))
>
>Kommer skriva ut 0, 666 och 0.
>
>
Jo, men hur gör man en vanlig variabel då, är det defvar, eller?

>Det var lättare för mig, då jag tröttnat på att i Scheme hitta på långa namn,
>
>
Är det lättare att hitta på namn i CL?

>skapa egna datatyper och predikat för dem, var urttrött på att jobba rekursivt
>för triviala saker.
>
Kunde du inte ha gjort lite härliga iterativa macron?

> Dessutom fick jag ångest av alla implementationer. :)
>
>
Vilken CL använder du, SBCL?

>För mig kändes CL precis som Erik Naggum sa, det är nåt man löser riktiga
>problem i och skriver riktiga program i.
>
>
Jag tycker att CLs eventuella robusthet är lite ortogonal mot
lisp-2/lisp-1-frågan, som är en viktig del av lättlärdheten med scheme.

[Ingvar]

Sunnan skriver:
> Tommy Hallgren wrote:
>
> >--- Sunnan <***@handgranat.org> wrote:
> >
> >Båda Björn och Sunnan har en poäng. Programmeringsstil spelar ju såklart roll
> >om lisp-2 är opraktiskt eller ej.
> >
> >
> Och så här tänker jag, som inbiten sapir-whorf:are, att en som använt
> mycket lisp-1 säkert kan slå upp hur man gör lisp-1-iga grejer med CL,
> men en som är uppfödd på lisp-2 inte skulle stumbla på lisp-1-iga
> programmeringstekniker av misstag direkt. Man behöver en dos av SICP
> eller dylikt.

Jag tror inte riktigt att det är fallet. Det är, liksom, givet att man leker
med de sakerna när man har lexikala omgivningar och man har dem ju.

[SNIP]
> >>Jag såg att du hade använt det liknande, klassiska
> >>make-bank-account-exemplet, som är ett exempel på denna
> >>programmeringsteknik. Du valde att göra ett macro för att dölja funcall!
> >>
> >>
> >
> >CLOS. :) Rätt tufft att kunna göra validering i :before och loggning i
> >:after-metoder.
> >
> >
> Mmm, det går väl med tinyclos också, eller hur?

Det beror på hur mycket av CLOS som implementeras/stöds. Förhoppningsvis...

> >define i Scheme är bara en pytteliten delmängd av vad defparameter och defvar
> >är. I Common Lisp markeras variabeln som "special" vilket betyder att den
> >alltid slås upp i en dynamisk omgivning snarare än den lexikala.
> >
> >(defparameter *x* 0)
> >
> >(defun print-x () (print *x*))
> >
> >(defun test ()
> > (print-x)
> > (let ((*x* 666))
> > (print-x))
> > (print-x))
> >
> >Kommer skriva ut 0, 666 och 0.
> >
> >
> Jo, men hur gör man en vanlig variabel då, är det defvar, eller?

Det är en sak som (naivt) inte finns i CL (top-level lexikala variabler),
eftersom den enda "globala" omgivningen som finns är "the null lexical
environment". OM man absolut vill ha dem kan man fejka dem m.h.a symbol-makron.

Skillnaden mellan DEFVAR och DEFPARAMETER är att DEFPARAMETER kommer att sätta
en dynamisk variabel oavsett om den är bunden eller inte.

* (defvar *sunnan-1* 1)

*SUNNAN-1*
* (defvar *sunnan-2* 1)

*SUNNAN-2*
* (defun sunnan-demo () (list *sunnan-1* *sunnan-2*))

SUNNAN-DEMO
* (sunnan-demo)

(1 1)
* (defvar *sunnan-1* 17)

*SUNNAN-1*
* (defparameter *sunnan-2* 42)

*SUNNAN-2*
* (sunnan-demo)

(1 42)


> >Det var lättare för mig, då jag tröttnat på att i Scheme hitta på långa namn,
> >
> >
> Är det lättare att hitta på namn i CL?
>
> >skapa egna datatyper och predikat för dem, var urttrött på att jobba rekursivt
> >för triviala saker.
> >
> Kunde du inte ha gjort lite härliga iterativa macron?

När jag senast seriöst kikade på Scheme fanns, så vitt jag vet, inget
helspecat makropaket, men det är ett decennium sedan sist.

> > Dessutom fick jag ångest av alla implementationer. :)
> >
> >
> Vilken CL använder du, SBCL?

Jag använder SBCL som primärplattform och Lispworks för kompatibiltetstest
(dock, jag använder SB-CLX, så jag slipper dubbelkoll på CLX-implementationen).

//Ingvar

[Björn Lindberg]

Ingvar <***@cathouse.bofh.se> writes:

> Skillnaden mellan DEFVAR och DEFPARAMETER är att DEFPARAMETER kommer
> att sätta en dynamisk variabel oavsett om den är bunden eller inte.

... och poängen är följande: Säg att du utvecklar ett program med en
databaskoppling. Då kanske du har en databasanslutning i variabeln
*database*. Om den definierades med DEFVAR så kan du hacka ditt
program interaktivt och ladda om filen med *database*-definitionen,
utan att du ideligen får en ny databasanslutning, eftersom den
behåller sitt värde.


Björn

[Björn Lindberg]

Tommy Hallgren <***@yahoo.com> writes:

> > I scheme blir defparameter en vanlig define
>
> define i Scheme är bara en pytteliten delmängd av vad defparameter och defvar
> är. I Common Lisp markeras variabeln som "special" vilket betyder att den
> alltid slås upp i en dynamisk omgivning snarare än den lexikala.

Bra poäng. DEFUN, DEFVAR, DEFPARAMETER och DEFCONSTANT gör alla olika
saker. Att Scheme använder define för dem alla betyder bara att Scheme
inte kan göra alla dessa olika saker.


Björn

[Tommy Hallgren]

--- Björn Lindberg <d95-***@nada.kth.se> skrev:
> Sunnan <***@handgranat.org> writes:
> > (define (make-grower)
> > (let ((s 0))
> > (lambda ()
> > (set! s (add1 s))
> > s)))
> >
> > (define gen-id (make-grower))
>
> (Så här skulle det se ut i CL:
>
> (defun make-grower ()
> (let ((s 0))
> #'(lambda () (incf s))))
> )

Björn, du glömde visst "gen-id", hur hade du definierat den? :-)

Mvh, Tommy

[Björn Lindberg]

Tommy Hallgren <***@yahoo.com> writes:

> --- Björn Lindberg <d95-***@nada.kth.se> skrev:
> > Sunnan <***@handgranat.org> writes:
> > > (define (make-grower)
> > > (let ((s 0))
> > > (lambda ()
> > > (set! s (add1 s))
> > > s)))
> > >
> > > (define gen-id (make-grower))
> >
> > (Så här skulle det se ut i CL:
> >
> > (defun make-grower ()
> > (let ((s 0))
> > #'(lambda () (incf s))))
> > )
>
> Björn, du glömde visst "gen-id", hur hade du definierat den? :-)

(let ((s 0))
(defun gen-id ()
(incf s)))


Björn

[Tommy Hallgren]

--- Lars Brinkhoff <***@nocrew.org> wrote:
> Kanske
>
> (setf (symbol-function 'gen-id) (make-grover))
>
> ?

Måste man inte skapat gen-id innan det här körs? setf är väl inte tänkt att
skapa symboler som inte finns?

Mvh, Tommy

[Lars Brinkhoff]

Tommy Hallgren <***@yahoo.com> writes:
> --- Lars Brinkhoff <***@nocrew.org> wrote:
>> Kanske
>> (setf (symbol-function 'gen-id) (make-grover))
>> ?
> Måste man inte skapat gen-id innan det här körs?

Nej.

> setf är väl inte tänkt att skapa symboler som inte finns?

setf skapar inte symbolen, det har gjorts tidigare.

[Björn Lindberg]

Tommy Hallgren <***@yahoo.com> writes:

> --- Lars Brinkhoff <***@nocrew.org> wrote:
> > Kanske
> >
> > (setf (symbol-function 'gen-id) (make-grover))
> >
> > ?
>
> Måste man inte skapat gen-id innan det här körs? setf är väl inte tänkt att
> skapa symboler som inte finns?

Symbolen skapas av läsaren om den inte fanns innan. Du blandar nog
ihop detta med *bindningar*.


Björn

[Tommy Hallgren]

--- Lars Brinkhoff <***@nocrew.org> wrote:
> Tommy Hallgren <***@yahoo.com> writes:
> > --- Lars Brinkhoff <***@nocrew.org> wrote:
> >> Kanske
> >> (setf (symbol-function 'gen-id) (make-grover))
> >> ?
> > Måste man inte skapat gen-id innan det här körs?
>
> Nej.
>
> > setf är väl inte tänkt att skapa symboler som inte finns?
>
> setf skapar inte symbolen, det har gjorts tidigare.

Okej, tror mig förstå detta, symbol-function ger funktionssloten i symbolen
gen-id och setf sätter den sloten till make-grover. Lurigt innan någon har
visat hur man gör.

Mvh, Tommy

[Lars Brinkhoff]

Tommy Hallgren <***@yahoo.com> writes:
> Okej, tror mig förstå detta, symbol-function ger funktionssloten i
> symbolen gen-id och setf sätter den sloten till make-grover.

Korrekt!

> Lurigt innan någon har visat hur man gör.

Tänk på att kärnan i en vanlig funktionsdefinition, t ex

(defun foo (x y)
(+ x y))

är

(setf (symbol-function 'foo)
(lambda (x y)
(+ x y)))

(eller ekvivalent).

[Björn Lindberg]

Lars Brinkhoff <***@nocrew.org> writes:

> Tommy Hallgren <***@yahoo.com> writes:
> > Okej, tror mig förstå detta, symbol-function ger funktionssloten i
> > symbolen gen-id och setf sätter den sloten till make-grover.
>
> Korrekt!
>
> > Lurigt innan någon har visat hur man gör.
>
> Tänk på att kärnan i en vanlig funktionsdefinition, t ex
>
> (defun foo (x y)
> (+ x y))
>
> är
>
> (setf (symbol-function 'foo)
> (lambda (x y)
> (+ x y)))
>
> (eller ekvivalent).

Om man skall vara petig bör defun leda till
(setf (fdefinition ...) ...). Annars fungerar det inte för funktioner
med namn som (setf bla).


Björn

[Tommy Hallgren]

--- Tommy Hallgren <***@yahoo.com> wrote:
> > >> (setf (symbol-function 'gen-id) (make-grover))
> Okej, tror mig förstå detta, symbol-function ger funktionssloten i symbolen
> gen-id och setf sätter den sloten till make-grover. Lurigt innan någon har
> visat hur man gör.´

En fråga till, hur vet man att gen-id inte skräpsamlas bort? Ovan uttryck ser
gen-id ut att vara lokalt skräp efter anropen.

Mvh, Tommy

[Lars Brinkhoff]

Tommy Hallgren <***@yahoo.com> writes:
>> > >> (setf (symbol-function 'gen-id) (make-grover))
>> Okej, tror mig förstå detta, symbol-function ger funktionssloten i symbolen
>> gen-id och setf sätter den sloten till make-grover. Lurigt innan någon har
>> visat hur man gör.´
> En fråga till, hur vet man att gen-id inte skräpsamlas bort?

För att den är internerad i ett paket.

[Tommy Hallgren]

--- Björn Lindberg <d95-***@nada.kth.se> wrote:
> Just så. Och skälet till att defmacro fungerar dåligt i Scheme är ju
> just att Scheme inte gör skillnad på funktioner och värden fast de är
> olika sorters entiteter

Hmm, på vilket sätt fungerar defmacro dåligt under Scheme?

Mvh, Tommy

[d***@nada.kth.se]

> --- Björn Lindberg <d95-***@nada.kth.se> wrote:
>> Just så. Och skälet till att defmacro fungerar dåligt i Scheme är ju
>> just att Scheme inte gör skillnad på funktioner och värden fast de är
>> olika sorters entiteter
>
> Hmm, på vilket sätt fungerar defmacro dåligt under Scheme?

Risken för namnkonflikter blir mycket större och är dessutom svår att
undvika. I CL samverkar lisp-2 och paketsystemet på ett sätt som helt
undviker problemet. (Även detta är ett exempel på hur saker i CL "passar
ihop", som jag skrivit tidigare. Paketsystemet passar perfekt tillsammans
med defmacro i detta avseende.)


Björn

[Tommy Hallgren]

--- d95-***@nada.kth.se wrote:
> > Hmm, på vilket sätt fungerar defmacro dåligt under Scheme?
>
> Risken för namnkonflikter blir mycket större och är dessutom svår att
> undvika. I CL samverkar lisp-2 och paketsystemet på ett sätt som helt
> undviker problemet. (Även detta är ett exempel på hur saker i CL "passar
> ihop", som jag skrivit tidigare. Paketsystemet passar perfekt tillsammans
> med defmacro i detta avseende.)

Har du nåt exempel på hur problem kan uppstå? Även i CL måste vi använda gensym
och dessutom är det väl det bara a i (a b c) som makroexpanderas? Hmm. Ska göra
kaffe. :)

Jag har alltid trott att lisp-2 råkade bli, inte att det faktiskt fanns en
tanke med det, det är inte uppenbart att det skulle vara så.

Mvh, Tommy