openstrat/Lobby

Rich

@Rich2

@w0d BNF vs EBNF vs ABNF. My first instinct is to go with EBNF.

w0d

@w0d

@rich same here

w0d

@w0d

@Rich2 if you can write an EBNF for RSON i can use that to generate a transpiler for RSON/javascript ;)

StephenMainwaring

@StephenMainwaring

Just joined. Having a look around...

w0d

@w0d

@StephenMainwaring Hi there, feel free to ask any questions etc

Rich

@Rich2

@StephenMainwaring Hi, there. Welcome, like Rod said feel free to ask any questions, documentation is improving, but there is still much that is a bit obscure at the moment.

w0d

@w0d

@Rich2 is AppStr working atm?

Rich

@Rich2

@w0d No the parsing is broken, will look into further tomorrow.

w0d

@w0d

Cheers as need to test the new parameters for Text[Graphic|Outline]

w0d

@w0d

thanks for the workaround :)

w0d

@w0d

@Rich2 Im wondering if you've plans for the Geometry and Vector Graphics library to utilise bitmaps?

Rich

@Rich2

@w0d As a temporary measure just change the string at Dev/src/ostrat/pDev/Apps.scala 71, 90. Don't worry about commiting your workflow changes to this value. I'd like to take my time over a systematic fix.

w0d

@w0d

yep had that - cheers

@Rich2 not quite sure how to parameterize bold & italic in TextGraphic TextOutline - best i can think off is to have a Style parameter that 0=nornal 1=bold 2=italic 3=bold&italic - can you see a better way?

@Rich2 if i knew how to do associative arrary id be tempted to do style: {bold: true, italic:false}

Rich

@Rich2

I'd suggest just Booleans for now.

The implementation can always be optimised later.

I'm thinking there needs to be two classes. One that creates a style on the fly and covers the main defaults, and a second one that uses a style object that can be reused and allows the full panoply of styles.

Rich

@Rich2

If that were the case do we even need italics in the former?

Rich

@Rich2

@w0d What is the expectation setter for text styling these days? Is it CSS, Microsoft Word, Open/ LibreOffice or something else?

Rich

@Rich2

@w0d So it won't find a Float Token because there isn't a Float Token, only an Int Token. An Int Token can be used later on as an Expression for a Float or a Double type later.

Currently there are Float Tokens but recently I started questioning whether there should Float / Double Tokens. So under that schema "2.3" tokenised would be sequence of 3 Tokens. An IntToken followed by a DotToken followed by an IntToken.

Rich

@Rich2

The advantage of this is that it would allow "2.3" and "2.3.1" to be interpreted as version numbers abovr the AST level.

Rich

@Rich2

@w0d The Char case required Char single quotes around the letter. Its easy to get lost when parsing Strings and Chars, as its a String within a String.

Rich

@Rich2

So I'm thinking we parse from left to right. An operator Token is not an expression. An operator Token can be added to an already passed left hand side expression to create a possible infix expression with its RHS to be parsed from the remaining (unparsed at this level) objects. If the next object to the right is an OperatorToken then it can only be a prefix operator.

Rich

@Rich2

@w0d Your test case for the AlphaToken was correctly failing as underscores weren't implemented. I'm thinking AlphaToken should change name to IdentToken and that trailing undeerscores should not be allowed.

Rich

@Rich2

Also I'm wondering if there should be different Token classes for ones that start with a Capital letter and those that start with a lowercase letter. Although not strictly necessary, the distinction is easily recoverable later, capitalisation is a syntactic concern, so it feels appropriate to recognise this in the Tokeniser.

w0d

@w0d

@w0d What is the expectation setter for text styling these days? Is it CSS, Microsoft Word, Open/ LibreOffice or something else?

@Rich2 a shared one - which doesn't help - in this context html is strong but not convincing for me..

w0d

@w0d

@Rich2 thought you might find this wasm article interesting?

Rich

@Rich2

@w0d So I'm thinking that a number / Identifier Token should never be allowed to be adjacent to another number / identifier Token.

w0d

@w0d

@Rich2 sounds good

Rich

@Rich2

That restriction on the AST would give us much more freedom on the Tokeniser.

It means such things as

final override def

would not not be allowed. I presume there is similar syntax in JavaScript.

Rich

@Rich2

Even before this change, the C statement

int a, b = 5

would not be valid because ',' always has a lower precedence than '='.

w0d

@w0d

@Rich2 so keywords are in play? otherwise int a = 5 would be invalid?

Rich

@Rich2

It seems to me that succinctness of Tokens should take priority over succinctness of the Tree.

An operator ending in an '=' Char has the lowest precedence of any operator, but it has a higher precedence than commas and semicolons because these are clause and Statement delimiters respectively.

I always find it a bit tricky thinking about this stuff because the lower the precedence of an entity the higher it will be in the AST.

Rich

@Rich2

Lower precedence means more important! In syntax land

Rich

@Rich2

@w0d I slightly missed the meaning of your question no

int a = 5//not valid
a: int = 5//is valid.

There are no keywords at the syntax level. The Tokeniser and Treeicator do not care about meaning. Pure separation of concerns syntax and semantics.

There are no keywords, but there are what you might call key operators. So the ':' operator has a special syntactic position, just above assignment operators in precedence.

w0d

@w0d

@Rich2 thanks i find that helpful

w0d

@w0d

unicode letter = http://unicode.org/reports/tr31/#Default_Identifier_Syntax
??https://www.unicode.org/reports/tr31/#Figure_Code_Point_Categories_for_Identifier_Parsing

Rich

@Rich2

@w0d So I'm wondering if the type of layout orientation can be usefully generalised. Top Bottom, Left, Right.

Rich

@Rich2

@w0d Do you fancy taking on the Scala.js 0.6 => 1.0 upgrade?

w0d

@w0d

@Rich2 had a look at scala.js 1.0RC and mentioned: Drop support for sbt 0.13.x - im running sbt 1.3.4 - can u make sense of these numbers?

Rich

@Rich2

@w0d I would suggest standardising on KeyPressed and Key Released, as KeyUp and KeyDown have possible ambiguity with the Up and Down direction keys.

Sbt went from 0.13.x => 1.0.x => 1.1.x etc. So in short that's not a problem.

w0d

@w0d

@Rich2 Re: scalajs: ok will have a look over the next month/two.
re: keys: not sure the strength of that ambiguity unless you've plans for keyLeft & keyRight as well, and given also Pressed is ambiguous in itself

Where communities thrive

People

Repo info

Activity