[ANN] GSL Shell new beta release with anti-gran graphics module

classic Classic list List threaded Threaded
126 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Luiz Henrique de Figueiredo
> BTW, is there any position yet on token filtering being part of Lua 5.2?

I think it'll probably remain an external addon; it's just a one-line change
in llex.c.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

steve donovan
In reply to this post by David Kastrup
On Fri, Dec 4, 2009 at 12:49 PM, David Kastrup <[hidden email]> wrote:
> But wouldn't it feel inconsistent to have a shorthand for
> function(x) return x*x end
> but not for
> function(x) if x>0 then return 1 else return 0 end end

|x| x > 0 and 1 or 0 ?  (Granted, and/or does read a bit funny, but
it's an idiom we know and why I don't miss ?:)

> Wouldn't maintaining that elegance require that you get expression
> shorthands for most control structures in use for "short functions"?

Francesco's intention was to express simple one-liners, usually
one-to-one 'classical' mathematical functions. Where something more
complicated is happening, then the short form isn't a good idea.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Luiz Henrique de Figueiredo
In reply to this post by David Given
> I will say that I'd be very happy if they could consider adding #line support.

See http://lua-users.org/lists/lua-l/2005-06/msg00111.html

This code was written before token filters and can be easily converted in one.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Matthew Wild
In reply to this post by Luiz Henrique de Figueiredo
2009/12/4 Luiz Henrique de Figueiredo <[hidden email]>:
>> BTW, is there any position yet on token filtering being part of Lua 5.2?
>
> I think it'll probably remain an external addon; it's just a one-line change
> in llex.c.
>

Exactly! :)

Unfortunately I think this means I won't really be able to use it, as
Lua is already packaged for all major platforms, and I don't want to
have users install or build a custom version of Lua just for my
application (for a one-line change above all things).

Matthew
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

steve donovan
In reply to this post by Luiz Henrique de Figueiredo
On Fri, Dec 4, 2009 at 2:15 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> I think it'll probably remain an external addon; it's just a one-line change
> in llex.c.

Fair enough, it isn't really a mainstream feature. What _would_ be
interesting is if token filtering could be done by a _dynamically
loadable_ module, so that vaniilla Lua would just have to provide the
hook.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Luiz Henrique de Figueiredo
In reply to this post by Matthew Wild
> I think it'll probably remain an external addon; it's just a one-line change
> in llex.c.

I meant, it's a one line-change to include a .c file that does whatever
filtering you need. The point being that you can maintain your variants
without messing with the Lua sources. Also, one simple way to use token filters
without rebuilding Lua is to rebuild luac to use them but leave the rest of
Lua untouched. Then precompile your Lua+ scripts with luac and they can be
run on the installe Lua VM.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Tomás Guisasola-2
In reply to this post by Luiz Henrique de Figueiredo
> We might as well go for the traditional lambda notation :-)
> \x,y,z.x+y*z
>
> With mandatory parentheses, this is amenable to token filtering...
> \x,y,z.(x+y*z)

  I don't think these forms are easier to read than the current:

function (x, y, z) return x + y * z end

  Although shorter, I don't think it is worth adding this notation.
  Tomás
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Enrico Tassi-3
In reply to this post by Luiz Henrique de Figueiredo
On Fri, Dec 04, 2009 at 10:27:29AM -0200, Luiz Henrique de Figueiredo wrote:
> > I think it'll probably remain an external addon; it's just a one-line change
> > in llex.c.
>
> I meant, it's a one line-change to include a .c file that does whatever
> filtering you need. The point being that you can maintain your variants
> without messing with the Lua sources.

Please, reconsider this approach. Matthew is right in highlighting the
fact that having to modify the source of a software to activate a
feature is not an option for software distributions.

Luckily out there there are not trivial projects based on Lua that would
benefit from token filters, but the fact that it is not a "standard"
feature refrains them for using it, since the would not run on a vanilla
Lua interpreter nor on a vanilla jitter. This is really a portability
issue.

Moreover, even if you really embed Lua is a software that is part of a
software distribution, you really want to use the system wide installed
shared object. You will get the minor versions updates for free (OK,
historically Lua has few bugs... but I cannot predict the future ;-)
and you may also discover that your users have an easy option to use
Luajit without recompiling you software (if they are on a platform
supported by the jitter).  

Actually, my reasoning applies to all luaconf.h, but luckily here there
is a default; I hope all Linux distributions leave the file untouched.

Just my 2 cents wearing the Debian hat and hoping Lua steps out of the
"it's just for embedding" world. Cheers
--
Enrico Tassi
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

David Kastrup
In reply to this post by David Given
David Given <[hidden email]> writes:

> Paul Hudson wrote:
> [...]
>> Because, for Lua in particular, there is a resistance to convenience and
>> sugar. Not a refusal to ever consider it, but Lua is remarkably free of
>> cruft and I for one would prefer it stayed that way.
>
> Yup. There are, AFAIK, precisely two bits of syntactic sugar in Lua
> --- : notation for calling functions, and 'local function' for
> defining them. And even the first isn't really sugar, as it generates
> specific bytecode that you can't generate elsewhere.

There is more. function id is equivalent to id = function, and most
prominently a.b is equivalent to a["b"].

It is important to realize that all of this "syntactical sugar"
diversity is for cases where commonly and conceptually things are
implemented wildly different from their unsugared counterpart, but are
unified in Lua.

In contrast, |x| x*x is not conceptually different from the variant
written with reserved words.

> So if people want functional syntax, design a *proper* functional
> language syntax from the ground up and translate it into Lua. That way
> you get other functional things like everything-is-an-expression, etc.
> Most functional languages have simple syntaxes that are easy to parse,
> too.

Actually, I am considering trying my hand at reasonably efficient
Scheme->Lua translation.  The music typesetter Lilypond has a somewhat
inscrutable C++/Scheme implementation/extension language system that
seems to put more limitations on readability, extensibility and control
flow than I am fond of.  In particular, coroutines are just nice to
have, and continuations with a large warning label "don't use if you
require efficiency" are not a proper substitute.  At least simple
user-level Scheme code would need to be supported to maintain
compatibility.

However, this would be a rather large project all in all.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Ignacio Burgueño
In reply to this post by Enrico Tassi-3
Enrico Tassi wrote:

> On Fri, Dec 04, 2009 at 10:27:29AM -0200, Luiz Henrique de Figueiredo wrote:
>>> I think it'll probably remain an external addon; it's just a one-line change
>>> in llex.c.
>> I meant, it's a one line-change to include a .c file that does whatever
>> filtering you need. The point being that you can maintain your variants
>> without messing with the Lua sources.
>
> Please, reconsider this approach. Matthew is right in highlighting the
> fact that having to modify the source of a software to activate a
> feature is not an option for software distributions.

But this particular issue can be solved with external libraries (like
Leg [1] or Luma [2]) am I right?

Having token filters as part of the standard library would save you an
external dependency, but you'll still need your custom parser (or
whatever is used to deal with those filtered tokens).


[1] http://leg.luaforge.net/
[2] http://luma.luaforge.net/


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Francesco Abbate-2
In reply to this post by Sam Roberts
2009/12/4 Sam Roberts <[hidden email]>:
> Sorry, I've had lots of problems with LNUM before. Maybe it's better,
> now, but I'm no longer a fan of hacking the interpreter.
>
> And we are thinking of moving to Mike Pall's JIT, I don't think LNUM
> is going to work with it.
>
> Would complex support with a more portable, userdata-based approach
> (like http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lcomplex) be too,
> uh, complex?

As I've already explained for GSL shell I *really* need complex number
as *native* types. Please note that complex numbers are supported by C
programming language with standard C99.

> There are some problems with the build system.
>
> lua: error loading module 'gsl' from file './gsl.so':
>        ./gsl.so: undefined symbol: xwin_thread_function

Congratulation, you've the first to discover that the build system is
broken to build the DLL since the introduction of the AGG plot module
:-) sorry

I've already fixed the problem but for the moment I'm unable to commit
or to upload a new file. I will be able to do that this evening (may
be), I will inform you when is done.

Thank you for your feeback.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

David Given
In reply to this post by Luiz Henrique de Figueiredo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luiz Henrique de Figueiredo wrote:
>> I will say that I'd be very happy if they could consider adding #line support.
>
> See http://lua-users.org/lists/lua-l/2005-06/msg00111.html
>
> This code was written before token filters and can be easily converted in one.

Is there a chance this will make it into 5.2? For what I'm doing, I want
my generated code to be as portable as possible, and so depending on
custom Lua patches is a bit of a no-no...

- --
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksZIf4ACgkQf9E0noFvlzgdOgCeKE38o+AeuJHLVmKfn4lMozNu
Mk4AnAxYWlZlC7tFz0foSTFEqAqqJgO7
=MjO3
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Paul Hudson-2
In reply to this post by Norman Ramsey


2009/12/3 Norman Ramsey <[hidden email]>
  This syntax, from Haskell, looks
like line noise only if you've never seen lambda calculus.

Something that I would claim applies to the vast majority of Lua programmers.
 
  The information density for the Haskell syntax is much higher.

Regarding syntax that has higher information density as  'better" would seem to lead you inexorably to APL (or J). It's  not clear to me that higher information density is a positive for this idea.



Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Philippe Lhoste
In reply to this post by Luiz Henrique de Figueiredo
On 04/12/2009 11:12, Luiz Henrique de Figueiredo wrote:
> And one possible syntax could be
> function (x,y,z)=x+y*z

Or:
   function (x, y, z) x + y * z end

which isn't much longer (even more looking at the proposed -> alternative...), remains
close of current syntax and clearly defines where the expression ends.
Actually, it only makes 'return' optional, which isn't unlike JavaFX (which might have
taken the idea from some other language(s)) which considers that the last expression of a
function is the return value of that function.

People will find 'function' still too verbose, but I am not fan of |x| or \x syntaxes
within Lua which doesn't abuse of such notations (they are fines in themselves, of course).

So perhaps we can reuse some keyword in a different context (I might miss some syntactic
ambiguity, though), eg.:

   do: (x, y, z) x + y * z end

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Christopher Eykamp
By changing the whitespace, you can make the current syntax much easier
to read:

function(x, y, z)    return x + y + z   end

or, perhaps,

function(x, y, z)   return(x + y + z)   end


Chris


Philippe Lhoste wrote:

> On 04/12/2009 11:12, Luiz Henrique de Figueiredo wrote:
>> And one possible syntax could be
>>     function (x,y,z)=x+y*z
>
> Or:
>   function (x, y, z) x + y * z end
>
> which isn't much longer (even more looking at the proposed ->
> alternative...), remains close of current syntax and clearly defines
> where the expression ends.
> Actually, it only makes 'return' optional, which isn't unlike JavaFX
> (which might have taken the idea from some other language(s)) which
> considers that the last expression of a function is the return value
> of that function.
>
> People will find 'function' still too verbose, but I am not fan of |x|
> or \x syntaxes within Lua which doesn't abuse of such notations (they
> are fines in themselves, of course).
>
> So perhaps we can reuse some keyword in a different context (I might
> miss some syntactic ambiguity, though), eg.:
>
>   do: (x, y, z) x + y * z end
>
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Francesco Abbate-2
In reply to this post by Doug Rogers
I see that there are a lot of resistance to introduce the short
function syntax :

|args| expr  ==> function(args) return expr end

The main reason is not technical but just a matter of style, many
people prefer to keep a more traditional keyword based syntax. Another
given reason is to avoid another level of precedence.

I believe that, from a mathematical/functional point of view it is a
very useful notation and if it is noisy than we should consider that

a = 2 + 4*x - 3*x^2 + f(a+b)

is an incredibly noisy notation because of the '=', '+', '*', '^', '('
and ')' without not even a keyword. It is nevertheless universally
accepted as one of the most convenient notation both in mathematics
and in programming. I believe that the same logic also applies to the
short function syntax. But anyway, I will not argue anymore, I can
understand that Lua user base is not so mathematical of functional
oriented and prefer to keep the traditional notation using the
'function' keyword.

Another resistance is against modification of the interpreter to
introduce complex numbers. For me is very simple: people without a
strong mathematical background does not understand the importance of
complex numbers. In my point of view the complex number as native
types is *fundamental* for any serious numerical calculation work .
full stop. If the majority of people here does not want to introduce
complex numbers in Lua I understand because the majority of the user
base has a background mainly on IT or computer science and not on
mathematics, but IMHO this is an error. full stop.

I'm going to keep the same orientation for GSL shell whatever Lua
people may decide about mainstream Lua release.

People here have suggested to:
- prefix with 'math.' and 'gsl.' all the functions I'm using like
'sqrt' or 'plot'
- keep the full function literal notation
if I adopt these suggestion the GSL shell code will became awful and
painful to write as well to read, so I simply cannot adopt this
suggestion . full stop.

Otherwise I will remark that no help whatsoever came till now to help
the development of GSL shell. That is a little bit unfortunate because
a Lua package for numerical computation and graphics will be of great
benefits for Lua itself in the long term but this is just my idea.

So, I will continue to develop GSL shell as before, alone. Thank you guys.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

Cosmin Apreutesei
In reply to this post by David Kastrup
> The one thing that really struck me about Lua is that Lua programs looks
> like Lua.  They don't go fancy-syntax fishing elsewhere.  That's kind of
> unusual for a script language nowadays.

Some of that comes form its liberating semantics, but there's also
some crafted screen aesthetics going on which many dynamic languages
seem to overlook, and nice to see them in Lua:
 - good interleaving of keywords with symbols (contrary to perl,
haskell or the mathematical notation, more likely designed for the
chalkboard or paper)
 - good interleaving of whitespace with letterspace (unlike
curly-brace languages)
 - economic use of symbols, choosing those that look good on the
screen and are easy to type (eg. look at the conversation about
choosing a length operator some years ago)

I think the impact on these qualities should be evaluated when asking
for more syntax sugar especially if it includes new symbols :)
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

Jerome Vuarand
2009/12/4 Cosmin Apreutesei <[hidden email]>:

>> The one thing that really struck me about Lua is that Lua programs looks
>> like Lua.  They don't go fancy-syntax fishing elsewhere.  That's kind of
>> unusual for a script language nowadays.
>
> Some of that comes form its liberating semantics, but there's also
> some crafted screen aesthetics going on which many dynamic languages
> seem to overlook, and nice to see them in Lua:
>  - [...]
>  - economic use of symbols, choosing those that look good on the
> screen and are easy to type (eg. look at the conversation about
> choosing a length operator some years ago)

For symbols that's very variable on localized keyboards. On a fr_FR
keyboard, # is awkward to type, and ~= is even worse. English words
have the advantage that they are  easy to type on most (all?)
latin-alphabet-based keyboards.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

David Jones-2
In reply to this post by Francesco Abbate-2
2009/12/4 Francesco Abbate <[hidden email]>:
> Another resistance is against modification of the interpreter to
> introduce complex numbers. For me is very simple: people without a
> strong mathematical background does not understand the importance of
> complex numbers. In my point of view the complex number as native
> types is *fundamental* for any serious numerical calculation work .
> full stop. If the majority of people here does not want to introduce
> complex numbers in Lua I understand because the majority of the user
> base has a background mainly on IT or computer science and not on
> mathematics, but IMHO this is an error. full stop.

We don't want to introduce complex numbers into Lua because they don't
work on 1990 C (ISO 9899:1990), and real people still do real work on
platforms that only have ISO C 1990 compilers.

It is not hard to modify Lua to add complex numbers, and that's no
accident (in fact, I even had a very small hand in it).

You're attitude is bordering on arrogant.

David Jones
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Luiz Henrique de Figueiredo
In reply to this post by Philippe Lhoste
> Or:
>    function (x, y, z) x + y * z end

That's very hard to parse. Consider
    function (x, y, z) x[<complicated expression>][z] end
versus
    function (x, y, z) x[<complicated expression>](z) return f(x,y,z) end
which is valid right now.
1234567