future of annotations in Lua?

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Coda Highland


On Mon, Jun 10, 2019 at 10:19 AM [hidden email] <[hidden email]> wrote:
Roberto:
> Maybe I missed the answer, but repeating Dibyendu's question: How
to reconcile a syntax that prefixes an entire local statement with
per-variable annotations?

whats wrong with `local <const> a, b, <const> c, d`? do u mean that
`local <const> a, b, c, d` means by default that a-d are all
constants, so actually an opt-out would be needed for those that
shouldnt be constants?

if i understood u correctly, then i think the interpretation of my 2nd
expression above just shouldnt make b-d constants; or i could think
about (with the `@` notation) this for making all vars constants:
`local @@const a, b, c, d` - so doubling the at symbol would extend
the range of the const from the 1st variable to all of them. this way
both needs are covered, and its really a visible thing to prevent
messing around stuffs like `a.b()` vs `a:b()` that took away some
happy time from all of us here not even once. :D (no offense for `:`,
basically im fine with it. :) )


Your thought there is fine. The question was about the suggestion to put the annotation BEFORE the "local" keyword. That syntax would essentially make it impossible to put both annotated and not-annotated variable declarations in the same statement; it would be all or nothing.

I think this particular issue is a good reason why the annotation should prefix the specific declaration being annotated instead of having it prefix the statement. Other languages just don't allow you to mix them in a single statement, but if that's a desirable feature in Lua then I don't think it's worth bikeshedding over the positioning.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Philippe Verdy
+1
This will also avoid further ambiguitiess with other (non-"local") statements that may come before.

Per variable annotation, prefixing each declared name is far preferable (also allows easier refactoring of existing source code, when modifiying existing declarations, especially when there are initializers at end of the variable list and an "=" sign, given that these initializers may also have their own annotations inside their expression).


Le lun. 10 juin 2019 à 18:31, Coda Highland <[hidden email]> a écrit :


On Mon, Jun 10, 2019 at 10:19 AM [hidden email] <[hidden email]> wrote:
Roberto:
> Maybe I missed the answer, but repeating Dibyendu's question: How
to reconcile a syntax that prefixes an entire local statement with
per-variable annotations?

whats wrong with `local <const> a, b, <const> c, d`? do u mean that
`local <const> a, b, c, d` means by default that a-d are all
constants, so actually an opt-out would be needed for those that
shouldnt be constants?

if i understood u correctly, then i think the interpretation of my 2nd
expression above just shouldnt make b-d constants; or i could think
about (with the `@` notation) this for making all vars constants:
`local @@const a, b, c, d` - so doubling the at symbol would extend
the range of the const from the 1st variable to all of them. this way
both needs are covered, and its really a visible thing to prevent
messing around stuffs like `a.b()` vs `a:b()` that took away some
happy time from all of us here not even once. :D (no offense for `:`,
basically im fine with it. :) )


Your thought there is fine. The question was about the suggestion to put the annotation BEFORE the "local" keyword. That syntax would essentially make it impossible to put both annotated and not-annotated variable declarations in the same statement; it would be all or nothing.

I think this particular issue is a good reason why the annotation should prefix the specific declaration being annotated instead of having it prefix the statement. Other languages just don't allow you to mix them in a single statement, but if that's a desirable feature in Lua then I don't think it's worth bikeshedding over the positioning.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

szbnwer@gmail.com
what about `<const> local a, b, c, d` and `local <const> a, b, <const>
c, d` for the 2 variations?

Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Jim-2
In reply to this post by Philippe Verdy
08.06.2019, 12:23, "Philippe Verdy" <[hidden email]>:
> For now, only "@" does not have any one of these problems
> (when used as a prefixed annotation) simply because it cannot
> be used also as a binary operator (for now, but most probably never...).

doesn't this hold for "$" aswell ?


Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Jim-2
In reply to this post by szbnwer@gmail.com
08.06.2019, 23:29, "[hidden email]" <[hidden email]>:
>> @attributename -- for attributes without arguments
>> @(attributename arguments) -- for attributes with arguments
>
> +1, but a big ONE!
> currently this is the most friendly for my eyes

indeed, this syntax looks better.
but what about - say -
@@attributename arg1 arg2 ...@
(assuming the arguments do not contain "@" themselves),
i. e. an "@" immediately following the preceding "@" indicates
an attribute with arguments ?

or even
@$attributename arg1 arg2 ...$
?



Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Jim-2
In reply to this post by Lorenzo Donati-3
08.06.2019, 10:25, "Lorenzo Donati" <[hidden email]>:
> Moreover, it is very bad netiquette

another point would be abstaining from posting html formated
messages. email is a textual protocol that does not need any
fancy html formating. especially not when sending 2 copies of
the same message: one in pure textual form and another one
attached as html formated version. apart from being quite
annoying it is also superfluous and not worth the space
it wastes in list archives and subscriber mailboxes.


Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Lorenzo Donati-3
In reply to this post by Coda Highland
On 10/06/2019 18:31, Coda Highland wrote:

> On Mon, Jun 10, 2019 at 10:19 AM [hidden email] <[hidden email]>
> wrote:
>
>> Roberto:
>>> Maybe I missed the answer, but repeating Dibyendu's question: How
>> to reconcile a syntax that prefixes an entire local statement with
>> per-variable annotations?
>>
>> whats wrong with `local <const> a, b, <const> c, d`? do u mean that
>> `local <const> a, b, c, d` means by default that a-d are all
>> constants, so actually an opt-out would be needed for those that
>> shouldnt be constants?
>>
>> if i understood u correctly, then i think the interpretation of my 2nd
>> expression above just shouldnt make b-d constants; or i could think
>> about (with the `@` notation) this for making all vars constants:
>> `local @@const a, b, c, d` - so doubling the at symbol would extend
>> the range of the const from the 1st variable to all of them. this way
>> both needs are covered, and its really a visible thing to prevent
>> messing around stuffs like `a.b()` vs `a:b()` that took away some
>> happy time from all of us here not even once. :D (no offense for `:`,
>> basically im fine with it. :) )
>>
>>
> Your thought there is fine. The question was about the suggestion to put
> the annotation BEFORE the "local" keyword. That syntax would essentially
> make it impossible to put both annotated and not-annotated variable
> declarations in the same statement; it would be all or nothing.
>

Mmmh, /IF/ annotations are not meant (even in the future) to annotate
objects, but just variable declarations, I'm not sure it is a good idea
to allow mixing annotations in the same statement.

I fear that it could be source of errors like in C with pointer
declarations:

int *a, b, c; // b and c are NOT pointers, but inexpert people read:

int* a, b, c; // where int* is interpreted as the type for a, b and c

BTW, writing `int* a` instad of `int *a` seems to be adviced in "modern
C", together with avoiding multiple declarations per statement.

In Lua there is a catch, however: multiple assignment. So if I want to
store just one result from a call in a const variable I must have the
ability to

local a, <const> b , c = f(...)

So, meh, I assume you have to live with the risk.

That's another reason I don't like that syntax (and I'd prefer @const,
with @ not separable from `const`). In fact this would be a mess to /read/:

local a, < const > b, c, < const, helpful > h, < toclose > z = f(...)

(imagine longer names for realistically complex statement where such
syntax would be applied)

Spaces together with <> "operators", especially when multiple attributes
will be supported will be extremely confusing when reading/debugging code.

Compare:


local a, @const b, c, @const @toclose h, @toclose z = f(...)


So the "sigil" @ would also replace the need for commas between multiple
annotations. So an annotation list would be a space-separated sequence
of identifiers beginning with @, with no intervening token inbetween.

Neither syntax is beautiful, IMO, but this latter is the least of the
two evil, IMHO. A nicer syntax would be to introduce new keywords (At
least for "const"), but this has other drawbacks and still doesn't
provide a general syntax for the future "annotation list" thing.

BTW, I also agree with someone else in this discussion about "scoped"
being a better substitute for "toclose". The problem is the __close
metametod, which will not match the attribute (rename it to __scope is
misleading, maybe __scope_handler, longer, but MUCH more readable).

> I think this particular issue is a good reason why the annotation should
> prefix the specific declaration being annotated instead of having it prefix
> the statement. Other languages just don't allow you to mix them in a single
> statement, but if that's a desirable feature in Lua then I don't think it's
> worth bikeshedding over the positioning.
>
> /s/ Adam
>


Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Sean Conner
In reply to this post by Jim-2
It was thus said that the Great Jim once stated:
> 08.06.2019, 10:25, "Lorenzo Donati" <[hidden email]>:
> > Moreover, it is very bad netiquette
>
> another point would be abstaining from posting html formated
> messages.

  I'm subscribed to a mailing list devoted to classic computers [1], and
*they* gave up on trying to enforce non-HTML emails (and top posting, and
... ).  Sadly, it's a lost cause.

> email is a textual protocol that does not need any
> fancy html formating. especially not when sending 2 copies of
> the same message: one in pure textual form and another one
> attached as html formated version.

  At least that shows the sender cares (or at least, the client they are
using cares) enough to send a plain text version of the email.  Nothing
worse than to receive an email with ONLY HTML, which in my case, means I
shell out to Lynx to read the email.

> apart from being quite
> annoying it is also superfluous and not worth the space
> it wastes in list archives and subscriber mailboxes.

  Good luck on your crusade.

  -spc (You might get better luck in saying it lowers potential spam scores
        when one DOES NOT use HTML in email---check the headers of this
        email)

[1] Officially, any computer at least 10 years old or older.
        Unofficially, anthing that can run Microsoft Windows is NOT
        a classic computer.

Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Philippe Verdy

Le jeu. 13 juin 2019 à 07:38, Sean Conner <[hidden email]> a écrit :
It was thus said that the Great Jim once stated:
> 08.06.2019, 10:25, "Lorenzo Donati" <[hidden email]>:
> > Moreover, it is very bad netiquette
>
> another point would be abstaining from posting html formated
> messages.

  I'm subscribed to a mailing list devoted to classic computers [1], and
*they* gave up on trying to enforce non-HTML emails (and top posting, and
... ).  Sadly, it's a lost cause.

And for my case, you're wrong, the mails were sent from some machine running some Linux or BSD system (anything that Google wanted for its Gmail service). And they're definitely NOT old computers, but very modern ones, highly optimized for efficiency and security.

I've abandonned since long any use of local mail clients (because they were very unpractical and storage was at much more risk. Security was not even better locally than what Google can do itself on its servers, and with much better handling and detection of spams. You may argue that privacy is an issue, but privacy is definitely not one for public mailing lists like this one.

So yes this is a lost cause (otherwise Gmail would have enforced it since long, but it NEVER made that even the default). So any claim of "netiquette" about this placement is simply fake, it may have been proposed by a few but never accepted and supported by a large majority. The same is true about HTML posting (that still works much better than plain-text only messages) and must ALWAYS used with the dual encoding (HTML original + altered plain-text only for those that use very antique softwares that can't even parse a safe basic HTML syntax that shows at last the content but can still disable any form of active scripting, including links to external images not part of the mail as an attachment, or tracking pixels).

In fact emails should use HTML-only by default now. Plain-text-only is outdated and not reliable (it breaks legitimate contents to give non-sense), and the current HTML+plain-text format shouls now no longer be necessary (if you use Lynx, Lynx can still perfectly parse HTML and render its text; otherwise if your agent can only process plain-text, it is definitely antique, and most probably dangerous for you to use, or at least very unreliable, given the many inconsistencies left in the old RFCs supporting it but that were never solved correctly... before the arrival of MIME and the shared development with HTTP that allowed full interoperability and HTML then made the default (and now efficient, consistant and secure since the huge HTML5 efforts) !)


Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Jim-2
14.06.2019, 19:40, "Philippe Verdy" <[hidden email]>:
>>   I'm subscribed to a mailing list devoted to classic computers [1], and
>> *they* gave up on trying to enforce non-HTML emails (and top posting, and
>> ... ).  Sadly, it's a lost cause.
>
> And for my case, you're wrong, the mails were sent from some machine running
> some Linux or BSD system (anything that Google wanted for its Gmail service).
> And they're definitely NOT old computers, but very modern ones, highly
> optimized for efficiency and security.

that was just a general EXAMPLE he gave to make his point clear.
he wanted to emphasize how bad the situation has become and
used the example of a mailing list "devoted to classic computers"
which one instantly assumes to be only subscribed by old pre facebook
luddites that do not even know html formating of message texts
is possible. :D

it was more meant as a reply to my posting and not directly connected to
you or the OS/mailer you use.

> I've abandonned since long any use of local mail clients
> (because they were very unpractical and storage was at much more risk.

but storing mails on NSA disks is not risk at all, i see.

> Security was not even better locally than what Google can do itself on its
> servers, and with much better handling and detection of spams.

?
there exist endless spam detection toolsets that can be used at your site,
server or client side.

i personally use a webmailer only since i cannot run my own. :-(
it is no good thing at all, though.
but emails should not be used where privacy/security is a concern
anyway.

> You may argue that privacy is an issue, but privacy is definitely not one
> for public mailing lists like this one.

indeed. but many people will use the same account for private mails and
their mailing list subscriptions.

> So yes this is a lost cause (otherwise Gmail would have enforced it since long,
> but it NEVER made that even the default).

this is in fact not true. use the basic interface like i did when sending mails
with my google account to this list. even in gmails fancier looking default
interface it is possible to send plain text mails (click "without formating"
and voila, same here with the yandex webmailer).

> So any claim of "netiquette" about this placement is simply fake,
> it may have been proposed by a few but never accepted and
> supported by a large majority.

i doubt that most of the html-mail "fans" even know/bother they
are polluting the net and mail storage with html formated garbage.
when their mailtool sends plaintext-only mails they would not
notice either. it is not a choice they made wittingly somewhere.
it is the default policy of the mail user agent they use, that is all
there is to it.
 
> The same is true about HTML posting (that still works much
> better than plain-text only messages) and must ALWAYS used
> with the dual encoding

MUST ? ALWAYS ? since when and why is that ?
what SMTP RFC requires that ?
i totally missed that ...
 
> (HTML original + altered plain-text only for those that use very
> antique softwares

like a whole bunch of non-gui unix mailers ?

> that can't even parse a safe basic HTML syntax that shows at

mail is a TEXTUAL protocol, NO mail user agent is REQUIRED
by anything to "parse safe basic HTML syntax".
it is a MAIL USER AGENT, not a browser, please do not mix things.

> last the content but can still disable any form of active scripting,
> including links to external images not part of the mail as an
> attachment, or tracking pixels).

since when is a mail user agent required to handle "external images"
or "tracking pixels" ?? such questions do not even arise when just
sending PLAIN text messages.

> In fact emails should use HTML-only by default now.
> Plain-text-only is outdated and not reliable
> (it breaks legitimate contents to give non-sense),
> and the current HTML+plain-text format shouls now no longer
> be necessary

who decided this ? hot-/gmail by making it their default ? you ?
why not making pdf the default ? or even better: only allow
M$ word format. :D

BTW: i never understood why C, Lua and anybody else require
ASCII source code and do not require it to be formated in PDF,
doc and/or HTML. :DD

> if you use Lynx, Lynx can still perfectly parse HTML and render

why should one use Lynx for sending, receiving, reading emails ?
it is a web browser after all and no mail user agent.

> its text; otherwise if your agent can only process plain-text,
> it is definitely antique,

says ?

> and most probably dangerous for you to use, or at least very
> unreliable, given the many inconsistencies left in the old RFCs

i am sure you have read all the "old RFCs", right ? :DD

> supporting it but that were never solved correctly ...

i see. that old lamers (who exactly ? dunno ;-) dared to never
solve it "correctly", so we still have to send plain text mails instead
of sending HTML, PDF, PS, DOC or whatever.

these dinosaurs responsible for the mail standards and grumpy old
luddites implementing/maintaining (and still using ??) "antique"/outdated
mail user agents should be retired urgently.

> before the arrival of MIME and the shared development with HTTP
> that allowed full interoperability and HTML then made the default

now i understand. :D

> (and now efficient, consistant and secure since the huge HTML5
> efforts) !)

i agree that HTML4/XHTML is outdated and "antique" and hence
cannot be used to format mails, HTML5 HAS to be used for formating
mails, there is no other. :D

HINTS:

1) do not put the whole mail on one line, split it into several lines
    not longer than 80 chars instead, using paragraphs also
    improves readability (i. e. insert an empty line from time
    to time)

2) use the "basic" gmail webmail interface by default, even
    though it looks "antique", outdated or whatever, it also
    helps with letting lines grow not too long and only sends
    PLAIN text mails.

3) when using the default gmail webmail interface for posting
    messages to mailing lists make sure to click on "without
    formating" when starting to compose the message.
    (same holds for yandex and other webmailers)


Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Jim-2
In reply to this post by Sean Conner
13.06.2019, 07:38, "Sean Conner" <[hidden email]>:
>   I'm subscribed to a mailing list devoted to classic computers [1], and
> *they* gave up on trying to enforce non-HTML emails (and top posting, and
> ... ). Sadly, it's a lost cause.

not really.
in the case of top posting enlightening the author why to avoid that
can be helpful.

in the case of html formating there exist technical solutions aswell,
like rejecting such messages to forcibly educate such users a bit.
this can be achieved with the mailing list software, i found that
in "sympa" and/or at groups.io (don't remember exactly which one)
this is possible. i am sure this can be achieved with "mailman" too.

> Nothing worse than to receive an email with ONLY HTML,

indeed, totally agreed.
i forgot to mention that really ANNOYING case. :-(((

> which in my case, means I shell out to Lynx to read the email.

i still try to read such garbage with with the normal pager, since
luckily HTML is not a binary format and sometimes it is possible to
locate and follow the contained message, of course tons of CSS
(crazy!!! CSS in a message)
and similar garbage is not helpful when doing so ... :-/

when replying to such messages mutt retains the html garbage.
i intentionally do not remove that in the reply to give the recipients
the chance to reflect their message formating in further mails.
 
> Good luck on your crusade.

thanks. :-/


Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Jim-2
In reply to this post by Philippe Verdy
08.06.2019, 07:00, "Philippe Verdy" <[hidden email]>:
> Note also that Javascript has similar issues, but it does not require ";"
> only because it differenciates whitespaces
> (those that include a newline not part of a comment
> from other whitespaces); you cannot safely remove all newlines
> in Javascript and merge all whitespaces to a single space,
> without adding a few ";" where needed.
> So Javascript's parser defines the newline token!

i do not like giving syntactical meaning
(mostly statement termination) to newlines since i prefer free
form syntaxes where the programmer can use the source code
formating they prefer.


Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Jim-2
In reply to this post by Philippe Verdy
08.06.2019, 06:56, "Philippe Verdy" <[hidden email]>:
> If we add syntaxic features to Lua, we should keep this in mind
> and not transform Lua into a Fortran-like language
> (whose parsing is extremely complex because of its optional
> whitespaces between all keywords and identifiers, and very tricky
> to write and test with enough coverages) or
> in a C++-like language (also very tricky).

indeed, i totally agree.


Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Lorenzo Donati-3
In reply to this post by Jim-2
On 13/06/2019 07:06, Jim wrote:

> 08.06.2019, 10:25, "Lorenzo Donati" <[hidden email]>:
>> Moreover, it is very bad netiquette
>
> another point would be abstaining from posting html formated
> messages. email is a textual protocol that does not need any
> fancy html formating. especially not when sending 2 copies of
> the same message: one in pure textual form and another one
> attached as html formated version. apart from being quite
> annoying it is also superfluous and not worth the space
> it wastes in list archives and subscriber mailboxes.
>
>
>

Mmmh... what do you mean, exactly?

Is it just an addition to what I said or is it a complaint addressed at me?

I've configured my mail-client (Thunderbird) to send mail to Lua-l in
text format.





Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Sean Conner
In reply to this post by Jim-2
It was thus said that the Great Jim once stated:

> 14.06.2019, 19:40, "Philippe Verdy" <[hidden email]>:
> >>   I'm subscribed to a mailing list devoted to classic computers [1], and
> >> *they* gave up on trying to enforce non-HTML emails (and top posting, and
> >> ... ).  Sadly, it's a lost cause.
> >
> > And for my case, you're wrong, the mails were sent from some machine running
> > some Linux or BSD system (anything that Google wanted for its Gmail service).
> > And they're definitely NOT old computers, but very modern ones, highly
> > optimized for efficiency and security.
>
> that was just a general EXAMPLE he gave to make his point clear.
> he wanted to emphasize how bad the situation has become and
> used the example of a mailing list "devoted to classic computers"
> which one instantly assumes to be only subscribed by old pre facebook
> luddites that do not even know html formating of message texts
> is possible. :D

  Exactly!  Thank you for getting my point.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Philippe Verdy
In reply to this post by Jim-2


Le sam. 15 juin 2019 à 09:58, Jim <[hidden email]> a écrit :
14.06.2019, 19:40, "Philippe Verdy" <[hidden email]>:
> I've abandonned since long any use of local mail clients
> (because they were very unpractical and storage was at much more risk.

but storing mails on NSA disks is not risk at all, i see.
 
You forget my essential argument: "unpractical".

The main  point is the local storage and inacessibility from multiple devices or from remote sites. As well, large volumes of incoming spams is causing excessive network usage, and adds delays for the delivery. Managing the storage locally is also a problem (because I have archives of all my mails since several decennials). And the POP3 protocol has too many problems (even when it is secured) causing too frequent losses of emails during transfers (and impossibility to get them back again). Now with mobile devices, local stage is impossible. Of course I could have installed a remote hosting, but managing it (and paying a lot for it, or suffering bandwidth outages was not a good solution).

All that are reasons why I've stopped using local mail agents in favor of webmails (I'm not "devoted" to Gmail, it's just the most stable solution I found, it offers the least bugs and delivery of emails to it are very stable, and it offers a very decent filtering for spams and malicious contents, without excessive ads throughout, and I'm still not required to your their webmail site as it works seemlessly from all other devices using their own local interface, and a temporary local storage that remains accessible without network connectivity, allowing to compose mails that can be delivered later when I'm online again; and it is very secure even if Google may get some aggregated profiling info from my usage; for now it has never abused my privacy, unlike all other mail providers I tested, and I no longer trust any other ISP, not even my current one or any other in France, and can change my ISP at any time without having to reconfigure everything or loosing all the storage after the switch).

Reply | Threaded
Open this post in threaded view
|

Re: future of annotations in Lua?

Jim-2
In reply to this post by Lorenzo Donati-3
On Sat, Jun 15, 2019 at 04:48:34PM +0200, Lorenzo Donati wrote:
> Is it just an addition to what I said or is it a complaint addressed at me?

no, it is not.

it is addressed to all html mail friends in general and to Philippe
in particular. :D
(the latter was the recipient of your original complaint about his
weird posting preferences)

> I've configured my mail-client (Thunderbird) to send mail to Lua-l in text
> format.

comme il faut.
was not too difficult, right ? :D


123