gmane.comp.lang.fortress.general

Guy.Steele | 30 May 07:30

Proposal to expand set of operator words

Background:

(1) A basic principle of operator words in Fortress, as far as we are
able to support it, has been that if you know the LaTeX name for
an operator symbol, then if you leave off the backslash and write
it using uppercase letters, then that is a name for that symbol in
Fortress and "ASCII conversion" will replace that name with the
character itself.

(2) The AMS has been working with other scientific and mathematical
publishing societies and corporations to produce a comprehensive set
of freely available fonts that will cover all mathematical operatiors in
Unicode version 5.  They also plan to provide LaTeX support for these
fonts, and as part of that process will provide a LaTeX macro to name
each operator symbol for use in "math mode".  See http://www.stixfonts.org .

(3) Our plan for the last two years has been that when the AMS eventually
releases its STIX fonts (later this year, we hope), we will adopt their names
for the Unicode mathematical operators in accordance with principle (1).

(4) At present, operator words in Fortress are words that would otherwise
be regarded as identifiers except that they are distinguished by consisting
entirely of uppercase letters and underscores, and containing two distinct
letters, and neither beginning nor ending with an underscore.

(5) The reason for excluding words ending in underscore from the set of
operator words was that such words are needed as names of SI unit symbols,
for example MW_ for megawatts.  (Note that the trailing underscore indicates
that the identifier MW_ is to be set in a roman typeface (rather than italics),
which is correct style for dimensional units.)  The related prohibition against

(Continue reading)

headers

dmitrey | 30 May 08:41

Re: Proposal to expand set of operator words

as for me the solution proposed by you is good enough

on the other hand, I would better implement just possibility for 
operators to be made of any cases, both lower and upper, for example 
"SUM" and "Sum" and "sum" could be 3 different operators.

--------------------
I would propose you another modification - to omit the rule "all that is 
uppercase w/o digits is operator"
this brings problems with manual & automatic code translation to 
fortress (because these names should be changed).

for example I have a set of names (Python class constructors) "NLP", 
"LP", "QP" etc (that are well-known names of optimization problems 
classes), and using upper-case makes code more readable and 
understandable than "nlp", "lp", etc (and, of course, much better than 
_NLP_, NLP_ etc)

Regards, D.

Guy.Steele@... wrote:
> Background:
>
> (1) A basic principle of operator words in Fortress, as far as we are
> able to support it, has been that if you know the LaTeX name for
> an operator symbol, then if you leave off the backslash and write
> it using uppercase letters, then that is a name for that symbol in
> Fortress and "ASCII conversion" will replace that name with the
> character itself.
>

(Continue reading)

headers

Victor Luchangco | 3 Jun 13:03

Re: Proposal to expand set of operator words

On May 30, 2008, at 2:41 AM, dmitrey wrote:

> I would propose you another modification - to omit the rule "all  
> that is uppercase w/o digits is operator"
> this brings problems with manual & automatic code translation to  
> fortress (because these names should be changed).
>
> for example I have a set of names (Python class constructors)  
> "NLP", "LP", "QP" etc (that are well-known names of optimization  
> problems classes), and using upper-case makes code more readable  
> and understandable than "nlp", "lp", etc (and, of course, much  
> better than _NLP_, NLP_ etc)

Yeah, that all-caps names with two or more distinct letters cannot be  
identifiers has always bothered me a bit.  Here's an idea that isn't  
fully worked out yet that I'd like to hear what people think about:

Suppose we eliminate the syntactic distinction between identifiers  
and operator words, so that, for example, nlp, NLP, NLP_, N, ZZ, and  
ZZ32 could each be either an identifier or an operator word.   
Instead, we distinguish which are operators and which are identifiers  
based on their declarations.  We can do this because operator  
declarations are already distinguished by the opr modifier.  Thus, in  
the scope of the declarations

   opr MAX(x,y) = ...
   opr max(x,y) = ...

MAX and max would be operators, whereas in the scope of

(Continue reading)

headers

Sorin Miklós Zsejki | 3 Jun 13:38

Re: Proposal to expand set of operator words

Sounds good. I found it very odd when I first tried to write    trait
XML end    and got a strange error.

On Tue, Jun 3, 2008 at 2:03 PM, Victor Luchangco
<Victor.Luchangco@...> wrote:
> On May 30, 2008, at 2:41 AM, dmitrey wrote:
>
>> I would propose you another modification - to omit the rule "all that is
>> uppercase w/o digits is operator"
>> this brings problems with manual & automatic code translation to fortress
>> (because these names should be changed).
>>
>> for example I have a set of names (Python class constructors) "NLP", "LP",
>> "QP" etc (that are well-known names of optimization problems classes), and
>> using upper-case makes code more readable and understandable than "nlp",
>> "lp", etc (and, of course, much better than _NLP_, NLP_ etc)
>
> Yeah, that all-caps names with two or more distinct letters cannot be
> identifiers has always bothered me a bit.  Here's an idea that isn't fully
> worked out yet that I'd like to hear what people think about:
>
> Suppose we eliminate the syntactic distinction between identifiers and
> operator words, so that, for example, nlp, NLP, NLP_, N, ZZ, and ZZ32 could
> each be either an identifier or an operator word.  Instead, we distinguish
> which are operators and which are identifiers based on their declarations.
>  We can do this because operator declarations are already distinguished by
> the opr modifier.  Thus, in the scope of the declarations
>
>  opr MAX(x,y) = ...
>  opr max(x,y) = ...

(Continue reading)

headers

Sukyoung Ryu | 3 Jun 22:38

Improving syntax error messages

On Jun 3, 2008, at 7:38 AM, Sorin Miklós Zsejki wrote:

> Sounds good. I found it very odd when I first tried to write    trait
> XML end    and got a strange error.

Orthogonal to the original post, I agree with you about the strange  
syntax error message.

Revisions 1782 ~ 1784 improved some syntax error messages when an  
operator name is used as an identifier such as a trait or an object  
name.  If you try the following component:

====================
component XXXWrongTraitName
export Executable

trait XML end

run(args:String...) = ()

end
====================

the parser will give you the following error message:

====================
tests/XXXWrongTraitName.fss:21:0~11: XML is not a valid trait name.
A non-reserved word that is made up of a mixture of uppercase letters  
and underscores (but no digits), does not begin or end with an  
underscore, and contains at least two distinct letters is an operator

(Continue reading)

headers

Sorin Miklós Zsejki | 4 Jun 21:00

Re: Improving syntax error messages

Indeed, I've seen a big improvement in error messages since I've first
tried out Fortress. My point with that post was not to criticize the
error message, but that I was surprised that I couldn't change the
name of a trait, let's say, from Xml to XML.

By the way, what do you think of my suggestion to relax the check on
the name of components/APIs relative to the name of the file, so files
can be organized hierarchically in folders?

On Tue, Jun 3, 2008 at 11:38 PM, Sukyoung Ryu <Sukyoung.Ryu@...> wrote:
> On Jun 3, 2008, at 7:38 AM, Sorin Miklós Zsejki wrote:
>
>> Sounds good. I found it very odd when I first tried to write    trait
>> XML end    and got a strange error.
>
> Orthogonal to the original post, I agree with you about the strange syntax
> error message.
>
> Revisions 1782 ~ 1784 improved some syntax error messages when an operator
> name is used as an identifier such as a trait or an object name.  If you try
> the following component:
>
> ====================
> component XXXWrongTraitName
> export Executable
>
> trait XML end
>
> run(args:String...) = ()
>

(Continue reading)

headers

Guy Steele | 4 Jun 21:49

Using all-uppercase names for types and variables

On Jun 4, 2008, at 3:00 PM, Sorin Miklós Zsejki wrote:

> Indeed, I've seen a big improvement in error messages since I've first
> tried out Fortress. My point with that post was not to criticize the
> error message, but that I was surprised that I couldn't change the
> name of a trait, let's say, from Xml to XML.

Yep.  Would you consider using the ASCII name  XML_ ?
When rendered it will look like "XML" in roman type,
without the underscore.

On May 30, 2008, at 2:41 AM, dmitrey wrote:
>
>
> for example I have a set of names (Python class constructors) "NLP",  
> "LP", "QP" etc (that are well-known names of optimization problems  
> classes), and using upper-case makes code more readable and  
> understandable than "nlp", "lp", etc (and, of course, much better  
> than _NLP_, NLP_ etc)

If you are wanting to use "NLP", etc., as trait or object names,
would you consider using  NLP_  ?  This will set "NLP" in roman type,
according to the usual Fortress convention for type names.
I agree, not quite as nice as plain "NLP" in ASCII code, but only one
extra character, and a visually unobtrusive one.

If you want to use it as an ordinary variable name *and* want
it to be set in italic type rather than roman type when rendered,
then right now there is no good solution in Fortress as it

(Continue reading)

headers

Sorin Miklós Zsejki | 4 Jun 22:44

Re: Using all-uppercase names for types and variables

That would be reasonable. (I don't in fact intend, nor intended to
write an XML trait myself. I just tried out how it would look like in
Fortress).

On Wed, Jun 4, 2008 at 10:49 PM, Guy Steele <Guy.Steele@...> wrote:
>
> [...]
> Yep.  Would you consider using the ASCII name  XML_ ?
> When rendered it will look like "XML" in roman type,
> without the underscore.
> [...]
>
> --Guy
>

headers

Michael Alexander | 4 Jun 23:06

Re: Using all-uppercase names for types and variables

some form of coding of locality would be nice, e.g. rendering to subscript in LaTeX for local scopes, on the same token e.g. color-coding(!) regions might be good

On Wed, Jun 4, 2008 at 9:49 PM, Guy Steele <Guy.Steele <at> sun.com> wrote:

On Jun 4, 2008, at 3:00 PM, Sorin Miklós Zsejki wrote:

Indeed, I've seen a big improvement in error messages since I've first
tried out Fortress. My point with that post was not to criticize the
error message, but that I was surprised that I couldn't change the
name of a trait, let's say, from Xml to XML.

Yep. Would you consider using the ASCII name XML_ ?
When rendered it will look like "XML" in roman type,
without the underscore.

On May 30, 2008, at 2:41 AM, dmitrey wrote:

for example I have a set of names (Python class constructors) "NLP", "LP", "QP" etc (that are well-known names of optimization problems classes), and using upper-case makes code more readable and understandable than "nlp", "lp", etc (and, of course, much better than _NLP_, NLP_ etc)

If you are wanting to use "NLP", etc., as trait or object names,
would you consider using NLP_ ? This will set "NLP" in roman type,
according to the usual Fortress convention for type names.
I agree, not quite as nice as plain "NLP" in ASCII code, but only one
extra character, and a visually unobtrusive one.

If you want to use it as an ordinary variable name *and* want
it to be set in italic type rather than roman type when rendered,
then right now there is no good solution in Fortress as it
stands. But in the next generation of the rendering tool,
I am considering allowing one to write italic_NLP as a way
to force the use of italic type.

The general principle is that we are trying to make a lot of
common cases very easy to type, some of the less common
cases fairly easy to type, and then an all-purpose mechanism
that nearly always succeeds in letting you do what you want
but may be more verbose.

--Guy

--

Best Regards,

Dr. Michael Alexander
WU Wien Dept. of Information Systems
malexand <at> wu-wien.ac.at / +43.1.31336.4467

headers

Eric Allen | 4 Jun 21:57

Re: Improving syntax error messages

On Jun 4, 2008, at 2:00 PM, Sorin Miklós Zsejki wrote:

> Indeed, I've seen a big improvement in error messages since I've first
> tried out Fortress. My point with that post was not to criticize the
> error message, but that I was surprised that I couldn't change the
> name of a trait, let's say, from Xml to XML.
>
> By the way, what do you think of my suggestion to relax the check on
> the name of components/APIs relative to the name of the file, so files
> can be organized hierarchically in folders?

I support some such relaxation. Suppose we require only that the  
concatenation of the sequence of directory names (relative to the  
present working directory) together with the file name  (minus the  
suffix) matches the name of the component or API? For example, a  
component named Foo.Bar.Goo.Blah.fss could be put along any of the  
following paths (in Unix notation):

Foo/Bar/Goo/Blah.fss
Foo/Bar/Goo.Blah.fss
Foo/Bar.Goo/Blah.fss
Foo/Bar.Goo.Blah.fss
Foo.Bar/Goo/Blah.fss
Foo.Bar/Goo.Blah.fss
Foo.Bar.Goo/Blah.fss
Foo.Bar.Goo.Blah.fss

This is more restrictive than the approach taken in your diff but it  
should still allow you to organize code into directories. Also, it  
should make it easy to find source files, but it avoids long strings  
of nearly empty directories in the source path. Comments?

-- Eric

headers

Sorin Miklós Zsejki | 4 Jun 22:24

Re: Improving syntax error messages

I like that. I made that modification quickly and, additionally, I
don't know how to make the difference at that place in the code
between a base path that ends in Foo or a path within the project that
begins with Foo.

On Wed, Jun 4, 2008 at 10:57 PM, Eric Allen <Eric.Allen@...> wrote:
> On Jun 4, 2008, at 2:00 PM, Sorin Miklós Zsejki wrote:
>
>> Indeed, I've seen a big improvement in error messages since I've first
>> tried out Fortress. My point with that post was not to criticize the
>> error message, but that I was surprised that I couldn't change the
>> name of a trait, let's say, from Xml to XML.
>>
>> By the way, what do you think of my suggestion to relax the check on
>> the name of components/APIs relative to the name of the file, so files
>> can be organized hierarchically in folders?
>
> I support some such relaxation. Suppose we require only that the
> concatenation of the sequence of directory names (relative to the present
> working directory) together with the file name  (minus the suffix) matches
> the name of the component or API? For example, a component named
> Foo.Bar.Goo.Blah.fss could be put along any of the following paths (in Unix
> notation):
>
> Foo/Bar/Goo/Blah.fss
> Foo/Bar/Goo.Blah.fss
> Foo/Bar.Goo/Blah.fss
> Foo/Bar.Goo.Blah.fss
> Foo.Bar/Goo/Blah.fss
> Foo.Bar/Goo.Blah.fss
> Foo.Bar.Goo/Blah.fss
> Foo.Bar.Goo.Blah.fss
>
> This is more restrictive than the approach taken in your diff but it should
> still allow you to organize code into directories. Also, it should make it
> easy to find source files, but it avoids long strings of nearly empty
> directories in the source path. Comments?
>
> -- Eric
>
>
>

headers

Jon Rafkind | 4 Jun 23:15

Re: Improving syntax error messages

Eric Allen wrote:
> On Jun 4, 2008, at 2:00 PM, Sorin Miklós Zsejki wrote:
>
>> Indeed, I've seen a big improvement in error messages since I've first
>> tried out Fortress. My point with that post was not to criticize the
>> error message, but that I was surprised that I couldn't change the
>> name of a trait, let's say, from Xml to XML.
>>
>> By the way, what do you think of my suggestion to relax the check on
>> the name of components/APIs relative to the name of the file, so files
>> can be organized hierarchically in folders?
>
> I support some such relaxation. Suppose we require only that the 
> concatenation of the sequence of directory names (relative to the 
> present working directory) together with the file name  (minus the 
> suffix) matches the name of the component or API? For example, a 
> component named Foo.Bar.Goo.Blah.fss could be put along any of the 
> following paths (in Unix notation):
>
> Foo/Bar/Goo/Blah.fss
> Foo/Bar/Goo.Blah.fss
> Foo/Bar.Goo/Blah.fss
> Foo/Bar.Goo.Blah.fss
> Foo.Bar/Goo/Blah.fss
> Foo.Bar/Goo.Blah.fss
> Foo.Bar.Goo/Blah.fss
> Foo.Bar.Goo.Blah.fss
>
> This is more restrictive than the approach taken in your diff but it 
> should still allow you to organize code into directories. Also, it 
> should make it easy to find source files, but it avoids long strings 
> of nearly empty directories in the source path. Comments?
If I had all those files listed above, which one would be loaded first? 
Or would it just be a static error to have the same component found 
multiple times.

headers

David Chase | 5 Jun 00:45

Re: Improving syntax error messages


On 2008-06-04, at 5:15 PM, Jon Rafkind wrote:
>>
>> Foo/Bar/Goo/Blah.fss
>> Foo/Bar/Goo.Blah.fss
>> Foo/Bar.Goo/Blah.fss
>> Foo/Bar.Goo.Blah.fss
>> Foo.Bar/Goo/Blah.fss
>> Foo.Bar/Goo.Blah.fss
>> Foo.Bar.Goo/Blah.fss
>> Foo.Bar.Goo.Blah.fss
>>
>> This is more restrictive than the approach taken in your diff but  
>> it should still allow you to organize code into directories. Also,  
>> it should make it easy to find source files, but it avoids long  
>> strings of nearly empty directories in the source path. Comments?
> If I had all those files listed above, which one would be loaded  
> first? Or would it just be a static error to have the same component  
> found multiple times.

It cannot be an error, else consider what happens if you try to check  
for multiple copies of

a.b.c.d.e.f.g.h.i.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z

That requires that you attempt up to 32 million file opens to check  
for multiple naming (though you could prune prefixes carefully and  
probably avoiding that many opens).

David

headers

Jon Rafkind | 5 Jun 15:51

Re: Improving syntax error messages

David Chase wrote:
>
> On 2008-06-04, at 5:15 PM, Jon Rafkind wrote:
>>>
>>> Foo/Bar/Goo/Blah.fss
>>> Foo/Bar/Goo.Blah.fss
>>> Foo/Bar.Goo/Blah.fss
>>> Foo/Bar.Goo.Blah.fss
>>> Foo.Bar/Goo/Blah.fss
>>> Foo.Bar/Goo.Blah.fss
>>> Foo.Bar.Goo/Blah.fss
>>> Foo.Bar.Goo.Blah.fss
>>>
>>> This is more restrictive than the approach taken in your diff but it 
>>> should still allow you to organize code into directories. Also, it 
>>> should make it easy to find source files, but it avoids long strings 
>>> of nearly empty directories in the source path. Comments?
>> If I had all those files listed above, which one would be loaded 
>> first? Or would it just be a static error to have the same component 
>> found multiple times.
>
> It cannot be an error, else consider what happens if you try to check 
> for multiple copies of
>
> a.b.c.d.e.f.g.h.i.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z
>
> That requires that you attempt up to 32 million file opens to check 
> for multiple naming (though you could prune prefixes carefully and 
> probably avoiding that many opens).
>
> David
>
>
You are still required to look at that number of paths given such a 
filename in the worst case, although the same tricks can be played to 
lessen the number of file opens( I assume you mean read directories and 
filter filenames ). If fortress prefers / over . then someone who uses . 
will always pay a high price. How about instead of allowing / after a ., 
only allow / before .

a/b/c.fss - ok
a/b/c.d.fss - ok
a.b/c.fss - not ok

then the number of checks is linear in the number of elements seperated 
by . and /

headers

David Chase | 5 Jun 17:39

Re: Improving syntax error messages

My temptation is to say that you get three choices:

Foo/Bar/Goo/Blah.fss
Foo.Bar.Goo/Blah.fss
Foo.Bar.Goo.Blah.fss

This would give you something like what Eclipse (and Netbeans, I  
think) provide for views of Java projects.

David

headers

Jan-Willem Maessen | 3 Jun 15:09

Re: Proposal to expand set of operator words

On Jun 3, 2008, at 7:03 AM, Victor Luchangco wrote:

> On May 30, 2008, at 2:41 AM, dmitrey wrote:
>
>> I would propose you another modification - to omit the rule "all  
>> that is uppercase w/o digits is operator"
>> this brings problems with manual & automatic code translation to  
>> fortress (because these names should be changed).
>>
>> for example I have a set of names (Python class constructors)  
>> "NLP", "LP", "QP" etc (that are well-known names of optimization  
>> problems classes), and using upper-case makes code more readable  
>> and understandable than "nlp", "lp", etc (and, of course, much  
>> better than _NLP_, NLP_ etc)
>
> Yeah, that all-caps names with two or more distinct letters cannot  
> be identifiers has always bothered me a bit.  Here's an idea that  
> isn't fully worked out yet that I'd like to hear what people think  
> about:

Oddly, I've only had this problem with type names.

There's one very real downside: I can't parse code visually.  That is,  
I can't quickly tell the operator names from the variable names.  I  
expect most of my operators to be living somewhere else (in a library  
or an imported component) so this may be an important consideration.

-Jan-Willem Maessen

headers

dmitrey | 3 Jun 16:22

Re: Proposal to expand set of operator words

Jan-Willem Maessen wrote:
>
> On Jun 3, 2008, at 7:03 AM, Victor Luchangco wrote:
>
>> On May 30, 2008, at 2:41 AM, dmitrey wrote:
>>
>>> I would propose you another modification - to omit the rule "all 
>>> that is uppercase w/o digits is operator"
>>> this brings problems with manual & automatic code translation to 
>>> fortress (because these names should be changed).
>>>
>>> for example I have a set of names (Python class constructors) "NLP", 
>>> "LP", "QP" etc (that are well-known names of optimization problems 
>>> classes), and using upper-case makes code more readable and 
>>> understandable than "nlp", "lp", etc (and, of course, much better 
>>> than _NLP_, NLP_ etc)
>>
>> Yeah, that all-caps names with two or more distinct letters cannot be 
>> identifiers has always bothered me a bit.  Here's an idea that isn't 
>> fully worked out yet that I'd like to hear what people think about:
>
> Oddly, I've only had this problem with type names.
>
> There's one very real downside: I can't parse code visually.  That is, 
> I can't quickly tell the operator names from the variable names.
In essential fortress IDE it could be easily solved via different colors 
for variables and/or functions and/or operators.
Regards, D.

headers

Jan-Willem Maessen | 3 Jun 17:22

Re: Proposal to expand set of operator words

On Jun 3, 2008, at 10:22 AM, dmitrey wrote:

>> Oddly, I've only had this problem with type names.
>>
>> There's one very real downside: I can't parse code visually.  That  
>> is, I can't quickly tell the operator names from the variable names.
> In essential fortress IDE it could be easily solved via different  
> colors for variables and/or functions and/or operators.

Note that this means that all the imports must be correctly found and  
parsed by the IDE, or the highlighting will be wrong.  Usually IDE  
syntax highlighting is a local operation, and doesn't require us to  
set search paths for our library files within the IDE itself just to  
read code.

-Jan

>
> Regards, D.
>
>

headers

Dmitrey Kroshko | 6 Jun 12:48

Re: Proposal to expand set of operator words

Guy Steele wrote:

On May 30, 2008, at 2:41 AM, dmitrey wrote:

for example I have a set of names (Python class constructors) "NLP", "LP", "QP" etc (that are well-known names of optimization problems classes), and using upper-case makes code more readable and understandable than "nlp", "lp", etc (and, of course, much better than _NLP_, NLP_ etc)

If you are wanting to use "NLP", etc., as trait or object names,
would you consider using NLP_ ?

I'm not fond of the solution, because it's non-symmetric and requires typing _ ech time (that I do dozens times daily).
I would better implement a special symbol for operators, for example
<at> SUM
and
<at> Sum
being (different) operators (and omit symbol <at> during rendering, yielding another color for the word "sum" instead).

Jan-Willem Maessen wrote:

In essential fortress IDE it could be easily solved via different colors for variables and/or functions and/or operators.

Note that this means that all the imports must be correctly found and parsed by the IDE, or the highlighting will be wrong. Usually IDE syntax highlighting is a local operation, and doesn't require us to set search paths for our library files within the IDE itself just to read code.

-Jan

Yes, I had the issue in mind when I write the proposition, but AFAIK modern IDEs can handle it easily.

Regards, D