Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 11 19:32

    greggirwin on master

    cs/DT/float.adoc modified Merge branch 'master' of https:… docs-cs: cs/(float, reactivity,… and 1 more (compare)

  • Aug 11 19:32
    greggirwin closed #186
  • Aug 11 09:00
    Tovim opened #186
  • Aug 07 15:51

    dockimbel on master

    FEAT: describes more explicitly… (compare)

  • Aug 07 15:19

    dockimbel on master

    FEAT: adds the default value bl… (compare)

  • Jul 31 12:13
    meijeru opened #185
  • Jul 19 22:36

    greggirwin on master

    docs-cs: DT/pair.adoc Merge pull request #183 from To… (compare)

  • Jul 19 22:36
    greggirwin closed #183
  • Jul 15 18:01

    greggirwin on master

    Fixed typo in line 7 Some cleanup of float.adoc Merge pull request #184 from gl… (compare)

  • Jul 15 18:01
    greggirwin closed #184
  • Jul 15 04:32
    gltewalt synchronize #184
  • Jul 15 04:06
    gltewalt opened #184
  • Jun 18 09:23
    Tovim opened #183
  • Jun 16 18:05

    greggirwin on master

    Created README file Merge pull request #182 from en… (compare)

  • Jun 16 18:05
    greggirwin closed #182
  • Jun 16 14:11
    endo64 opened #182
  • Jun 14 17:13
    greggirwin commented #181
  • Jun 14 17:12

    greggirwin on master

    pair! comparison Merge pull request #181 from lo… (compare)

  • Jun 14 17:12
    greggirwin closed #181
  • Jun 14 10:28
    loziniak opened #181
Greg T
@gltewalt
EBNF is a no go?
Gregg Irwin
@greggirwin
IIRC, Peter said Nenad preferred straight BNF for this. Certainly we can and should offer various grammars to help people.
Greg T
@gltewalt
See if you can get the go-ahead for parse or ebnf (for examples in addition to the main bnf example)
Greg T
@gltewalt
word/selector/ is an invalid path, isn't it?
<word-literal>/<selector>/ wouldn't work
Gregg Irwin
@greggirwin
Correct.
Toomas Vooglaid
@toomasv

I wonder if following in the spec doc is correct:

             | /<word-literal>                          ; refinement!
             | #<word-literal>                          ; issue!

In case of both issue and refinement, differently from <word-literal> as explained in 5.2.5, they may also start with number and ' (although such refinement cannot be used in function).

Also, it may be worth mentioning that while < and > may appear in words, <> can only form stand-alone word; neither can <...> be part of any word.

Rudolf Meijer
@meijeru
@toomasv You are right on refinement and issue. I will need to be more subtle there. Also the remarks on < and > are to the point.
Rudolf Meijer
@meijeru
@greggirwin Evaluation rules for Red values occurring in a user-defined dialect are of necessity themselves user-defined. Therefore they have no place in a Reference or Spec document. The user may wish to define the dialect semantics using a combination of formal syntax and procedural evaluation rules (although other approaches are quite possible as well) and in that case will probably opt for their own syntax which I can't prejudge.
@gltewalt @greggirwin Coming to think of it, using "parse syntax" in the Reference document would be a good publicity for parse, and it is at least as readable as (E)BNF.
Gregg Irwin
@greggirwin
:+1:
Gregg Irwin
@greggirwin
The Community link on the main wiki page goes to a non-existent Gitter-Room-Index page. Can you look at that @gltewalt?
Greg T
@gltewalt
Fixed
Gregg Irwin
@greggirwin
Thanks.
Gregg Irwin
@greggirwin
@gltewalt, I merged updated Česky docs from @Tovim, but the summary page isn't showing all the TOC contents, as if it hasn't updated. Do you know what the cause might be?
Greg T
@gltewalt
His summary looks right, but it stops rendering at unset!
Could be something stuck with updating, but I'm combing through it, trying to find a typo
Greg T
@gltewalt
Try #75
Greg T
@gltewalt
Datové typy (Data type, I assume) is not indented as it should be in gitbook, and it doesn't function as a link.
It looks as it should, here: https://github.com/gltewalt/docs/blob/404ff8136f08c482e687648a80e40b0b52c2a0ac/cs/SUMMARY.adoc
My only guess is that gitbook has a problem with that text? Maybe Datove typy or Datovetypy would work.
Gregg Irwin
@greggirwin
Thanks for digging in.
Greg T
@gltewalt
I can try a test in local gitbook server
Greg T
@gltewalt
Works on local gitbook server as Datové typy, and the formatting looks fine, so... scratching my head
Tovim
@Tovim
I have sent the whole whatnot to my local GitHub page, consequently to my local gitbook server (https://tovim.gitbooks.io/docs-cs/content/cs/) and everything seems to be OK.
Rudolf Meijer
@meijeru
@toomasv I supplied new definitions of refinement and issue, but there is a lot of duplication of information now. The whole treatment would benefit from the introduction of a pseudo literal called "symbol" or similar. Then words would be symbols not starting with 0-9 and ', and refinements and issues would be symbols preceded by / and #. How would that sound?
Vladimir Vasilyev
@9214
@meijeru wouldn't that overlap with internal symbol! datatype?
Rudolf Meijer
@meijeru
The symbol! datatype is indeed internal and the reader of a Reference or Spec document does not need to know about its existence. On the other hand, and more importantly, the concept of a word's symbol is used in the explanation of section 6.1 of the Specs and this is precisely what is common between words, refeinements and issues. I would welcome some more comments from others (@greggirwin, @PeterWAWood) before making the change, though.
Vladimir Vasilyev
@9214
Giving that they are all members of all-word! typeset, I very much welcome such conceptual unification. :+1:
But it's a little bit confusing in my view, since 'symbol', as a term, to me associates with something that has 'referential capacity', which neither issue! nor refinement! have.
Rudolf Meijer
@meijeru
The use of symbol in this context was not initiated by me, but I have taken it from some text by @dockimbel only I don't remember where I found it ;-)
To go even further, I could envisage all-word! to be renamed symbolic!...
Toomas Vooglaid
@toomasv
@meijeru IMO using <symbol-literal> would be good choice. It would be somewhat similar to how series implementation type is reflected by series! typeset.
Vladimir Vasilyev
@9214

To go even further, I could envisage all-word! to be renamed symbolic!...

I leave it to someone with PhD in semiotic studies to rule out :smile:

Toomas Vooglaid
@toomasv
@9214 In a broad sense all lexemses are symbolic as they represent something binary deep down and also something conceptual high up. In much stricter sense I see what you mean by referencial capacity. Some might also prefer <wordish-literal> :laughing:
Rudolf Meijer
@meijeru
In the Lisp world (notably Scheme and Racket) they have symbols too, and the explanation there is: "a symbol is like an immutable string that happens to be interned so that symbols can be compared with eq? (fast, essentially pointer comparison). Symbols and strings are separate data types."
I offer that as a support for the terminology, even though Red is different in many respects...
Vladimir Vasilyev
@9214
@meijeru in that sense issues and refinements can be considered as interned strings (i.e. symbols in Lisp parlance). But words are interned strings + other interesting things.
I'm ok with that as long as there is a clean explanation of the terminology and generally accepted glossary.
Rudolf Meijer
@meijeru
Went ahead with the changes. Have a look! Specs sections 3.2 and 5.2.5 notably.
Vladimir Vasilyev
@9214
:+1:
Toomas Vooglaid
@toomasv
@meijeru Great! (There is typo in 5.2.16 # character on first line is not visible)
mikeparr
@mikeparr
@meijeru - In section S111 - " An <integer-literal> is written as a signed integer number ... " then the example shows unsigned numbers - confusing?
Rudolf Meijer
@meijeru
@mikeparr The examples are: Examples: 123 -123 +0001 1'000. There is one negative number, isn't there?
Rudolf Meijer
@meijeru
@toomasv Thanks, will be corrected.
mikeparr
@mikeparr
@meijeru I assumed 'signed' to mean a + or - is compulsory.
Rudolf Meijer
@meijeru
I meant signed to mean spanning negative and positive ranges. If that is confusing I can omit the word, because the range is explicitly indicated. Should I add "a + sign is allowed but not compulsory"?
Same thing for floats BTW
mikeparr
@mikeparr
@meijeru Ah, I understand. Personally, I think it is clearer to insert the "a + sign is allowed..etc"
Rudolf Meijer
@meijeru
Done.
Gregg Irwin
@greggirwin

A good an interesting topic. Thanks to all for giving it due thought. Symbol!, AFAIK is an implementation detail and, as @meijeru said, not part of the language proper. Whether we can safely leverage that term without confusion I don't know. It would be nice, as it's a strong word.

Refinement and issue types both stem from word today (pun somewhat intended), but the lexer uses symbol terminology in a couple word-related rules. As we know, those two types simply don't enforce the same limitation on the starting chars. That is when lexing, not post-processed to identify types. begin-symbol-rule vs symbol-rule.

I like @meijeru's change here, and think we're on fairly solid ground to justify it.

mikeparr
@mikeparr
@meijeru In the whole spec, there are 3 mentions of 'id.' I'm not sure what this means - value perhaps?