Typiskt blåbärsproblem?

14 posts in thread

• Sven Wickberg <1384> · Text 7403 · w8 · inlagg

  1987-08-19 11:05

  Ärende: Typiskt blåbärsproblem?

  Jag har en gammal rutin från ABC80-tiden som fungerar som den skall och därför inte borde ändras, men som är "oskön" därför att den innehåller ett virrvarr av IF-satser och ett par GOTO. Det handlar om att ge namn på en fil och skriva i den: AA INPUT Filnamn (Fil) IF Fil="PR1:" (öppnar printer m m) :GOTO BB (ELSE) ON ERROR GOTO BB OPEN Fil:CLOSE ! Fil finns redan (Skall vi fortsätta på den?) IF NEJ THEN AA (ELSE) (Fixa en rad åtgärder och...) BB SKRIV på filen Saken kompliceras dels av att villkoren på flera ställen är mycket komplicerade och kräver flera rader, dels också av att jag måste ha en felrutin för att fånga upp oavsiktliga tryckningar på PF-tangent. Jag har gjort några försök att "modernisera" versionen med WHILE-WEND och diverse funktioner, men jag kommer inte ifrån GOTO-hoppen; i några fall blir de tydligen otillåtna (det verkar som om man inte får hoppa ur en funktion med GOTO). Man KAN kanske dela upp koden i ett otal smårutiner(funktioner) som anropas vid de behövliga ställena, men då tycker jag koden blir ENORM och oöverskådlig. Man KAN också sätta flaggor för allt möjligt och pröva dem vid alla kritiska punkter, men inte heller det gör koden bättre, tycker jag. Ytterligare en möjlighet jag fundert på är att anropa skrivrutinen (som är en mycket omfattande egen procedur) direkt överallt där det står GOTO BB och att hela resten som en oändlig slinga; men då måste man kunna ta sig ur slingan när skrivandet är färdigt - ny flagga... Någon av melonerna som har något tips att ge? (Jag har funderingar på att detta kunde vara inspiration till en artikel i Bladet, det är därför jag tar upp det i detta möte; kanske borde det varit i 800-mötet i stället?) --- PS Naturligtvis är pseudokoden ovan starkt förenklad. Det finns ett par ytterligare villkor som jag hoppat över, och det måste i några fall sker filöppningar m m innan skrivrutinen anropas. Men jag bedömer att dess detaljer inte påverkar PRINCIPLÖSNINGEN.
  • Kristoffer Eriksson <5357> · Text 7404 · w8 · kommentar

    1987-08-24 22:56

    Ärende: Typiskt blåbärsproblem?

    Nu har det nog gått för långt i mötet Bladet. Den här frågan besvarar jag i det här mötet. WHILE FNVäljfil : WEND Skriv på filen ... DEF FNVäljfil INPUT "Filnamn: " Fil¤ IF Fil¤="PR1:" THEN (öppna printer m m) : RETURN 1 ON ERROR GOTO CC OPEN Fil¤ IF FNFrågajanej("Finns redan. Ska vi fortsätta på den?") ="N" THEN CLOSE : RETURN 1 (Fixa en rad åtgärder och...) RETURN 0 CC PREPARE Fil¤ RETURN 0 FNEND Här börjar det hela med en WHILE-loop som loopar tills man öppnar en bra fil. Den ersätter alla GOTO AA och BB. FNVäljfil frågar efter filnamn med målet att vid retur ha en fil öppen att skriva på. Går det dåligt är det bara att göra RETURN 1 (eller något annat "sannt" värde) i stället för GOTO AA. Går det bra gör den RETURN 0 i stället för GOTO BB. ON ERROR GOTO är det inte mycket att göra åt. Man kan förstås göra korta funktioner med en kort ON ERROR GOTO, och som med returvärdet talar om ifall det blev fel eller inte. Då kan man använda den i IF-satser som väljer mellan fortsättning och felhantering. 10 DEF FNOpen(Fil¤,Filnr) 20 ON ERROR GOTO 30 : OPEN Fil¤ AS FILE Filnr : RETURN 0 30 RETURN ERRCODE 40 FNEND Ett tipps i vissa fall, t ex när man ska fråga användaren angående en fil som redan finns, är att göra så här: 10 ON ERROR GOTO 30 : Gör ev felframkallande sak 20 WHILE 0 30 Felhantering 40 WEND 50 Gemensam fortsättning oavsett fel WHILE 0 ersätter här en GOTO förbi felhanteringen när det inte blir fel. Om man använder ON ERROR GOTO i en funktion måste den rad som anges ligga i samma funktion. Man kan inte låta den hoppa ut ur funktionen. Det upptäcker man snart. Det kan vara bra att veta att det fel man vill fånga upp däremot får inträffa i en funktion man anropar efter att ha satt ON ERROR GOTO, dvs så här: DEF FNFoo ... ON ERROR GOTO xxx Bar = FNFunktion-där-det-kanske-uppstår-fel xxx ... FNEND När felet uppstår i den anropade funktionen, kommer ett hopp att ske tillbaks till den angivna raden i FNFoo. Långa villkor kan man ev göra funktioner av, eller dela upp på flera rader. 10 IF xxx AND yyy THEN ... kan bli 10 Temp=xxx 20 IF Temp AND yyy THEN ... hellre än 10 IF NOT xxx THEN 30 20 IF yyy THEN ... 30 ... Att IF xxx THEN massor-av-saker kan skrivas WHILE xxx massor-av-saker-på-flera-rader IF 0 WEND när det inte finns flerradig IF, känner du kanske till vid det här laget. --- Om någon här inte är med i mötet Bladet, rekommenderar jag honom/henne att gå med där och läsa den senaste månadens inlägg, som inte alls handlar om tidningen.
    • Sven Wickberg <1384> · Text 7406 · w8 · kommentar

      1987-08-25 19:02

      Ärende: Typiskt blåbärsproblem?

      DET var verkligen en lektion! Med många fiffiga grepp som jag knappast skulle kommit på själv. Tack, Kristoffer! Jag hoppas du inte har något emot om jag (så smånginom) knycker en del och gör en artikel i Bladet av (tillsammans med diverse annat, knyckt och oknyckt). En del av dina lösningar kom på sidan om mitt problem, som jg mycket ofullständigt redovisade, det medges; men det gör inte så mycket, det är principerna som är intressanta. Fast egentligen är raden IF 0 WEND besvärlig därför att den är språkligt ologisk; man skulle tycka att om SANT så skulle man AVSLUTA; men det är tvärtom. Tankekrånglet uppstår inte när man gör en "falsk" flerradig IF-sats, utan i sammanhanget IF I<>0 THEN WEND Men man får väl helt enkelt lära sig. Basic2 är över huvud taget ett synnerligen flexibelt och användbart språk. Synd att det inte verkar ha någon framtid (beroende på att den inte uppdateras och avbuggas av DIAB).
      • Stefan Gartz <2600> · Text 7408 · w8 · kommentar

        1987-08-26 20:02

        Ärende: Typiskt blåbärsproblem?

        Jag bidrar med lite till för din ev artikel. Nu med minnessparande metoder. 10 ! list pgmtipps 20 ! Minnes sparande programmering 30 EXTEND 40 INTEGER 50 ; 60 ; ' fel användning av global inparameter till funktion' 70 ; 'Test 1' 80 Z=FNTest1 90 ; 100 ; ' rätt användning av funktionsparameter' 110 ; 'Test 2 ' 120 Z=FNTest2 130 ; 140 ; ' använd gärna mid¤ i funktion' 150 ; 'Test 3' 160 Z=FNTest3(SPACE¤(20)) 170 ; 180 ; " använd gärna globala variabler som läggs på stacken med +''" 190 DIM Q¤=10000 200 Q¤='KALLE' 210 ; FNTest4¤(Q¤+'') 220 ; Q¤ 230 END 240 ! 250 DEF FNTest1 260 Global¤=' glade' 270 Z=FNTest1a(Global¤) 280 RETURN 0 290 FNEND 300 ! 310 DEF FNTest1a(A¤) 320 Global¤=' du' 330 Z=FNTest1b(Global¤) 340 ; A¤ 350 RETURN 0 360 FNEND 370 ! 380 DEF FNTest1b(A¤) 390 Global¤='Hej' 400 ; Global¤ A¤; 410 RETURN 0 420 FNEND 430 ! 440 DEF FNTest2 450 Global¤=' glade' 460 Z=FNTest2a(Global¤+'') 470 RETURN 0 480 FNEND 490 ! 500 DEF FNTest2a(A¤) 510 Global¤=' du' 520 Z=FNTest2b(Global¤+'') 530 ; A¤ 540 RETURN 0 550 FNEND 560 ! 570 DEF FNTest2b(A¤) 580 Global¤='Hej' 590 ; Global¤ A¤; 600 RETURN 0 610 FNEND 620 ! 630 DEF FNTest3(A¤) 640 MID¤(A¤,8,5)='glade' 650 Z=FNTest3a(A¤) 660 RETURN 0 670 FNEND 680 ! 690 DEF FNTest3a(A¤) 700 MID¤(A¤,5,2)='du' 710 Z=FNTest3b(A¤) 720 RETURN 0 730 FNEND 740 ! 750 DEF FNTest3b(A¤) 760 MID¤(A¤,1,3)='Hej' 770 ; A¤ 780 RETURN 0 790 FNEND 800 ! 810 DEF FNTest4¤(A¤) 820 IF LEN(A¤)>1 THEN RETURN FNTest4¤(RIGHT¤(A¤,2))+LEFT¤(A¤,1) 830 RETURN A¤+'' 840 FNEND Ja varsågod och studera Mvh Sgz
        • Sven Wickberg <1384> · Text 7410 · w8 · kommentar

          1987-08-27 09:04

          Ärende: Typiskt blåbärsproblem?

          Tack för hemuppigften! :-) Men du kan väl underlätta läxan genom några kommentarer? Jag måste erkänna att jag inte helt självklart inser sens moralen.
          • Stefan Gartz <2600> · Text 7429 · w8 · kommentar

            1987-09-01 08:11

            Ärende: Typiskt blåbärsproblem?

            Ja här kommer en något mer kommenterad snutt för att demonstrera vad jag menade 1 ! 2 ! Det är inte god programmeringsed att ändra inparametrarna till en funktion 3 ! men att spara minne kan ibland vara bra att kunna. 4 ! 5 DIM Q¤=2000 ! Dimma Q¤ till det största du ska läsa in 6 Z=FNVisa(FNByt¤(FNLäsin¤,'LAD','AML')) 7 ! 8 DEF FNLäsin¤ 9 ! Läs in /skapa något data 10 Q¤='HEJ DU GLADE' 11 RETURN Q¤+'' 12 ! Additionen gör att datat lagras på stacken och endast 13 ! den aktuella längden + ny variabelrot går åt i minnet 14 ! Q¤ är direkt efter detta ledig för ny användning 15 FNEND 16 ! 17 DEF FNByt¤(In¤,Sök¤,Byt¤) LOCAL P 18 ! Genom att inte deklarera en lokal variabel för In¤ 19 ! behöver man inte veta längden på inargumentet 20 ! funktionen kapar ej åt sig minne i onödan 21 ! 22 P=INSTR(1,In¤,Sök¤) 23 IF P THEN MID¤(In¤,P,LEN(Byt¤))=Byt¤ 24 ! Vid insättningen av byt med MID¤ i vänsterledet så kommer ej In¤ att 25 ! läggas upp på stacken vid behandlingen, man spar lite minne till 26 ! gör man + så kommer stacken att byggas på med hela variabelns 27 ! aktuella längd och lite till 28 ! 29 Q¤='PELLE' ! Q¤ kan användas fritt 30 RETURN In¤ 31 FNEND 32 ! 33 DEF FNVisa(In¤) 34 ! Q¤ ledig för användning 35 PRINT In¤ ' OCH ' FNLäsin¤ 36 RETURN 0 37 FNEND Mvh Sgz
        • Lars Gjörling <6825> · Text 7414 · w8 · kommentar

          1987-08-27 23:37

          Ärende: Typiskt blåbärsproblem?

          Ett av dina pgmtips är: ' använd gärna mid¤ i funktion'. I program- exemplet ändras sedan funktionens inparameter. Efter vad jag kan minnas, tolererar inte äldre versioner av basic2 att inparametern ändras?? (På nyare versioner går det bra!) Kan mid¤ medföra oväntade konstigheter? Någonting i den här stilen såg jag för länge sedan i något inlägg: 10 INTEGER : EXTEND 20 Z=FNTest("Hej du glade") 100 DEF FNTest(A¤) 110 MID¤(A¤,9,3)="aml" 120 ; A¤ ! Denna rad kan tas bort om man vill. 130 RETURN 0 140 FNEND Kontrollera rad 20 INNAN du kör programmet! Kör det! Lista sedan på nytt och kontrollera lydelsen av rad 20 återigen! Var det någon som blev snopen? Tillämpat på ditt program, så kan man ändra i rad 160, och byta ut 'SPACE¤(20)' så att det står (det identiskt samma): 160 Z=FNTest3(" ") Kör programmet och lista på nytt! Mvh Lars
          • Sven Wickberg <1384> · Text 7415 · w8 · kommentar

            1987-08-28 18:59

            Ärende: Typiskt blåbärsproblem?

            Det var verkligen mycket egendomligt! Ändringar med MID¤() i A¤ återspeglas på den parameter man sänder med och har alltså "retroaktiv" verkan i programmet! Är alla dessa verkningar - förutom det där plusfenomenet i Stefan Gartz lokala variabler - dokumenterade ? Jag har knappast läst manualen (till BASICIIPC - den är otroligt tjock och svåröverskådlig och på förfärlig engelska) men jag kan inte påminna mig att det fanns något om detta i Luxors handbok till ABC800. Inte heller i Bit för Bit - som jag dock inte heller lusläst; jag har dock på sistone tittat igenom det här med rekursiva funktioner och felkontroll i funktioner.
            • Bo Kullmar SYSOP <1789> · Text 7416 · w8 · kommentar

              1987-08-28 19:26

              Ärende: Typiskt blåbärsproblem?

              Det är inte alls så konstigt. Parametern förs över med vad man brukar kalla för referens till värdet i det här fallet. Det är faktiskt därför inte meningen att man skall ändra inparametern i funktionen även om man kan göra det. Det är ej god programmerinssed att göra så. Man kan inte göra så i D-BASIC V och ej heller i BASIC:en till 1006 vad jag kommer inåg. Däremot så verkar det gå i BASIC II/PC version 1.13. Skickas värdet med till funktionen så påverkar man så klart ej det ursprunliga värdet.
              • Kristoffer Eriksson <5357> · Text 7427 · w8 · kommentar

                1987-08-30 23:30

                Ärende: Typiskt blåbärsproblem?

                MID¤-metoden på funktionsparametrar fungerar visst på D-BASIC V, det har jag just testat!
            • Lars Gjörling <6825> · Text 7419 · w8 · kommentar

              1987-08-29 16:02

              Ärende: Typiskt blåbärsproblem?

              När jag skrev att mid¤() kan medföra 'konstigheter', så menade jag inte 'obegripligheter' utan snarare 'oväntade lustigheter'. Jag delar helt Bosses uppfattning att man inte skall göra ändringar av inparametrarnas värden i funktioner, och ville bara visa ett ganska lustigt exempel på vad som kan inträffa (även i Stefans eget programexempel). Det har också flera gånger hänt (t ex i programmet LIBMENY.BAC) att ett program har lagts in i programbanken, och sedan utlöst en rad inlägg från medlemmar med äldre basicversioner, som får error 191, därför att deras version inte tillåter att en inparameter ändras i funktion. Om man har en nyare version, och dessutom vet vad man gör, så går det väl an, men annars bör man ta till vana att först kopiera inpa- rametern till en annan (lokal) variabel och sedan göra ändringarna på den, om sådana är nödvändiga. Mvh Lars
          • Kristoffer Eriksson <5357> · Text 7422 · w8 · kommentar

            1987-08-29 23:43

            Ärende: Typiskt blåbärsproblem?

            Det kanske var därför Lars använde SPACE¤ och inte " "... För att klara sig undan problemet, och ändå använda en strängkonstant, kan man skriva " "+"" eller något annat uttryck som ger den önskade strängen, så som Lars gjorde för att få en global variabel Q¤ att kopieras till stacken före anropet. (Fast där han gjorde det gjorde det detsamma...) Basic:en blir ju tvungen att beräkna uttrycket, och placerar då svaret på stacken och anväder det som funktionsargument, i stället för originalsträngen, och ingen skada på programmet sker. En gammal basic på ABC800 gillar inte att man gör en sak som DEF FNFoo(Bar) Bar=1 ... vilket är onödigt restriktivt, eftersom numeriska funktionsparametrar får en lokal kopia i funktionen, och det verkliga argumentet inte påverkas. Strängar därmot kopieras inte, utan refererar till själva argumentet. Därför får strängparametrar inte tilldelas värden med LET, typ A¤=..., vilket kontrolleras när programmet startas (fixup). En liten miss är att ändring i parametern med MID¤ INTE kontrolleras.
      • Kristoffer Eriksson <5357> · Text 7409 · w8 · kommentar

        1987-08-26 22:35

        Ärende: Typiskt blåbärsproblem?

        WEND betyder vid exekvering "fortsätt med loopen" (eller tekniskt "hoppa tillbaks till WHILE"), så SÅ ologiskt blir det inte. WHILE betyder "Om villkoret är falskt, så hoppa till satsen närmast efter WEND". IF 0 innebär att det som kommer efter på raden aldrig kommer att exekveras, alltså slipper vi hoppa tillbaks till den föregivna loopens början. Dock, om villkoret i WHILE-satsen är falskt, markerar denna aldrig exekverade WEND, hur mycket som ska hoppas över, alltså är den ändå inte helt onyttig. IF I<>0 THEN WEND betyder förstås "om I inte är noll, så fortsätt med loopen", vilket förstås innebär att villkoret i WHILE blir testat härnäst. "Avsluta" betyder WEND inte. Däremot kan man säga att WEND markerar slutet på WHILE-WEND-strukturen. Tja, att kunna behandla programstrukturen så här passar väl bra för folk med hacker-mentalitet, men "programmeringsteoretikerna" lär väl rynka på näsan... Basic-II lever vidare i BasicII/PC och Basic-V, som det kommer nya versioner av då och då, så helt ska vi nog inte dödförklara den än. Finns det några buggar i ABC-Basicen, förutom några tidiga versioner till 800?
        • Sven Wickberg <1384> · Text 7411 · w8 · kommentar

          1987-08-27 09:10

          Ärende: Typiskt blåbärsproblem?

          Tack för kompletteringarna; välformulerade och klargörande. Jovistt föstår jag att WEND har den innebörd du skriver. Vad jag menade var att för en "oinvigd" förefaller IF någonting THEN WEND betyda "Om någonting ... så WHILE-END (ENDWHILE) dvs avsluta WHILE-WEND-slingan". Definitionsfrågor för vissa; och sådnt man helt enkelt måste lära sig.