mirror of
https://github.com/github/semantic.git
synced 2024-11-24 17:04:47 +03:00
Merge branch 'master' into normalize-unevaluated-module-tables
This commit is contained in:
commit
02f5c332e4
@ -145,13 +145,12 @@ expressionChoices =
|
||||
, continue
|
||||
, constructorDeclaration
|
||||
, explicitConstructorInvocation
|
||||
-- , constantDeclaration
|
||||
-- , TODO: constantDeclaration
|
||||
, doWhile
|
||||
, fieldDeclaration
|
||||
, float
|
||||
, for
|
||||
, enum
|
||||
-- , hexadecimal
|
||||
, if'
|
||||
, interface
|
||||
, identifier
|
||||
@ -239,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
|
||||
@ -257,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)
|
||||
-- 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)
|
||||
|
||||
@ -281,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)
|
||||
@ -318,14 +293,9 @@ 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 = do
|
||||
loc <- symbol PackageDeclaration -- location which is calling the symbol API
|
||||
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)
|
||||
package = makeTerm <$> symbol PackageDeclaration <*> children (Java.Syntax.Package <$> someTerm expression)
|
||||
|
||||
enum :: Assignment
|
||||
enum = makeTerm <$> symbol Grammar.EnumDeclaration <*> children (Java.Syntax.EnumDeclaration <$> term identifier <*> manyTerm enumConstant)
|
||||
@ -515,12 +485,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 []))
|
||||
@ -540,14 +508,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
|
||||
|
Loading…
Reference in New Issue
Block a user