Menu
▾
▴
pure-lang-users
|
From: Albert G. <Dr....@t-...> - 2008-08-14 20:58:30
|
Hi all,
Now that Pure 0.5 is almost done, I've come to consider some (non
backward-compatible) syntax changes that I'd like to do, rather now than
later:
- First and foremost, I want to see whether I can massage the grammar so
that it becomes possible to write lists of tuples using the special case
syntax [(1,2),(3,4),...]. That's not straightforward because it
introduces ambiguities that I'll have to eliminate somehow, but I think
it's worth the effort, because it sucks having to write
(1,2):(3,4):...:[] all the time.
- I'd also like to revise the syntax of 'using' so that the module names
are separated by commas, which is more in line with the 'extern'
declaration syntax which also uses the comma delimiter. (I'd still like
to keep the syntax of operator and 'nullary' declarations, though,
because there whitespace as a delimiter is much easier to read when
listing non-alphanumeric symbols, IMHO.)
- The discussion I had with Libor about how to implement a sequencing
operator ("first x, then y") also kept me thinking, because the solution
I proposed there is not tail-recursive. To do this in a proper way, we'd
need a built-in sequencing operator (special form). While it's not
strictly needed, it's much more convenient than having to write 'y when
_ = x end' all the time.
That sequencing operator should be easy to implement, but how should it
be named? We can't use Q's '||' because that's logical or in Pure, and
we can't use C's ',' because that's Pure's tupling operator. Another
obvious choice would be the Haskell'ish monadic sequencing operator '>>'
but that's currently used for bit shifts (maybe I could rename '<<'/'>>'
to shl/shr, though). Any other ideas?
Finally (this is not a syntax change, but it also breaks backward
compatibility), I'd like to revise the script search. Currently the
interpreter always searches the current directory and then the PURELIB
directory. In the case that the interpreter is run with a main script
(pure -x main.pure), I think it makes sense to search the directory of
the main script instead of the cwd (for scripts loaded with a 'using'
clause). That would make it possible to install the main script along
with any other non-library modules it needs into its own directory and
run it from there. This would be useful, in particular, for "shebang"
scripts.
So what do you all think about these? Any objections? Comments?
TIA,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr....@t-..., ag...@mu...
WWW: http://www.musikinformatik.uni-mainz.de/ag
|
|
From: Eddie R. <er...@bm...> - 2008-08-14 21:41:18
|
On Thu, 2008-08-14 at 22:59 +0200, Albert Graef wrote:
> it's worth the effort, because it sucks having to write
> (1,2):(3,4):...:[] all the time.
+1
> - I'd also like to revise the syntax of 'using' so that the module names
> are separated by commas, which is more in line with the 'extern'
> declaration syntax which also uses the comma delimiter. (I'd still like
> to keep the syntax of operator and 'nullary' declarations, though,
> because there whitespace as a delimiter is much easier to read when
> listing non-alphanumeric symbols, IMHO.)
OK by me.
> - The discussion I had with Libor about how to implement a sequencing
> operator ("first x, then y") also kept me thinking, because the solution
> I proposed there is not tail-recursive. To do this in a proper way, we'd
> need a built-in sequencing operator (special form). While it's not
> strictly needed, it's much more convenient than having to write 'y when
> _ = x end' all the time.
> That sequencing operator should be easy to implement, but how should it
> be named? We can't use Q's '||' because that's logical or in Pure, and
> we can't use C's ',' because that's Pure's tupling operator. Another
> obvious choice would be the Haskell'ish monadic sequencing operator '>>'
> but that's currently used for bit shifts (maybe I could rename '<<'/'>>'
> to shl/shr, though). Any other ideas?
I've been using $$ or |> but whatever you decide is fine by me.
One minor quibble. Could we use ++ for list and string concatenation? It
interferes with using + for adding matrices when they are implemented as
lists of lists.
> Finally (this is not a syntax change, but it also breaks backward
> compatibility), I'd like to revise the script search. Currently the
> interpreter always searches the current directory and then the PURELIB
> directory. In the case that the interpreter is run with a main script
> (pure -x main.pure), I think it makes sense to search the directory of
> the main script instead of the cwd (for scripts loaded with a 'using'
> clause). That would make it possible to install the main script along
> with any other non-library modules it needs into its own directory and
> run it from there. This would be useful, in particular, for "shebang"
> scripts.
+1
Does TIA mean "The Intellectual Activist?" ;-)
e.r.
|
|
From: Albert G. <Dr....@t-...> - 2008-08-15 00:17:18
|
Eddie Rucker wrote: > I've been using $$ or |> but whatever you decide is fine by me. $$ doesn't look too bad. > One minor quibble. Could we use ++ for list and string concatenation? It > interferes with using + for adding matrices when they are implemented as > lists of lists. Well, actually I thought about this (in fact Q has this for exactly this reason). But lists are an awfully inefficient data structure to do matrix calculations anyway. In order to properly support GSL, we need an array data type that can be just passed to the GSL routines as is. As soon as your GSL module begins to take shape, I'm going to work on that. > Does TIA mean "The Intellectual Activist?" ;-) OMG BTW IANAL BALIKMFA !! ;-) Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2008-08-14 21:47:23
|
Albert Graef scripsit:
> That sequencing operator should be easy to implement, but how should it
> be named? We can't use Q's '||' because that's logical or in Pure, and
> we can't use C's ',' because that's Pure's tupling operator. Another
> obvious choice would be the Haskell'ish monadic sequencing operator '>>'
> but that's currently used for bit shifts (maybe I could rename '<<'/'>>'
> to shl/shr, though). Any other ideas?
How about -> ?
> Finally (this is not a syntax change, but it also breaks backward
> compatibility), I'd like to revise the script search. Currently the
> interpreter always searches the current directory and then the PURELIB
> directory. In the case that the interpreter is run with a main script
> (pure -x main.pure), I think it makes sense to search the directory of
> the main script instead of the cwd (for scripts loaded with a 'using'
> clause). That would make it possible to install the main script along
> with any other non-library modules it needs into its own directory and
> run it from there. This would be useful, in particular, for "shebang"
> scripts.
The sequence used by gcc is:
1) the directory from which this file was loaded (which may itself be
a file loaded by includes)
2) the process working directory
3) specified directories with -I
4) specified directories in the environment variable *_INCLUDE_PATH
5) the system directories
--
Only do what only you can do. John Cowan <co...@cc...>
--Edsger W. Dijkstra's advice
to a student in search of a thesis
|
|
From: Jeremy V. <jvo...@gm...> - 2008-08-14 22:01:16
|
Just my $0.02: +1 to >>, for its consistency with Haskell (but I'm not suggesting that Pure should be Haskell). To qualify my opinion, I think I am much more likely to use a sequencing operator than I am to shift bits. I wouldn't mind using $$. -1 to -> since I am accustomed to seeing it in Haskell and ML type sigs. Best, Jeremy Voorhis On Thu, Aug 14, 2008 at 2:47 PM, John Cowan <co...@cc...> wrote: > Albert Graef scripsit: > >> That sequencing operator should be easy to implement, but how should it >> be named? We can't use Q's '||' because that's logical or in Pure, and >> we can't use C's ',' because that's Pure's tupling operator. Another >> obvious choice would be the Haskell'ish monadic sequencing operator '>>' >> but that's currently used for bit shifts (maybe I could rename '<<'/'>>' >> to shl/shr, though). Any other ideas? > > How about -> ? I'm not too fond of |
|
From: John C. <co...@cc...> - 2008-08-14 22:03:37
|
Jeremy Voorhis scripsit: > -1 to -> since I am accustomed to seeing it in Haskell and ML type sigs. I can live with >> . What about => ? -- John Cowan co...@cc... http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King |
|
From: Jeremy V. <jvo...@gm...> - 2008-08-14 22:18:47
|
=> seems like a good choice, though I might have a little trouble dissociating it from Ruby's "hash rocket" operator. Best, On Thu, Aug 14, 2008 at 3:03 PM, John Cowan <co...@cc...> wrote: > Jeremy Voorhis scripsit: > >> -1 to -> since I am accustomed to seeing it in Haskell and ML type sigs. > > I can live with >> . What about => ? > > > -- > John Cowan co...@cc... http://www.ccil.org/~cowan > Most languages are dramatically underdescribed, and at least one is > dramatically overdescribed. Still other languages are simultaneously > overdescribed and underdescribed. Welsh pertains to the third category. > --Alan King > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > pure-lang-users mailing list > pur...@li... > https://lists.sourceforge.net/lists/listinfo/pure-lang-users > |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 00:30:19
|
Jeremy Voorhis wrote: > => seems like a good choice, though I might have a little trouble > dissociating it from Ruby's "hash rocket" operator. Actually it's a "hash rocket" in Pure as well (used in Jiri's dictionary and Eddie's csv module). So not possible either, sorry. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 00:26:13
|
John Cowan wrote: > How about -> ? Not possible (used in lambdas: \x->2*x). > The sequence used by gcc is: That sounds more reasonable than my suggestion, and doesn't depend on the -x option. So for each script named in a 'using' clause: - search the directory of the script containing the using clause - failing that, search the cwd - failing that, search PURELIB Sounds good to me. Any objections? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 11:12:41
|
Albert Graef wrote: > - search the directory of the script containing the using clause > > - failing that, search the cwd > > - failing that, search PURELIB Thinking about this some more, I realized that this is vunerable to code injection. What if the user inadvertently puts a module named 'primitives.pure' into the cwd? Therefore I think that PURELIB should actually be searched before the cwd (much like #include <foo.h> in C). Note that if the 'using' script is in the cwd, then the cwd will still be searched first anyway. Also, this will only apply to 'using' clauses, not to scripts specified on the command line or with 'run'. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-08-15 12:39:26
|
On Fri, 2008-08-15 at 13:13 +0200, Albert Graef wrote: > Albert Graef wrote: > > - search the directory of the script containing the using clause > > > > - failing that, search the cwd > > > > - failing that, search PURELIB > > Thinking about this some more, I realized that this is vunerable to code > injection. What if the user inadvertently puts a module named > 'primitives.pure' into the cwd? What if we want to override the primitives.pure for some strange reason that I cannot think of yet? Maybe we should have some mechanism like using <foo.pure> so that we know it's the one in the standard library? > Therefore I think that PURELIB should actually be searched before the > cwd (much like #include <foo.h> in C). Note that if the 'using' script > is in the cwd, then the cwd will still be searched first anyway. Also, > this will only apply to 'using' clauses, not to scripts specified on the > command line or with 'run'. |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 13:28:40
|
Eddie Rucker wrote: > What if we want to override the primitives.pure for some strange reason > that I cannot think of yet? Well, it's a kludge, but of course you could just ship a custom prelude with your application and write a wrapper script that sets up PURELIB accordingly. I think that this is actually preferable, since it makes it clear that your program operates in a nonstandard environment. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-16 23:51:47
|
Albert Graef wrote: > Eddie Rucker wrote: >> What if we want to override the primitives.pure for some strange reason >> that I cannot think of yet? > > Well, it's a kludge, but of course you could just ship a custom prelude > with your application and write a wrapper script that sets up PURELIB > accordingly. I think that this is actually preferable, since it makes it > clear that your program operates in a nonstandard environment. I should have read the manpage first. ;-) Of course the simplest way to override the prelude and its dependent modules still is to just place prelude.pure et al into the current directory. This works because the prelude is searched first in the cwd, and with the new script search algorithm other modules used by the prelude then pick up the path from prelude.pure. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-16 23:47:30
|
Albert Graef wrote: >> - search the directory of the script containing the using clause >> >> - failing that, search the cwd >> >> - failing that, search PURELIB > > Thinking about this some more, I realized that this is vunerable to code > injection. What if the user inadvertently puts a module named > 'primitives.pure' into the cwd? > > Therefore I think that PURELIB should actually be searched before the > cwd (much like #include <foo.h> in C). Note that if the 'using' script > is in the cwd, then the cwd will still be searched first anyway. Also, > this will only apply to 'using' clauses, not to scripts specified on the > command line or with 'run'. Ok, this is implemented now. I also threw in some script name canonicalization and symbolic link resolution, details can be found in the ChangeLog and in the DECLARATIONS section of the manpage. The new 'using' syntax is now implemented as well, so multiple script names in one clause have to be separated with commas now. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-17 21:34:29
|
Albert Graef wrote: > Albert Graef wrote: >>> - search the directory of the script containing the using clause >>> >>> - failing that, search the cwd >>> >>> - failing that, search PURELIB > > Ok, this is implemented now. I also threw in some script name > canonicalization and symbolic link resolution, details can be found in > the ChangeLog and in the DECLARATIONS section of the manpage. I still wasn't satisfied with all this, so I gave it another thorough overhaul. The new search algorithm also puts to rest the non-portable workarounds which were necessary to load dynamic libraries in Pure scripts. I hope that this will do the job now. Here's the full blurb from the ChangeLog: The prelude is now *always* searched for in PURELIB only, to prevent code injection issues. Thus to use a custom prelude you'll have to set the PURELIB environment variable accordingly, or employ the '-n' option and explicitly specify the prelude on the command line. Scripts specified on the command line or with the 'run' command will *only* be searched for in the current directory. In addition to the PURELIB environment variable, new -I/-L command line options and PURE_INCLUDE/PURE_LIBRARY environment variables are now available to specify additional directories to search for source files and dynamic libraries specified using relative pathnames in 'using' clauses. For source scripts opened with a 'using' clause, the interpreter searches the following directories in the given order: - the directory of the script containing the 'using' clause (or the current working directory if the 'using' clause is read from standard input), - directories specified with -I, in the order in which they are specified on the command line, - directories specified in colon-separated format in the PURE_INCLUDE variable, in the order in which they are specified, - the PURELIB directory. Similarly, dynamic libraries are searched for in: - the directory of the script containing the 'using' clause (or the current working directory if the 'using' clause is read from standard input), - directories specified with -L, in the order in which they are specified on the command line, - directories specified in colon-separated format in the PURE_LIBRARY variable, in the order in which they are specified, - the PURELIB directory, - other platform-specific locations searched by the dynamic linker, such as system library directories and LD_LIBRARY_PATH on Linux. Note that in either case the current working directory is *not* searched by default (unless the 'using' clause is read from standard input), but of course you can force this by adding '.' to the corresponding search path. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Libor S. <li...@gm...> - 2008-08-14 22:23:27
|
On Thu, 14 Aug 2008 21:59:01 +0100, Albert Graef <Dr....@t-...> wrote:
> Hi all,
>
> Now that Pure 0.5 is almost done, I've come to consider some (non
> backward-compatible) syntax changes that I'd like to do, rather now than
> later:
>
> - First and foremost, I want to see whether I can massage the grammar so
> that it becomes possible to write lists of tuples using the special case
> syntax [(1,2),(3,4),...]. That's not straightforward because it
> introduces ambiguities that I'll have to eliminate somehow, but I think
> it's worth the effort, because it sucks having to write
> (1,2):(3,4):...:[] all the time.
>
I agree! I remember finding it quite confusing compared to prolog's lists,
where you can easily use the [(1,2),(3,4),...] form.
What is more, you can also use the comma as a simple sequencing operator
(cf. below), though it does have somewhat different semantics there,
of course.
I am not entirely convinced that the tuples are even worth having at all.
For the minimal (flatness) distinction, they ship in a lot of confusion.
Imho it is seldom a good idea having two conflicting mechanisms for doing
two almost identical things.
> - I'd also like to revise the syntax of 'using' so that the module names
> are separated by commas, which is more in line with the 'extern'
> declaration syntax which also uses the comma delimiter. (I'd still like
> to keep the syntax of operator and 'nullary' declarations, though,
> because there whitespace as a delimiter is much easier to read when
> listing non-alphanumeric symbols, IMHO.)
That sounds OK to me.
>
> - The discussion I had with Libor about how to implement a sequencing
> operator ("first x, then y") also kept me thinking, because the solution
> I proposed there is not tail-recursive. To do this in a proper way, we'd
> need a built-in sequencing operator (special form). While it's not
> strictly needed, it's much more convenient than having to write 'y when
> _ = x end' all the time.
Good, thanks!
>
> That sequencing operator should be easy to implement, but how should it
> be named? We can't use Q's '||' because that's logical or in Pure, and
> we can't use C's ',' because that's Pure's tupling operator. Another
> obvious choice would be the Haskell'ish monadic sequencing operator '>>'
> but that's currently used for bit shifts (maybe I could rename '<<'/'>>'
> to shl/shr, though). Any other ideas?
I must say << and >> are so well known that, at least in my mind, they are
synonymous with the bit shifts. Given the strong links to C via LLVM,
I think that syntactic similarity with C would be good to maintain as much as
possible. On the other hand, if Pure is one day to compete with,
or even to overtake Haskell, the need to be syntactically compatible with it
is less pressing. Have you considered naming the sequencing operator instead?
Something like seq or fb (followed by) might do?
It seem that the special characters are a valuable 'real estate' in
short supply. Especially in view of the fact that the user will want them too
for defining operators! It may be worth adopting some convention to distinguish
user defined operators (such as all starting with a designated character)?
Echoes of APL here....
>
> Finally (this is not a syntax change, but it also breaks backward
> compatibility), I'd like to revise the script search. Currently the
> interpreter always searches the current directory and then the PURELIB
> directory. In the case that the interpreter is run with a main script
> (pure -x main.pure), I think it makes sense to search the directory of
> the main script instead of the cwd (for scripts loaded with a 'using'
> clause). That would make it possible to install the main script along
> with any other non-library modules it needs into its own directory and
> run it from there. This would be useful, in particular, for "shebang"
> scripts.
No objections to this, sounds good.
Regards, Libor
|
|
From: John C. <co...@cc...> - 2008-08-14 22:34:53
|
Libor Spacek scripsit: > I am not entirely convinced that the tuples are even worth having at all. > For the minimal (flatness) distinction, they ship in a lot of confusion. > Imho it is seldom a good idea having two conflicting mechanisms for doing > two almost identical things. +1. In Q they are fixed-length vectors and seem worth having. In Pure they seem like a kind of substitute for multiple-valued functions. -- I could dance with you till the cows John Cowan come home. On second thought, I'd http://www.ccil.org/~cowan rather dance with the cows when you co...@cc... come home. --Rufus T. Firefly |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 01:10:45
|
John Cowan wrote: > +1. In Q they are fixed-length vectors and seem worth having. In Pure > they seem like a kind of substitute for multiple-valued functions. Well, they're useful for what they are, a kind of sequence "without all those darn brackets". Multi-valued functions is one application, but they're also useful for "multi-valued arguments" such as 1,3..7. That's all the more important because Pure doesn't allow you to define your own n-ary (n>=3) and mixfix operators. The only downside I see is that we can't use ',' for the sequencing operator. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 00:59:52
|
Libor Spacek wrote: > I must say << and >> are so well known that, at least in my mind, they are > synonymous with the bit shifts. That's true. But as Jeremy already pointed out, in a high-level language they're of limited usefulness (they mostly provide just a convenient shorthand for multiplying and dividing integers by powers of 2). And we already had to rename '&' and '|' as well. > Have you considered naming the sequencing operator instead? > Something like seq or fb (followed by) might do? > It seem that the special characters are a valuable 'real estate' in > short supply. Yes, but short identifiers are a scarce resource, too, maybe even more so. I wouldn't want to take something like 'fb' away from the user. (Once it's defined as an operator, it becomes part of the syntax and can't be used for any other purpose any more.) So we're basically left with $$ and >>. Even though I proposed >> myself, I think I like $$ better. Unless someone finds use for a Joda'ish "reversed sequencing" operator <<. ;-) Would everyone be happy with $$ ? (Or at least grudgingly put up with it?) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Libor S. <li...@gm...> - 2008-08-15 10:21:37
|
> > Would everyone be happy with $$ ? (Or at least grudgingly put up with it?) > > Albert > +1 Yes, you are right about short identifiers being restrictive as well. $$ is better. L. |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 01:15:58
|
Libor Spacek wrote: > I am not entirely convinced that the tuples are even worth having at all. > For the minimal (flatness) distinction, they ship in a lot of confusion. Can you elaborate on that? The only complication I see is the borked list-of-tuples syntax, and I'm about to fix that (hopefully!). -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 13:51:30
|
Eddie Rucker wrote: >> 1 2 3 > Hey Libor, that's cute! Tain't thought of that one. But, ... How do you > get at the elements? That's easy: > f x = a [] x with a xs (x@_ y) = a (y:xs) x; a xs x = x:xs end; > f (1 2 3 4); [1,2,3,4] > Would be nice if we could have something like [1 2 3 4] That would wreak havoc on the Pure grammar. But the above hack should do the trick as long as the first element can't be mistaken for a closure. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-08-15 14:09:27
|
On Fri, 2008-08-15 at 15:52 +0200, Albert Graef wrote: > Eddie Rucker wrote: > >> 1 2 3 > > Hey Libor, that's cute! Tain't thought of that one. But, ... How do you > > get at the elements? > > That's easy: > > > f x = a [] x with a xs (x@_ y) = a (y:xs) x; a xs x = x:xs end; > > f (1 2 3 4); > [1,2,3,4] > > > Would be nice if we could have something like [1 2 3 4] > > That would wreak havoc on the Pure grammar. But the above hack should do > the trick as long as the first element can't be mistaken for a closure. Understood about the havoc on the pure grammar. I thought you had something very useful for me for a second. However, > f x = a [] x with a xs (x@_ y) = a (y:xs) x; a xs x = x:xs end; > let k = f (); when I highlight a sequence of numbers vertically from an openoffice spreadsheet and middle click in the () I get > let k = f ();34 > 56 > 78 > 34 > 56 > 12 And when I highlight a sequence of numbers horizontally from an openoffice spreadsheet and middle click in the () I get > let k = f();34122334 Note quite what I was looking for but don't worry about it and be happy ;-) e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-08-15 23:37:07
|
Eddie Rucker wrote: > when I highlight a sequence of numbers vertically from an openoffice > spreadsheet and middle click in the () I get Yeah, I get similar results, with both OOo calc and qcalc, so I believe it's a konsole/xterm issue. Well, I guess we need a port of qcalc asap, but first I need to get the base system right, then the SWIG interface, then port Qt/Q... Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Jeremy V. <jvo...@gm...> - 2008-08-15 04:25:56
|
OMG $$++ Regarding tuples, I've always thought of tuples as representing structures with a fixed number of slots, and that this was a perfectly valid thing to do. My Pure abilities are still weak, so somebody help me out – I assumed tagged tuples would be useful for representing algebraic types in a dynamic language like Pure, since they are good for matching on. Is there a better way? Best, Jeremy Voorhis On Thu, Aug 14, 2008 at 5:17 PM, Albert Graef <Dr....@t-...> wrote: > Eddie Rucker wrote: >> I've been using $$ or |> but whatever you decide is fine by me. > > $$ doesn't look too bad. > >> One minor quibble. Could we use ++ for list and string concatenation? It >> interferes with using + for adding matrices when they are implemented as >> lists of lists. > > Well, actually I thought about this (in fact Q has this for exactly this > reason). But lists are an awfully inefficient data structure to do > matrix calculations anyway. In order to properly support GSL, we need an > array data type that can be just passed to the GSL routines as is. As > soon as your GSL module begins to take shape, I'm going to work on that. > >> Does TIA mean "The Intellectual Activist?" ;-) > > OMG BTW IANAL BALIKMFA !! ;-) > > Cheers, > Albert > > -- > Dr. Albert Gr"af > Dept. of Music-Informatics, University of Mainz, Germany > Email: Dr....@t-..., ag...@mu... > WWW: http://www.musikinformatik.uni-mainz.de/ag > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > pure-lang-users mailing list > pur...@li... > https://lists.sourceforge.net/lists/listinfo/pure-lang-users > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X