compiler issueshttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues2024-02-19T18:41:01+01:00https://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/101newtypes with higher-kinded type variables give a strange error2024-02-19T18:41:01+01:00Mart Lubbersnewtypes with higher-kinded type variables give a strange errornewtypes with higher-kinded type variables give a strange error.
e.g.:
T.dcl:
```
definition module T
:: T0 m a =: T0 (m a)
```
T.icl:
```
implementation module T
```
When compiling gives the following error:
```
Error [T.dcl,3,T0]: ...newtypes with higher-kinded type variables give a strange error.
e.g.:
T.dcl:
```
definition module T
:: T0 m a =: T0 (m a)
```
T.icl:
```
implementation module T
```
When compiling gives the following error:
```
Error [T.dcl,3,T0]: m attribute variable not allowed
```John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/100Unexpected parse error message when using _createArray2024-03-04T14:43:14+01:00Peter AchtenUnexpected parse error message when using _createArrayHi,
compiling the function definition:
```
import _SystemArray
g = _createArray 42
```
gives the unexpected compiler error message:
```
Parse error [Experiments.icl,42;3,RHS expression]: <expression> expected instead of _createArray
``...Hi,
compiling the function definition:
```
import _SystemArray
g = _createArray 42
```
gives the unexpected compiler error message:
```
Parse error [Experiments.icl,42;3,RHS expression]: <expression> expected instead of _createArray
```
Using:
```
g = createArray 42 ' '
```
gives no problems.
If you're not allowed to use `_createArray`, then a different error message is clearer.
Cheers,
Peterhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/95make it possible to a type variable introduced in the type specification o...2022-02-04T11:32:07+01:00Steffen Michelsmake it possible to a type variable introduced in the type specification of a surrounding function in the specification for local functionsThis is not possible (see "3.7 Typing Functions" of the language report). The example given is:
```
f:: a -> (a,a)
f x = g x
where
// g:: b -> (a^,b)
g y = (x,y)
```
This feature would be highly desirable to:
* improve readabi...This is not possible (see "3.7 Typing Functions" of the language report). The example given is:
```
f:: a -> (a,a)
f x = g x
where
// g:: b -> (a^,b)
g y = (x,y)
```
This feature would be highly desirable to:
* improve readability of the code
* improve performance (e.g. the tuple returned by `g` in the example above cannot be made strict without type annotation)John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/94identifiers of ?None constructors still contain "Nothing"2021-04-23T16:54:39+02:00Steffen Michelsidentifiers of ?None constructors still contain "Nothing"The identifiers are still e.g. "_!Nothing". Wouldn't "_?None" be more consistent with the actual syntax?The identifiers are still e.g. "_!Nothing". Wouldn't "_?None" be more consistent with the actual syntax?John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/93Compiler ignores `-o` option2021-04-10T11:15:21+02:00Erin van der VeenCompiler ignores `-o` optionThe `-o` option for the compiler is parsed but never used. This makes it impossible to specify where the `.abc` files should go, in turn making it impossible to use the compiler in the usual way on a system where `$CLEAN_HOME` is read-on...The `-o` option for the compiler is parsed but never used. This makes it impossible to specify where the `.abc` files should go, in turn making it impossible to use the compiler in the usual way on a system where `$CLEAN_HOME` is read-only.
This was noted on the `itask` branch of the compiler. Not checked for `master`.John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/92Compiler crashes when "let let" is parsed2021-03-22T14:48:58+01:00Mart LubbersCompiler crashes when "let let" is parsed```
module test
Start = let let
```
results in:
```
$ clm test
Compiling test
tokenBack with empty token bufferclm: reading compiler result failed: No such file or directory
``````
module test
Start = let let
```
results in:
```
$ clm test
Compiling test
tokenBack with empty token bufferclm: reading compiler result failed: No such file or directory
```John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/91compiler complains about overlapping instances when one is clearly more specific2021-03-15T21:32:17+01:00Steffen Michelscompiler complains about overlapping instances when one is clearly more specific```
class C a :: a
:: T a = A
instance C (a b) where
C = undef
instance C (T b) where
C = undef
```
The instance for `T b` is clearly more specific than the one for `a b`. So this should compile in my opinion.```
class C a :: a
:: T a = A
instance C (a b) where
C = undef
instance C (T b) where
C = undef
```
The instance for `T b` is clearly more specific than the one for `a b`. So this should compile in my opinion.John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/90SegFault when compiling tiny program2021-03-22T17:42:52+01:00Erin van der VeenSegFault when compiling tiny programThe following program causes the compiler to SegFault:
```Clean
Start | False = 1
```
with
``cocl -P . test``The following program causes the compiler to SegFault:
```Clean
Start | False = 1
```
with
``cocl -P . test``John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/89Constants in node patterns2021-02-23T16:11:18+01:00Camil StapsConstants in node patternsWhat is the purpose of the `constant not allowed in a node pattern` error in checkFunctionBodies?
It prevents you from writing things like:
```clean
Start
# [] = [1]
= 1
```
This is useful. Without the error you might think th...What is the purpose of the `constant not allowed in a node pattern` error in checkFunctionBodies?
It prevents you from writing things like:
```clean
Start
# [] = [1]
= 1
```
This is useful. Without the error you might think that the program will check that the pattern matches. However, we *are* allowed to write the following, and there you would then also want an error:
```clean
Start
# [_:_] = []
= 1
```
So this can't be it, or it would be more useful to check whether any variables are bound instead of whether the pattern has arity 0.
Or is the problem that the pattern match would never be performed? But then should this not be a warning instead of an error (and also appear for patterns that do not bind any variables)?John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/88iTasks compile can't solve overloading when using StdOverloadedList.Diag22021-02-25T22:03:13+01:00Steffen MichelsiTasks compile can't solve overloading when using StdOverloadedList.Diag2In this program the type of the arguments and result should be defined unambiguously:
```
import StdOverloadedList
Start :: [(Int, Int)]
Start = Diag2 [1] [2]
```
Still the compiler reports:
```
Overloading error [StdOverloadedList.d...In this program the type of the arguments and result should be defined unambiguously:
```
import StdOverloadedList
Start :: [(Int, Int)]
Start = Diag2 [1] [2]
```
Still the compiler reports:
```
Overloading error [StdOverloadedList.dcl,396,diag2_]: internal overloading of "_nil" could not be solved for: List _ a (contains type variable not in function type at _ )
```John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/87Segmentation fault when comparing unboxed maybes2020-12-15T13:42:08+01:00Camil StapsSegmentation fault when comparing unboxed maybesThe following program crashes with a segmentation fault with the current nightly master compiler on x64 linux:
```clean
import StdEnv, StdMaybe
Start = ?#Just 1 == ?#Just 1
```The following program crashes with a segmentation fault with the current nightly master compiler on x64 linux:
```clean
import StdEnv, StdMaybe
Start = ?#Just 1 == ?#Just 1
```John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/86convertTypeCode lacks alternative for PD_UnboxedMaybeTypeIndex2020-12-11T17:31:53+01:00Camil StapsconvertTypeCode lacks alternative for PD_UnboxedMaybeTypeIndexIn `convertTypeCode` (convertDynamics.icl), the local function `typeConstructor` seems to be missing an alternative for `PD_UnboxedMaybeTypeIndex`, causing a run-time error when packing a `?#` in a dynamic.In `convertTypeCode` (convertDynamics.icl), the local function `typeConstructor` seems to be missing an alternative for `PD_UnboxedMaybeTypeIndex`, causing a run-time error when packing a `?#` in a dynamic.John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/85Unsigned integer constants2020-12-07T21:22:50+01:00Camil StapsUnsigned integer constantsI encountered an issue where:
- 32-bit ABC code is interpreted on a 64-bit platform (e.g. compile with 32-bit Clean, run in WebAssembly)
- The code uses negative integer constants with unsigned semantics (e.g. `bitor 0x80000000`)
When ...I encountered an issue where:
- 32-bit ABC code is interpreted on a 64-bit platform (e.g. compile with 32-bit Clean, run in WebAssembly)
- The code uses negative integer constants with unsigned semantics (e.g. `bitor 0x80000000`)
When generating 64-bit bytecode this value is sign-extended, since there is no way to tell that this value should be `0x0000000080000000` on 64-bit platforms.
The issue could be solved by computing the values at runtime (https://gitlab.science.ru.nl/clean-and-itasks/clean-platform/-/merge_requests/386) using only positive values. Performance-wise this is not ideal.
Would it be very difficult to add syntax for unsigned integer constants, e.g. `0x80000000u` or `0ux80000000` (neither of these is fully backwards compatible) all the way down to the ABC level so that the bytecode generator knows how the value should be extended? Or do you see another way to solve this without losing performance?John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/84Local derive in custom generic instance2020-12-24T14:55:07+01:00Camil StapsLocal derive in custom generic instanceAs an exception to the rule that generic derives are only allowed on the top level, since recently we can also derive in instances:
```clean
instance == T
where
(==) x y = trace_n "eq" (eq x y)
where
derive eq gEq
gEq{|T|} x y = x ...As an exception to the rule that generic derives are only allowed on the top level, since recently we can also derive in instances:
```clean
instance == T
where
(==) x y = trace_n "eq" (eq x y)
where
derive eq gEq
gEq{|T|} x y = x == y
```
which is useful to use a slightly customised version of the derived function, without deriving it on the top level, as is done to add a trace statement above.
In this case I made use of the fact that there is a class `==` with the same type and semantics as `gEq`. For the case that there is no matching class, would it make sense to also allow local derives in custom instances of generic functions?
```clean
gEq{|T|} x y = trace_n "eq" (eq x y)
where
derive eq gEq
```
Apologies if we discussed this already and there was a reason to not add it, or it simply has not been implemented yet.
In your email of July 16th (see below) you suggested that you can implement this without classes by adding a second generic function, but this seems cumbersome if it can be avoided.
For reference I will quote your two emails from July here:
<details>
<summary>July 15: Deriven van instanties</summary>
```
Hallo,
Hierbij wat uitleg over het deriven van instanties met behulp van
generische functies. Dit is geimplementeerd en beschikbaar in
de nightly builds.
Als syntax heb ik voorlopig gekozen wat makkelijk te implementeren
was. Dat kan dus nog veranderen.
derive in instantie definitie
------------------------------
Om een member van een instantie te deriven gebruik je
derive member generische_functie
in de instantie definitie. Bijvoorbeeld om == voor type T
te deriven met gEq:
instance == T where
derive == gEq
Dit genereert met behulp van generische functie gEq een
member == die een gEq voor type T uitvoert en daarbij
== gebruikt voor de elementen van constructors of velden
van records van type T.
Er kunnen natuurlijk meer members zijn die al of niet worden
gederived. Als er maar 1 member is, kan dit worden afgekort
tot:
instance == T derive gEq
Als een type parameters heeft, moet je zoals gebruikelijk
bij instanties de klassen opgeven, bijvoorbeeld:
instance == (T a) | == a derive gEq
De types van het member en de generische functie moeten
natuurlijk ongeveer hetzelfde zijn. Dat wordt nog niet
gecontroleerd, behalve dan dat de gegenereerde instantie wordt
getypeerd. De ariteit wordt wel gecontroleerd.
derive in klasse definitie
--------------------------
Om niet elke keer "derive generische_functie" in te hoeven
typen. Kun je ook het volgende doen.
In de definitie van een klasse kun je een default definieren
voor een member. Nu kun je met:
default member generische_functie
ook een generische functie opgeven als default. Bijvoorbeeld:
class equal a where
equal :: !a !a -> Bool
derive equal gEq
Als je dan een instantie declareert wordt de default gebruikt
en automatisch een instantie gegenereerd. Dus voor een type:
:: T = T Int
derive je dan een instantie met:
instance equal T
Omdat de instantie definitie in dit geval member equal
niet definieert, wordt de default uit de klasse definitie
overgenomen, die bevat een derive, waardoor de member
equal wordt gederived.
Je kunt natuurlijk ook nog:
instance equal T derive gEq
gebruiken, of met een andere generische functie.
derive van een functie in instantie definitie
---------------------------------------------
In de where van een instantie kan met een derive ook een
functie worden gegeneerd die hetzelfde doet als een member
die gederived wordt.
Bijvoorbeeld:
instance == T where
(==) a b = equal_function a b
where
derive equal_function gEq
"derive equal_function gEq" genereert een locale functie
met naam equal_function, die een gEq voor type T doet en
== gebruikt voor de elementen van constructors of velden
van records.
In dit geval roept member == deze functie aan, en
gebeurt dus hetzelfde als voor:
instance == T where
derive == gEq
Maar je kunt ook extra code toevoegen, bijvoorbeeld om
te debuggeb:
instance == T where
(==) a b
| trace_tn "== T"
= equal_function a b
where
derive equal_function gEq
of bijvoorbeeld in een functie die test waardes genereerd:
instance gen T where
gen st = [value_1,value_2 : g_gen]
where
derive g_gen gGen
Zo'n derive is alleen toegestaan in de where na een alternatief
van een member, niet in de where's van locale functies,
let's of with's.
derive van een functie in klasse definitie
------------------------------------------
Bij een definitie van een default klasse member kan ook
een locale functie worden gederived, net als bij een
instantie definitie, met dezelfde beperkingen.
Bijvoorbeeld:
class equal a where
equal :: !a !a -> Bool
equal a b
| trace_tn "derived equal"
= equal_function a b
where
derive equal_function gEq
derive met gebruik van een ander member
=======================================
Bij een "derive member_naam generische_functie_naam" wordt een
member met naam "member_naam" gegenereerd die "member_naam"
gebruikt voor de elementen van contructors of velden van
records.
Het is ook mogelijk een andere member te gebruiken. Dit kan
met "derive member_naam1 generische_functie_naam member_naam2".
Dan wordt een member met naam "member_naam1" gegenereerd die
"member_naam2" gebruikt voor de elementen van contructors of
velden van records.
Net als via het deriven van locale functies, kun je daarmee
een generische functie deriven en daarbij extra code toevoegen. In
dit geval door een extra member toe te voegen met hetzelfde type
in deze klasse, of in een andere klasse.
Bijvoorbeeld (met een andere klasse), als equal gedefineerd is:
class equal a where
equal :: !a !a -> Bool
derive equal gEq
kun je een extra klasse toevoegen:
class equal2 a where
equal2 :: !a !a -> Bool
equal2 kan dan gederived worden met:
instance equal2 T where
derive equal2 gEq equal
equal2 gebruikt nu equal, en doet daardoor hetzelfde als
een derive van equal. Nu kan equal2 gebruikt worden in
de definitie van equal:
instance equal T where
equal a b
| trace_tn "equal T"
= equal2 a b
Dit was geimplementeerd voordaar het mogelijk was om locale
functies te deriven. Misschien is dit nu niet meer nodig.
De derive met extra member kan ook gebruikt worden in een
default van een klasse definitie.
tegelijk deriven van meerdere instanties
----------------------------------------
Met generics is het mogelijk voor meerdere type tegelijk
generische functies te deriven. Bijvoorbeeld:
derive gEq T1,T2,T3
Als geen members gedefinieerd worden bij een instantie
definitie (omdat alle members gedefinieerd worden door
default (derived) class members), kan dit nu ook voor
instanties met:
instance == T1,T2,T3
opmerkingen
-----------
Members van dictionaries zijn strict. Dit kan problemen opleveren
als je i.p.v. een generische functie met ariteit 0 een gederivede
instantie gaat gebruiken. De member van een dictionary van een
generische functie met ariteit 0 is lazy voor de itask compiler.
Dit moet eigenlijk ook zo zijn voor members met ariteit 0 van
gewone klassen, maar is nog niet geimplementeerd.
Bij deriven van generische functies kunnen bij instanties geen
extra klasse constraints toegevoegd worden voor type variabelen
van het het type waarvoor gederived wordt. Bij het deriven van
instanties kan dat wel. Daardoor is zoiets als afhankelijke
generische functies vaak niet nodig.
En is het bijvoorbeeld ook mogelijk instanties te definieren of
te deriven voor unboxed lijsten. Voor generics kan dat niet.
details
-------
- alleen de generische instanties voor EITHER, PAIR, UNIT,
CONS, OBJECT, RECORD en FIELD worden gebruikt. De generische
functie moet gedefinieerd zijn.
- de generische klassen voor allerlei kinds worden niet gebruikt.
Zelfs de klasse voor kind * niet. Shorthand instanties ook niet.
- net als voor generische functies kan een bimap nodig zijn.
- instanties voor multiparameter type klassen zijn niet toegestaan.
- generische functies met afhankelijke generische functies zijn
niet geimplementeed. Dit kan waarschijnlijk wel. Maar ik kwam
tot nu toe geen voorbeeld tegen waarbij dit nodig was.
- als locale functies gederived worden, krijgen ze nu dezelfde
ariteit als het member. Dat moet eigenlijk bepaald worden
door de ariteit van de generische functie, maar kan niet
zomaar geimplementeerd worden. De syntax zo aanpassen dat
de ariteit uit de syntax kan worden bepaald is een andere
mogelijk.
Met vriendelijke groet,
John
```
</details>
<details>
<summary>July 16: Gederivede generische functies aanpassen</summary>
```
Hallo,
Bij het implementeren van het deriven van instanties met generische functies
bedacht ik een paar manieren om een instantie te deriven en toch te kunnen
aanpassen.
Een van die methodes is het deriven met een andere naam, zodat je de de instantie
zelf kunt definieren met behulp van de gederivede code, doordat je die kunt
aanroepen met die andere naam.
Dit zou je ook kunnen doen met gewone generische functies. Als je een
generische functie g hebt, definieer je dan een zelfde generische functie
met een andere naam, bijvoorbeeld g2. Als je dan een instantie van g2
zou kunnen deriven die hetzelfde doet als een instantie van g, kun je g2
voor een type T maken met:
g{|T|} a0 .. an = g2{|*|} a0 .. an
waarbij a0 .. an de argumenten voor de generische functie zijn.
De code kun je dan makkelijk aanpassen, bijvoorbeeld als je wilt debuggen:
g{|T|} a0 .. an
| trace_tn "g T"
= g2{|*|} a0 .. an
Nu bedacht ik net dat je deze g2 nu ook al kunt maken met de huidige compiler
met behulp van afhankelijke generische functies:
g2 a | g a :: type_van_g
g2 voor OBJECT en RECORD moet je dan definieren, door g voor OBJECT/RECORD
te copieren, g te veranderen in g2 en als extra tweede argument een _ toe te
voegen. Bij het exporteren van g2 voor OBJECT en RECORD gebruik je dan
with _ g, bijvoorbeeld:
derive g2 OBJECT with _ g
Daardoor weet de compiler dat je alleen g gebruikt en niet g2 en hoef je
g2 niet te definieren voor andere types, zoals PAIR en EITHER.
Ik heb dit getest voor gast en de itasks gEditor.
ggen is:
generic ggen a :: Int [Int] -> [a]
dus ggen2 wordt dan:
generic ggen2 a | ggen a :: Int [Int] -> [a]
ggen voor OBJECT is:
ggen{|OBJECT|} f n rnd = [OBJECT a \\ a<-f n rnd]
dus ggen2 is dan hetzelfde, behalve de naam en een extra _ :
ggen2{|OBJECT|} _ f n rnd = [OBJECT a \\ a<-f n rnd]
Dus aan ggen.icl voeg ik toe:
generic ggen2 a | ggen a :: Int [Int] -> [a]
ggen2{|OBJECT|} _ f n rnd = [OBJECT a \\ a<-f n rnd]
ggen2{|RECORD|} _ f n rnd = [RECORD a \\ a<-f n rnd]
en aan ggen.dcl:
generic ggen2 a | ggen a :: Int [Int] -> [a]
derive ggen2 OBJECT with _ ggen, RECORD with _ ggen
In voorbeeld testTree kun je nu:
derive ggen Color
vervangen door:
derive ggen2 Color
ggen{|Color|} n rnd = ggen2{|*|} n rnd
Maar je kunt nu ook:
ggen{|Color|} n rnd = [Blue] ++ ggen2{|*|} n rnd
of:
ggen{|Color|} n rnd = [Blue] ++ [c\\c<-ggen2{|*|} n rnd | not c=:Blue]
En voor Tree:
derive ggen2 Tree
ggen{|Tree|} f n rnd = ggen2{|*->*|} undef f n rnd
of:
ggen{|Tree|} f n rnd = [Leaf] ++ ggen2{|*->*|} undef f n rnd
of:
ggen{|Tree|} f n rnd = [Leaf] ++ [t\\t<-ggen2{|*->*|} undef f n rnd | not t=:Leaf]
gEditor is gedefinieerd in module iTasks.UI.Editor.Generic als:
generic gEditor a | gText a, JSONEncode a, JSONDecode a :: Editor a
gEditor2 zou dan worden:
generic gEditor2 a | gEditor a, gText a, JSONEncode a, JSONDecode a :: Editor a
Maar omdat de gEditor voor OBJECT a en RECORD a alleen gEditor a gebruiken, en
niet gText a, JSONEncode a en JSONDecode, kunnen we dit vereenvoudigen tot:
generic gEditor2 a | gEditor a :: Editor a
gEditor voor OBJECT en RECORD in implementatie module iTasks.UI.Editor.Generic
copieren we (dit zijn grote functies) en we passen de eerste regel aan:
gEditor{|RECORD of {grd_arity}|} {Editor|genUI=exGenUI,onEdit=exOnEdit,onRefresh=exOnRefresh,valueFromState=exValueFromState} _ _ _
wordt:
gEditor2{|RECORD of {grd_arity}|} _ {Editor|genUI=exGenUI,onEdit=exOnEdit,onRefresh=exOnRefresh,valueFromState=exValueFromState}
en:
gEditor{|OBJECT of {gtd_num_conses,gtd_conses}|} ce=:{Editor|genUI=exGenUI,onEdit=exOnEdit,onRefresh=exOnRefresh,valueFromState=exValueFromState} _ _ _
wordt:
gEditor2{|OBJECT of {gtd_num_conses,gtd_conses}|} _ ce=:{Editor|genUI=exGenUI,onEdit=exOnEdit,onRefresh=exOnRefresh,valueFromState=exValueFromState}
Dus in beide gevallen hernoemen, een _ toevoegen als 2de argument en de 3 _'s aan het einde weghalen, omdat gText,JSONEncode en JSONDecode niet nodig zijn.
In de definitie module voegen we dan toe:
generic gEditor2 a | gEditor a :: Editor a
derive gEditor2
OBJECT of {gtd_num_conses,gtd_conses} with _ gEditor,
RECORD of {grd_arity} with _ gEditor
Ik heb dit getest met BasicAPIExamples.EditorsOnCustomTypes.EnterPerson.
Om het deriven makkelijker te maken definieer ik:
class iTaskEditor2 a | gEditor2{|*|}, gText{|*|}, JSONEncode{|*|}, JSONDecode{|*|}, gEq{|*|} a
Ik kan nu:
derive class iTask Person
vervangen door:
derive class iTaskEditor2 Person
gEditor{|Person|} = gEditor2{|*|}
En gEditor{|Person|} kan ik nu aanpasen, voorbeeld om te zien wanneer hij wordt
aangeroepen:
gEditor{|Person|}
| trace_tn "gEditor Person"
= gEditor2{|*|}
Maar je zou bijvoorbeeld ook de editor kun customizen.
Met vriendelijke groet,
John
```
</details>John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/83Faulty strictness analysis?2020-11-19T15:21:20+01:00Camil StapsFaulty strictness analysis?The program below aborts with `1`, whereas I would expect `2` because `x` does not need to be evaluated in `f`. The same problem occurs when using guards. When `f` is exported the compiler gives a warning that not all derived strictness ...The program below aborts with `1`, whereas I would expect `2` because `x` does not need to be evaluated in `f`. The same problem occurs when using guards. When `f` is exported the compiler gives a warning that not all derived strictness is exported and the first parameter is strict.
This happens on the current master and itask compilers.
```clean
f :: a -> a
f x = if False x (abort "2\n")
Start = f (abort "1\n")
```John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/82Duplicate errors with class constraints2021-04-09T14:07:15+02:00Colin de RoosDuplicate errors with class constraintsWhen defining instances with free variables of classes with constraints, these constraints have to be repeated to be able to use them in the instance definition. However, this leads to duplicated error messages:
```
class Test a | + a w...When defining instances with free variables of classes with constraints, these constraints have to be repeated to be able to use them in the instance definition. However, this leads to duplicated error messages:
```
class Test a | + a where
test :: a a -> a
instance Test a | + a where
test x y = x + y
Start = test "" ""
```
gives the errors:
```
Overloading error [main.icl,11,Start]: "+" no instance available of type String
Overloading error [main.icl,11,Start]: "+" no instance available of type String
```
I would expect the error to occur only once
Environment: iTasks with -aui compiler flaghttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/81Runtime error with functional dependencies in class contexts2021-04-08T13:32:38+02:00Colin de RoosRuntime error with functional dependencies in class contextsHi, I'm getting a runtime error with functional dependencies in class contexts:
```hs
class ~= a | TypeEq a bool where
cast :: a
class TypeEq a ~bool1 where
typeEq :: a -> bool1
```
Error:
```
Bring up to date...
Compiling...
Anal...Hi, I'm getting a runtime error with functional dependencies in class contexts:
```hs
class ~= a | TypeEq a bool where
cast :: a
class TypeEq a ~bool1 where
typeEq :: a -> bool1
```
Error:
```
Bring up to date...
Compiling...
Analyzing 'main'.
[main.icl,]: .abc out of date, different compiler options. (Dynamics)
Compiling 'main'.
Run time error, selector does not matchread failed 0
```
I would expect this to work, or at least give a clear error.
Environment: iTasks with -aui compiler flaghttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/80Runtime error with dynamics in default definitions2021-04-08T13:35:37+02:00Colin de RoosRuntime error with dynamics in default definitionsHi, I'm getting a runtime error when trying to use dynamics in default definitions:
```hs
class test a where
test :: a -> a | TC a
test y =
case (dynamic y) of
(y :: a^) = y
instance test Int, Bool
```
Error:
```
Bring u...Hi, I'm getting a runtime error when trying to use dynamics in default definitions:
```hs
class test a where
test :: a -> a | TC a
test y =
case (dynamic y) of
(y :: a^) = y
instance test Int, Bool
```
Error:
```
Bring up to date...
Compiling...
Analyzing 'main'.
[main.icl,]: no abc file
Compiling 'main'.
Run time error, rule '<case>[line:2591];15;746' in module 'type' does not match
read failed 0
```
I would expect this to work, or at least give a clear error of some sort.
Edit: Environment: iTasks with -aui compiler flaghttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/79Crash due to "make dictionary fields for 0 arity members lazy"2020-10-29T08:08:15+01:00Camil StapsCrash due to "make dictionary fields for 0 arity members lazy"The program attached below (main module is MBQS.Languages.Grammar) crashes on the current master compiler with a segmentation fault. According to `git bisect` this was introduced in https://gitlab.science.ru.nl/clean-compiler-and-rts/com...The program attached below (main module is MBQS.Languages.Grammar) crashes on the current master compiler with a segmentation fault. According to `git bisect` this was introduced in https://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/commit/5ccd651ccc4703b7954e0ac18d429edf3558e13d.
[crash.tar.gz](/uploads/3bb923d57642aa3041267cbccef737f8/crash.tar.gz)John van GroningenJohn van Groningenhttps://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/issues/78Cycle in spine introduced by "remove first argument type for BESetMemberTypeO...2020-10-21T17:01:22+02:00Camil StapsCycle in spine introduced by "remove first argument type for BESetMemberTypeOfField"After commit https://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/commit/6c39cd56e31b53445c5814ec3b2702f4e9e6a8e6, the following program crashes with a cycle in spine:
```clean
import Clean.Types.Parse
Start = parseType ['Int'...After commit https://gitlab.science.ru.nl/clean-compiler-and-rts/compiler/-/commit/6c39cd56e31b53445c5814ec3b2702f4e9e6a8e6, the following program crashes with a cycle in spine:
```clean
import Clean.Types.Parse
Start = parseType ['Int']
```
You can find Clean.Types.Parse in Platform.John van GroningenJohn van Groningen