John van Groningen (59e20218) at 28 Mar 13:58
feature, allow explicit imports of generic case/instance definition...
This does not have priority for me currently. We won't have time to work on https://gitlab.com/clean-and-itasks/itasks-sdk/-/issues/476 in the foreseeable future.
John van Groningen (b1295e05) at 25 Mar 14:00
refactor: in module generics1 remove unused argument index of local...
John van Groningen (066254bd) at 25 Mar 13:14
refactor function convert_context in module generics1: pass Generic...
The following program compiles (and should), but generating bytecode gives an error:
Compiling Example
Optimising Example
Generating bytecode for Example
Unknown instruction 'eqR_a' at line 97.
Generating bytecode failed
Minimal program:
module Example
:: T = C Real
g :: T -> Bool
g t = case t of
C 0.0 = True
_ = False
Start = g (C 0.0)
John van Groningen (1960f4cb) at 12 Mar 13:39
refactor function determineProducer in module trans, remove argumen...
To explicitly import a field, the record has to be specified and imported as well. Therefore the code in the compiler for imports does not support importing a field without the record.
The compiler needs this to implement qualified fields in this case.
The following commit:
fixes this if the record of the qualified field is also specified. In that case the field can be imported because the record is known.
So for:
{'b'.T | 'b'.x = 5}
field x can now be imported from record T.
For .'b'.x this is not possible. It was however already imported by:
{'b'.T | 'b'.x = 5}
So in this case this import may now be removed:
from b import qualified :: T{..}
If the record of the qualified field is never mentioned, such an import is still required. This has not been fixed yet.
John van Groningen (cb3c1542) at 08 Mar 13:48
bug fix, if a field is qualified and only imported by a qualified i...
It is no longer accepted after:
John van Groningen (22713561) at 07 Mar 14:55
bug fix, don't allow fields without values in expressions, only in ...
John van Groningen (005640d5) at 07 Mar 12:15
bug fix, prevent compiler crash when parsing a record update that s...
John van Groningen (1574a86b) at 07 Mar 11:47
refactor module parse: the test for CharListToken to give better er...
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, Peter
A. is supported, but not with a constraint.
The attached program (main module is interpretergen
) fails to compile while I believe it should. The current master
compiler gives:
Overloading error [target.icl,491,;491;70]: "to_hword" no instance available of type a
The itask
compiler:
(THWord.0M:0 [], t)
bindAndAdjustAttrs: incompatible types (1)
The offending line is target.icl:492
, where I already tried to hint the type to the compiler using the :::
which should be superfluous.
There is one more issue, perhaps related: in interpretergen.icl
, there are several cases where overloading could not be resolved. I marked these with NB:
. I believe, for instance, that grow_a (to_hword n_a)
on line 2174 should be allowed to be grow_a n_a
because the type of n_a
is known due to new_local
on line 2164.
The attached program (main module is interpretergen
) fails to compile while I believe it should. The current master
compiler gives:
Overloading error [target.icl,491,;491;70]: "to_hword" no instance available of type a
The itask
compiler:
(THWord.0M:0 [], t)
bindAndAdjustAttrs: incompatible types (1)
The offending line is target.icl:492
, where I already tried to hint the type to the compiler using the :::
which should be superfluous.
There is one more issue, perhaps related: in interpretergen.icl
, there are several cases where overloading could not be resolved. I marked these with NB:
. I believe, for instance, that grow_a (to_hword n_a)
on line 2174 should be allowed to be grow_a n_a
because the type of n_a
is known due to new_local
on line 2164.
Does this still occur with the master branch ?
It seems useful to me to add the => qualified
construct for imports to the master compiler. It seems to be stable and there are cases where there is no easy workaround (e.g. System.Socket in https://gitlab.science.ru.nl/clean-and-itasks/clean-platform/merge_requests/248). Is there a reason why it is only supported by the iTasks compiler?
This has been added to the master compiler.
The Tonic compiler wrongly considers UserActions to have an iTask constraint, while TaskCont does not have an iTask instance.
:: UserActions r o a :== [TaskCont (Room r o a) (Task (Actor o a))]
moveAround :: (Actor o a) (UserActions r o a) (Shared (MAP r o a)) -> Task (Actor o a) | iTask r & iTask o & iTask a & Eq o
moveAround actor actions smap