3 kyu
Type Transpiler
54 of 206ice1000
Loading description...
Algorithms
Strings
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
I had this test case:
A < out >
-> is this correct? According to the specification, I would doubt it. It seems to be a keyword, one that requirestype
behind itFor both Kotlin and Java, since
userType
can be just aname
, having justfunctionType
anduserType
should suffice in the definition oftype
In java section:
params
should betypeParams
Python 3.8 should be enabled.
.
Random tests are pathetically weak: https://www.codewars.com/kata/reviews/5aa936340a1ff7a89d002a14/groups/5eaeb8697e8d1e00015315b6
Please write proper random tests with actual randomly-generated types of all forms ;-)
There're
<
escape sequences in the EBNF.Fixed
Thanks for Ruby translator :)
Java translation!
cheers
Why isn't
NAME
a compiled pattern? Approved though.Because I'd need to add another aliasing for
taste
andeat
, if I do that. ;) So I prefer to keep the same kind of arguments everywhere, even if it's less efficient, yes.thx!
well, it just needed to think a bit more about it... ;)
Hi,
Seems to me there are some troubles in your BNF diagrams, aren't there?
Kotlin
Java
Subsquent questions:
name
followingin/out
actually betype
too?userType
andsimpleUserType
?Kotlin:
Java:
Cheers!
(btw: I find that one harder than your "expression transpiler"... x) )
Addressed all questions in my edit except
Yes I did that just to follow Kotlin's official grammar declaration. You can edit it as you wish, as long as it doesn't break the actual syntax :)
:+1:
note: seems there aren't any tests with
in type
instead of justin name
(otherwise my code wouldn't pass). Maybe it should be turned back to name? (even if "less true"?) -> that or modify the test suite... :o (and make the kata a bit harder... x) )"Hugh" is a given name, and is weird to report back to the user. If an exclamation is intended, this should be considered a typo, and "Huh?" should be returned.
Yes, it's indeed a typo.
Somewhat difficult to fix all translations :(
Hugh is an imaginary colleague who breaks things ;)
Haskell error: TypeTranspiler.hs:2:14: Unsupported extension: ApplicativeDo
Fixed
JavaScript Translation Python Translation
aa ;)
Hi,
Is that me or the python version expects
None
instead of"Hugh?"
when the input is invalid?EDIT: btw, shouldn't
Void
rather bevoid
? (well, that doesn't matter but, just to know...)@Blind4Basics Right. Actually it expects
None
instead ofLeft "Hugh?"
. Alternately, it could expectLeft("Hugh?")
andRight("")
whereLeft
andRight
are actually preloaded classes. But that would be too annoying, just selecting a value that is special would be enough for this kata. So i pickednull
(JS) andNone
(Python) represtingLeft("Hugh?")
and strings forRight(string)
, which is based on how it was translated to JS in Type Transpiler. And i thought i gave enough message telling what should be returned.Void is a class java.lang.Void
Sure, that's not a problem. But the description should be up to date about JS and python, that's all. ;)
thx for the information. :)
@Blind4Basics Well, the description was not modified in that kata. But as you wish, updated.
I guess the Kotlin bnf should actually be the following?
If it is so, then the Java one will have to be modified as well.
This is still not complete, it can not hold cases like
() -> B
->Function0<B>
. Anyway, it is easy to guess the what the proper form should be, though the desc. need to be updated.Okey. I forget about that one, though I did accommodate it with my code :).
Thanks guys. I nearly forget the existence of this kata :)
(JS)
The description is not updated and I ran into the same issue ..
( For me, it is not easy to guess. )
@JohanWiltink Updated.
Cheers!
I also figured out
name
is redundant intype
andtypeParam
. It's always available throughuserType
->simpleUserType
, where the[ "<" typeParams ">" ]
is optional. That saved a lot of time on ambiguous parsing.