On 01/14/2017 02:38 AM, Alex Buckley wrote:
On 1/13/2017 3:52 PM, Stephan Herrmann wrote:
Speaking of which, I'm confused by these sentences:
7.2:
"The host system is free to decide that a compilation unit containing a
module declaration is not, in fact, associated with the module declared
ther
On 1/13/2017 3:52 PM, Stephan Herrmann wrote:
Speaking of which, I'm confused by these sentences:
7.2:
"The host system is free to decide that a compilation unit containing a
module declaration is not, in fact, associated with the module declared
therein."
Should be "an observable compilation
On 01/08/2017 08:13 PM, Stephan Herrmann wrote:
[...]
Lastly, with the interplay of things defined in JLS vs. observability
which is subject to the host system, I wonder if JLS will at least include
"recommendations" regarding the structure of directories and compilation
units. The same holds for
On 1/12/2017 3:44 AM, Stephan Herrmann wrote:
On 01/10/2017 11:24 PM, Alex Buckley wrote:
On 1/10/2017 12:20 PM, Stephan Herrmann wrote:
Can a module export a package even if no compilation units of that
package
are associated with the current module? The export might only affect
types
exported
On 01/10/2017 11:24 PM, Alex Buckley wrote:
On 1/10/2017 12:20 PM, Stephan Herrmann wrote:
Can a module export a package even if no compilation units of that package
are associated with the current module? The export might only affect types
exported from some other required module. Is that allow
On 1/10/2017 12:20 PM, Stephan Herrmann wrote:
On 01/07/2017 01:37 AM, Alex Buckley wrote:
On 1/4/2017 12:44 PM, Stephan Herrmann wrote:
Given that types are identified by qualified names that
do not contain the module name, this distinction doesn't seem to be
possible per JLS.
Per 7.3, javac
On 01/07/2017 01:37 AM, Alex Buckley wrote:
On 1/4/2017 12:44 PM, Stephan Herrmann wrote:
Given that types are identified by qualified names that
do not contain the module name, this distinction doesn't seem to be
possible per JLS.
Per 7.3, javac is associating a first other.Other type with mo
On 1/8/2017 11:13 AM, Stephan Herrmann wrote:
I'm also surprised that some requirements are indeed specified with
regard to compilation units. Modules export packages, and types are
declared in packages. Isn't it possible to define requirements due to
JPMS solely in those terms (modules, packages
Hi Alex,
On 01/07/2017 01:37 AM, Alex Buckley wrote:
On 1/4/2017 12:44 PM, Stephan Herrmann wrote:
Yes, and I owe you some apologies for this. The "visibility of a declaration"
is an obscure corner of the scope rules, and I intend
to rename it. Visibility will unambiguously be "of a compilation
On 1/4/2017 12:44 PM, Stephan Herrmann wrote:
I have started to dig through the JLS changes (2016-12-16) to figure out
requirements for a Java 9 compiler without consulting javac, but I'm
having some difficulties understanding the interplay of scope,
visibility, importing, accessibility and obser
I have started to dig through the JLS changes (2016-12-16) to figure out requirements for a Java 9 compiler without consulting
javac, but I'm having some difficulties understanding the interplay of scope, visibility, importing, accessibility and observability
at this level.
For instance, this a
On 11/16/2016 03:28 PM, Stephan Herrmann wrote:
On 11/17/2016 12:10 AM, Alex Buckley wrote:
On 11/16/2016 3:03 PM, Stephan Herrmann wrote:
On 11/16/2016 11:57 PM, Alex Buckley wrote:
On 11/16/2016 2:26 PM, Stephan Herrmann wrote:
And we may safely assume regularity of the grammar, i.e.,
the
On 11/17/2016 12:10 AM, Alex Buckley wrote:
On 11/16/2016 3:03 PM, Stephan Herrmann wrote:
On 11/16/2016 11:57 PM, Alex Buckley wrote:
On 11/16/2016 2:26 PM, Stephan Herrmann wrote:
And we may safely assume regularity of the grammar, i.e.,
the above approach will never lead to ambiguities, rig
On 11/16/2016 3:03 PM, Stephan Herrmann wrote:
On 11/16/2016 11:57 PM, Alex Buckley wrote:
On 11/16/2016 2:26 PM, Stephan Herrmann wrote:
And we may safely assume regularity of the grammar, i.e.,
the above approach will never lead to ambiguities, right?
Fictitious counter example
ModuleDe
On 11/16/2016 11:57 PM, Alex Buckley wrote:
On 11/16/2016 2:26 PM, Stephan Herrmann wrote:
And we may safely assume regularity of the grammar, i.e.,
the above approach will never lead to ambiguities, right?
Fictitious counter example
ModuleDeclaration:
module open Identifier ModuleBo
On 11/16/2016 02:55 PM, Stephan Herrmann wrote:
On 11/16/2016 11:35 PM, Jonathan Gibbons wrote:
On 11/16/2016 02:26 PM, Stephan Herrmann wrote:
Still no good news for tools wishing to process just a fragment of
the text.
Just how small a fragment, and in how unknown a context are you
w
On 11/16/2016 2:26 PM, Stephan Herrmann wrote:
And we may safely assume regularity of the grammar, i.e.,
the above approach will never lead to ambiguities, right?
Fictitious counter example
ModuleDeclaration:
module open Identifier ModuleBody;
module Identifier ModuleBody;
With
On 11/16/2016 11:35 PM, Jonathan Gibbons wrote:
On 11/16/2016 02:26 PM, Stephan Herrmann wrote:
Still no good news for tools wishing to process just a fragment of the text.
Just how small a fragment, and in how unknown a context are you worried about?
Yes, if you're wanting to locally a
On 11/16/2016 1:41 PM, Stephan Herrmann wrote:
On 11/16/2016 10:02 PM, Alex Buckley wrote:
[...]
Make a close reading of JLS 2.2. It's true that identifiers are
terminal symbols of the _syntactic grammar_. However, I want to
speak of 'open', 'module', et al as terminal symbols of the _lexical
gr
On 11/16/2016 02:34 PM, Stephan Herrmann wrote:
On 11/16/2016 11:19 PM, Jonathan Gibbons wrote:
On 11/16/2016 02:08 PM, Stephan Herrmann wrote:
On 11/16/2016 10:02 PM, Alex Buckley wrote:
- If you lex 'package', then the sequence must parse as the first
alternative.
- If you don't lex 'pac
On 11/16/2016 02:26 PM, Stephan Herrmann wrote:
On 11/16/2016 11:01 PM, Jonathan Gibbons wrote:
On 11/16/2016 01:41 PM, Stephan Herrmann wrote:
At the end of the day we need full pattern matching right?
Not really, at least, not in javac.
Words like 'module', 'requires', etc are lexed a
On 11/16/2016 11:19 PM, Jonathan Gibbons wrote:
On 11/16/2016 02:08 PM, Stephan Herrmann wrote:
On 11/16/2016 10:02 PM, Alex Buckley wrote:
- If you lex 'package', then the sequence must parse as the first alternative.
- If you don't lex 'package', but rather lex 'import', then parsing is
am
On 11/16/2016 11:01 PM, Jonathan Gibbons wrote:
On 11/16/2016 01:41 PM, Stephan Herrmann wrote:
At the end of the day we need full pattern matching right?
Not really, at least, not in javac.
Words like 'module', 'requires', etc are lexed as identifiers. When we get to
the point where the
On 11/16/2016 02:08 PM, Stephan Herrmann wrote:
On 11/16/2016 10:02 PM, Alex Buckley wrote:
- If you lex 'package', then the sequence must parse as the first
alternative.
- If you don't lex 'package', but rather lex 'import', then parsing
is ambiguous until you've looked ahead to lex either '
On 11/16/2016 10:02 PM, Alex Buckley wrote:
- If you lex 'package', then the sequence must parse as the first alternative.
- If you don't lex 'package', but rather lex 'import', then parsing is
ambiguous until you've looked ahead to lex either 'open',
'module', or a keyword that can start TypeDe
On 11/16/2016 01:41 PM, Stephan Herrmann wrote:
At the end of the day we need full pattern matching right?
Not really, at least, not in javac.
Words like 'module', 'requires', etc are lexed as identifiers. When we
get to the point where the grammar would accept one of these words as a
ke
Alex,
I understand the motivation of not breaking existing code that uses these as
identifiers.
I just want to understand the precise rules and figure out if any established
technology
can recognize the desired language.
On 11/16/2016 10:02 PM, Alex Buckley wrote:
[...]
Make a close reading o
On 11/15/2016 6:34 AM, Stephan Herrmann wrote:
On 11/15/2016 12:20 AM, Alex Buckley wrote:
You have a lot of questions here, mainly not about the OpenJDK
implementation of JSR 379 but rather about JSR 379 itself. I'm
working on JLS text that will be presented alongside lang-vm.html in
the next f
Hi Alex,
On 11/15/2016 12:20 AM, Alex Buckley wrote:
You have a lot of questions here, mainly not about the OpenJDK implementation
of JSR 379 but rather about JSR 379 itself. I'm
working on JLS text that will be presented alongside lang-vm.html in the next
few weeks, but here are some quick p
overloading. Has anything been
planned/discussed in this direction?
In Java 8, any package-qualified type name is sufficient for identifying a type
during compilation. Will the same assumption also hold for compiling Java 9, or
is a compiler required to distinguish identically named types from
alified type name is sufficient for identifying a type
during compilation. Will the same assumption also hold for compiling Java 9, or
is a compiler required to distinguish identically named types from different
modules? While this seems to be a question of compiler implementation only, it
also seems
31 matches
Mail list logo
