On Mon, Oct 22, 2018 at 11:59 AM Hongwei Xi wrote:
> It is all explained here:
>
> https://github.com/githwxi/ATS-Xanadu/blob/master/docgen/SYNTAX/fixity.txt
>
> #infix0 : infix with no associativity
> #infixl : infix with left associativity
> #infixr : infix with right associativity
Thanks.
Ah...
```
$ git grep infix0 | cat
docgen/SYNTAX/fixity.txt:#infix0 foo2 bar2
docgen/SYNTAX/fixity.txt:#infix0 baz of 71
prelude/fixity.sats:#infix0 < <= > >= of 40
prelude/fixity.sats:#infix0 = != == !== of 30
prelude/fixity.sats:#infix0 := of 0 // HX: assign
prelude/fixity.sats:#infix0 :=: of 0
On Mon, Oct 22, 2018 at 11:43 AM Kiwamu Okabe wrote:
> How about introduce your infix syntax such like Haskell?
>
> "Infix Functions In Haskell"
> https://wuciawe.github.io/functional%20programming/haskell/2016/07/03/infix-functions-in-haskell.html
>
> The infix syntax in Haskell has:
>
> A.
I have question: what is different on following?:
* #infix0
* #infixl
* #infixr
How about introduce your infix syntax such like Haskell?
"Infix Functions In Haskell"
https://wuciawe.github.io/functional%20programming/haskell/2016/07/03/infix-functions-in-haskell.html
The infix syntax in
You can use pandoc to get manpages, TeX, etc. if you'd like :)
On 10/21/18 7:21 PM, Hongwei Xi wrote:
>
> >> text (simple text files with some formatting, markdown, or AsciiDoc)
>
> I choose this one: Text + Markdown is what I like most these days :)
>
> On Sun, Oct 21, 2018 at 8:17 PM Kiwamu
>> text (simple text files with some formatting, markdown, or AsciiDoc)
I choose this one: Text + Markdown is what I like most these days :)
On Sun, Oct 21, 2018 at 8:17 PM Kiwamu Okabe wrote:
> As a translator English to Japanese, I would like to choose `po4a` tool.
>
>
As a translator English to Japanese, I would like to choose `po4a` tool.
https://po4a.org/index.php.en
It can maintain translations on gettext, and be easy to track original update.
Could you choose your document format from followings which are supported
by po4a:
* manpages
* POD
* XML
I don't want to take the RFC route. At least not for now. ATS is too rich
and complex to be handle in this way.
I am writing some notes now. In these notes, I plan to mostly talk about
various syntax entities in ATS3 and also use concrete examples to illustrate
them.
Once I have written enough
On Mon, Oct 22, 2018 at 9:04 AM gmhwxi wrote:
> Proofs are part of dynamics. As far syntax design is concerned, writing a
> proof
> is pretty much like writing a program.
OK. I should re-draw my big picture:
http://jats-ug.metasepi.org/draw/flow.png
--
Kiwamu Okabe at METASEPI DESIGN
--
You
Proofs are part of dynamics. As far syntax design is concerned, writing a
proof
is pretty much like writing a program.
--
You received this message because you are subscribed to the Google Groups
"ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send
If `ATS-Xanadu/docgen/SYNTAX` is a specification document, not a
tutorial, we do not need to choose any format such like markdown, TeX,
SGML, XML, HTML, etc...
Let's choose your style as plain text such like RFC:
https://www.rfc-editor.org/in-notes/rfc-index.txt
But we need TOC.
--
You
I think we need `ATS-Xanadu/docgen/SYNTAX/README.md` for table of contents.
--
You received this message because you are subscribed to the Google Groups
"ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Why not introduce Proof stuff at `overview.txt `?
I believe ATS3 stands on:
* Dynamics
* Proofs
* Statics
http://cs.likai.org/ats/ml-programmers-guide-to-ats
And also the Proofs are important parts for me.
--
You received this message because you are subscribed to the Google Groups
13 matches
Mail list logo
