Re: Brackets for type parameters distracting

On Apr 30, 2008, at 4:24 AM, Akhilesh Mritunjai wrote:
>
> What I'm getting at is that syntax should strive to be intuitive,  
> non-cryptic and at same time it shouldn't be too taxing on parser  
> writers. If it's too hard to write a parser/analyzer for the  
> language, the IDEs and III party tools probably won't take off.

I'd suggest just using our parser (when the NetBeans plugin was  
contributed, Rats was described as being easy to use in this  
respect).  Fortress is, in fact, hard to parse, especially if you try  
to use an LR(1), LALR, or LL(k) parsing tool.  Syntax abstraction will  
make this harder still (because it integrates with our parser).   
Luckily the Packrat model used by Rats is pretty easy to understand.

-Jan

>
>
>
> My 2 cents
> Regards
> - Akhilesh

Re: Brackets for type parameters distracting

To fix the issue with [[...]] array indexing another (symmetric) 
brackets could be used, for example <[...]> or [<...>].

On the other hand I would prefer it be just {}:
my_func{...}(...):(...) = ...
, while current implementation of set (IIRC it is the one defined by {}) 
make as {{}} or [\\] or something else. I guess sets will be used much 
more rarely than static arguments, so {} may be used for a more common 
language operation.

Regards, D.

Re: Brackets for type parameters distracting

David Chase wrote:
> opr BIG UNIONUNION(g:(Reduction⟦Map⟦ZZ32,List⟦String⟧⟧⟧,
>                       Map⟦ZZ32,List⟦String⟧⟧->Map⟦ZZ32,List⟦String⟧⟧)->
>                         Map⟦ZZ32,List⟦String⟧⟧):Map⟦ZZ32,List⟦String⟧⟧ =
>     embiggen⟦Map⟦ZZ32, List⟦String⟧⟧⟧(fn(a,b) => a UNIONUNION b,
>                                             mapping⟦ZZ32,List⟦String⟧⟧(),
>                                             g)
My 2 cents:
still I think too many brackets, like "⟧⟧⟧" above, make code difficult 
to read and edit. Using {} would be better (is it so hard to check is it 
used for fortress *set* type or for these args from function definition?).

Also, I think definitions w/o args like the one above with () should be 
made with () being optional or absent at all.
D.

Re: Brackets for type parameters distracting

In my opinion, white brackets are great and [\ \] is really not a big
deal. People should probably concentrate more on IDEs for Fortress
than finding a temporary solution. I don't care how the scaffolding
looks like, only the façade matters.

As an aside, wouldn't it be great to be able to write:

type IntToStrings = Map[\ZZ32,List[\String\]\]

before that expression?

On Mon, May 12, 2008 at 7:36 PM, David Chase <dr2chase@...> wrote:
> We're discussing this in our weekly meeting, not reaching consensus,
>  and curious to know what other people think.  This example comes
>  from the recently created wordcount demo, and was chosen because
>  it's hard to read.  Here's four versions (better viewed in a fixed font,
>  not only does that line up the indents, that's also what people will
>  probably use to edit code in this form):
>
>  (1) status quo:
>
>  opr BIG UNIONUNION(g:(Reduction[\Map[\ZZ32,List[\String\]\]\],
>
> Map[\ZZ32,List[\String\]\]->Map[\ZZ32,List[\String\]\])->
>
> Map[\ZZ32,List[\String\]\]):Map[\ZZ32,List[\String\]\] =
>     embiggen[\Map[\ZZ32, List[\String\]\]\](fn(a,b) => a UNIONUNION b,
>
> mapping[\ZZ32,List[\String\]\](),
>                                             g)
>
>  (2) [[ and ]]:
>
>  opr BIG UNIONUNION(g:(Reduction[[Map[[ZZ32,List[[String]]]]]],
>
> Map[[ZZ32,List[[String]]]]->Map[[ZZ32,List[[String]]]])->
>
> Map[[ZZ32,List[[String]]]]):Map[[ZZ32,List[[String]]]] =
>     embiggen[[Map[[ZZ32, List[[String]]]]]](fn(a,b) => a UNIONUNION b,
>
> mapping[[ZZ32,List[[String]]]](),
>                                             g)
>
>  (3) [[ and ]] with some spacing:
>
>  opr BIG UNIONUNION(g:(Reduction[[Map[[ZZ32,List[[String]] ]] ]],
>                       Map[[ZZ32,List[[String]] ]]->Map[[ZZ32,List[[String]]
> ]])->
>                         Map[[ZZ32,List[[String]]
> ]]):Map[[ZZ32,List[[String]] ]] =
>     embiggen[[Map[[ZZ32, List[[String]] ]] ]](fn(a,b) => a UNIONUNION b,
>                                               mapping[[ZZ32,List[[String]]
> ]](),
>                                               g)
>
>  (4) with actual white square brackets, no other formatting (might not
>  display if no font on your box has the character(s) 27E6 and 27E7):
>
>  opr BIG UNIONUNION(g:(Reduction⟦Map⟦ZZ32,List⟦String⟧⟧⟧,
>                       Map⟦ZZ32,List⟦String⟧⟧->Map⟦ZZ32,List⟦String⟧⟧)->
>                         Map⟦ZZ32,List⟦String⟧⟧):Map⟦ZZ32,List⟦String⟧⟧ =
>     embiggen⟦Map⟦ZZ32, List⟦String⟧⟧⟧(fn(a,b) => a UNIONUNION b,
>                                             mapping⟦ZZ32,List⟦String⟧⟧(),
>                                             g)
>
>  We'd like some estimate of relative awfulness -- for instance,
>  how do these proposals compare to:
>
>  (a) Python blocking with indentation
>  (b) Lisp backquote macros
>  (c) Lisp parentheses
>  (d) C declaration syntax
>  (e) Perl (in general)
>  (f) Postscript
>
>  Changes could still get tangled up in parsing issues, but we're trying to
>  get a feel for whether [\ \] is a short-term annoyance, or something that
>  will bother people every time they use the language.
>
>  David
>
>
>

Re: Brackets for type parameters distracting

Re: Brackets for type parameters distracting