1
1
mirror of https://github.com/github/semantic.git synced 2024-11-24 17:04:47 +03:00

remove CRRRAZY comments

This commit is contained in:
Ayman Nadeem 2018-06-01 14:08:49 -07:00
parent 576057bb82
commit 3da883460c

View File

@ -238,16 +238,6 @@ scopedIdentifier = makeTerm <$> symbol ScopedIdentifier <*> children (Expression
superInterfaces :: Assignment.Assignment [] Grammar [Term]
superInterfaces = symbol SuperInterfaces *> children (symbol InterfaceTypeList *> children(manyTerm type'))
-- a *> b
-- both of these are impure
-- getLine *> getLine
-- in half apply, they're both monadic impure actions
-- :t (<$)
-- :t (*>)
-- what does it mean to say monadic action? more precise term: sequence-able
-- a sequence of applicative actions can be executed left to right
-- applicative computations can't do branch and control flow; applicative computations can only compute in a direct line, monadic can compute arbitrary branches
-- Declarations
class' :: Assignment
@ -256,19 +246,11 @@ class' = makeTerm <$> symbol ClassDeclaration <*> children (makeClass <$> many m
makeClass modifiers identifier typeParams superClass superInterfaces = Declaration.Class (modifiers ++ typeParams) identifier (maybeToList superClass ++ superInterfaces) -- not doing an assignment, just straight up function
classBody = makeTerm <$> symbol ClassBody <*> children (manyTerm expression)
superClass = symbol Superclass *> children type'
-- matching term expression won't work since there is no node for that; it's AnonExtends
-- superClass = makeTerm <$> symbol SuperClass <*> children (Java.Syntax.SuperClass <$> term expression <*> type')
-- We'd still like to match the SuperClass node, but we don't need to create a syntax to make a term
-- Do you lose info by omitting the superclass term? No...
-- Don't need to make a term since we're not using syntax
-- what's the difference between using tokens: AnonExtends GenericType?
-- optional: when something can or can't exist and you want to produce a Maybe
-- TODO: superclass -- need to match the superclass node when it exists (which will be a rule, similar to how the type params rule matches the typeparams node when it exists)
-- optional, when we have a single term
-- superInterfaces is also optional but since it produces a list, lists already have an empty value so we don't need to wrap it up in a maybe to get an empty value
-- TODO: superclass
-- need to match the superclass node when it exists (which will be a rule, similar to how the type params rule matches the typeparams node when it exists)
-- optional, when we have a single term
-- superInterfaces is also optional but since it produces a list, lists already have an empty value so we don't need to wrap it up in a maybe to get an empty value
-- define this at the top level, we may change TS grammar so that if someone wants to write a Java snippet we could assign
-- it correctly; fieldDeclaration is standalone (compared to a type, which doesn't say anything by itself)
fieldDeclaration :: Assignment
fieldDeclaration = makeTerm <$> symbol FieldDeclaration <*> children ((,) <$> manyTerm modifier <*> type' <**> variableDeclaratorList)
@ -280,14 +262,8 @@ method = makeTerm <$> symbol MethodDeclaration <*> children (makeMethod <$> many
methodHeader = symbol MethodHeader *> children ((,,,,) <$> (typeParameters <|> pure []) <*> manyTerm annotation <*> type' <*> methodDeclarator <*> (throws <|> pure []))
makeMethod modifiers receiver (typeParams, annotations, returnType, (name, params), throws) = Declaration.Method (returnType : modifiers ++ typeParams ++ annotations ++ throws) receiver name params
-- TODO: add genericType
-- Question: should this genericType be part of type or not? Its own type because it's different structurally
generic :: Assignment
generic = makeTerm <$> symbol Grammar.GenericType <*> children(Java.Syntax.GenericType <$> term type' <*> manyTerm type')
-- when do we make a term again? - if we want to wrap something in a syntax constructor, because each piece of syntax
-- will be populated by further terms inside it. in this case, we wrap two terms in a piece of syntax.
-- Q to help decide: do we lose anything by omitting the term?
methodInvocation :: Assignment
methodInvocation = makeTerm <$> symbol MethodInvocation <*> children (Expression.Call [] <$> (callFunction <$> expression <*> optional (token AnonDot *> expression)) <*> (argumentList <|> pure []) <*> emptyTerm)
@ -317,14 +293,13 @@ interface = makeTerm <$> symbol InterfaceDeclaration <*> children (normal <|> an
annotationType = symbol AnnotationTypeDeclaration *> children (Declaration.InterfaceDeclaration [] <$> identifier <*> annotationTypeBody)
annotationTypeBody = makeTerm <$> symbol AnnotationTypeBody <*> children (many expression)
interfaceMemberDeclaration = symbol InterfaceMemberDeclaration *> children (term expression)
-- we won't make a term because we have a choice of a bunch of things
package :: Assignment
-- package = makeTerm <$> symbol PackageDeclaration <*> children (Java.Syntax.Package <$> someTerm expression)
package = makeTerm <$> symbol PackageDeclaration <*> children (Java.Syntax.Package <$> someTerm expression)
package = do
loc <- symbol PackageDeclaration -- location which is calling the symbol API
loc <- symbol PackageDeclaration
c <- children $ do Java.Syntax.Package <$> someTerm expression
pure (makeTerm loc c) -- pure is re-wrapping it back into the outer context, which in this case is Assignment (ie., the return type of the function)
pure (makeTerm loc c)
enum :: Assignment
enum = makeTerm <$> symbol Grammar.EnumDeclaration <*> children (Java.Syntax.EnumDeclaration <$> term identifier <*> manyTerm enumConstant)
@ -514,12 +489,10 @@ constructorDeclaration = makeTerm <$> symbol ConstructorDeclaration <*> children
constructor modifiers (typeParameters, identifier, formalParameters) = Java.Syntax.Constructor modifiers typeParameters identifier formalParameters -- let partial application do its thing
typeParameters :: Assignment.Assignment [] Grammar [Term]
typeParameters = symbol TypeParameters *> children (manyTerm typeParam) -- this produces a list, which is what we need to return given by the type definition
typeParameters = symbol TypeParameters *> children (manyTerm typeParam)
where
typeParam = makeTerm <$> symbol Grammar.TypeParameter <*> children (Java.Syntax.TypeParameter <$> manyTerm annotation <*> term identifier <*> (typeBound <|> pure [])) -- wrapping up all three of those fields so we need to makeTerm (producing a term here)
typeParam = makeTerm <$> symbol Grammar.TypeParameter <*> children (Java.Syntax.TypeParameter <$> manyTerm annotation <*> term identifier <*> (typeBound <|> pure []))
typeBound = symbol TypeBound *> children (manyTerm type')
-- manyTerm typeParam made sense because each type Parameter was wrapped up into a Grammar.TypeParameter node, dissimilar
-- to superInterfaces
annotation :: Assignment
annotation = makeTerm <$> symbol NormalAnnotation <*> children (Java.Syntax.Annotation <$> term expression <*> (elementValuePairList <|> pure []))
@ -539,14 +512,6 @@ formalParameters = manyTerm parameter
parameter = makeTerm <$> symbol FormalParameter <*> children (makeAnnotation <$> manyTerm modifier <*> type' <* symbol VariableDeclaratorId <*> children identifier)
makeAnnotation [] type' variableName = Type.Annotation variableName type'
makeAnnotation modifiers type' variableName = Type.Annotation variableName (makeTerm1 (Java.Syntax.TypeWithModifiers modifiers type'))
-- know when we are in a functor context and fmap is all gravy
-- we're just wrapping stuff up in data, we aren't building a pattern (assignment) so we aren't in an applicative context
-- when in an applicative context, we're also in a functor context (ie., defining how fmap will work over it)
-- sometimes it is nice to be able to say you're in an applicative context without refering to any particular applicative instance
-- constantDeclaration :: Assignment
-- constantDeclaration = makeTerm <$> symbol ConstantDeclaration <*>
castExpression :: Assignment
castExpression = makeTerm <$> symbol CastExpression <*> children (flip Type.Annotation <$> type' <*> term expression)
-- term expression, because we can deal with comments