Send guile-user mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/guile-user
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of guile-user digest..."
Today's Topics:
1. Re: How to make GNU Guile more successful (Marko Rauhamaa)
2. Re: How to make GNU Guile more successful (Panicz Maciej Godek)
3. Help formatting a UTC Timestamp (Guy Baumann)
4. Re: Help formatting a UTC Timestamp (address@hidden)
5. Re: Help formatting a UTC Timestamp (Chris Vine)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Feb 2017 07:59:07 +0200
From: Marko Rauhamaa <address@hidden>
To: Arne Babenhauserheide <address@hidden>
Cc: Panicz Maciej Godek <address@hidden>,
"address@hidden" <address@hidden>
Subject: Re: How to make GNU Guile more successful
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8
Arne Babenhauserheide <address@hidden>:
Marko Rauhamaa <address@hidden> writes:
Then, there's GOOPS, which in my opinion is simply an unnatural way
to go about object-oriented programming. It does violence both to
ordinary OO way of thinking and classic Lisp idioms.
GOOPS works pretty well for me where I use it (for dispatch by type).
Could you clarify your criticism: Do you think it is bad or is it just
different?
GOOPS starts by defining slots. Slots are an objects internal business
and should not be visible to the outside. Instead, objects should be
black boxes that interact with methods. For example, the port interface
is a nice, classic OO API. You don't know anything about the slots of a
port.
Furthermore, I think an extensive type system is un-Lisp-like. OO is not
about things belonging to a type but objects interacting through
methods. In fact, the concept of a "class" could be done away with.
Continuations and multiple values are obstacles instead of enablers.
I think multiple values are nice. But they are not well-integrated (I
have to import something to use them). Why do you think them enablers?
Yes, the multiple values API is a problem in and of itself, but more
generally, what does:
(values a b c)
give you on top of, say:
(list a b c)
Why do you think that continuations are an obstacle (do you mean
general continuations or do you mean prompts)?
Continuations prevent you from implementing Python's try/finally and
emacs' (unwind-protect).
On the other hand, I don't think any application developer would come to
a point of thinking, "Hey, I know, I'll use a continuation!"
asyncio, type annotation,
type annotations should provide nice ways to optimize for pypy and
other more optimizing Python implementations.
You can't have it bothways. A dynamic language liberates you from
shackles and boilerplate even if it destroys your performance. The
moment you bring in the boilerplate, you are back to Java.
Decorators are really cool to use:
Have yet to find a need for one.
dunder jungle,
What?s that?
<URL: https://docs.python.org/3/genindex-_.html>
meta-object programming,
That?s needed to make some things elegant. "Different 20%"-rule again.
Again, I haven't yet found a need to deviate from the regular object
semantics.
Unicode illusion. (Guile has fallen into that last trap as well,
unfortunately.)
I?m using Python and Guile for physics and math (to some degree), and
having good Unicode-support is great for that. What?s your practical
criticism here?
In Linux, all pathnames, files, sockets, environment variables and
command-line arguments are, or deal with, bytes. The bytes are often
encoded with UTF-8, but a programming language cannot assume that, even
if LOCALE promises otherwise.
It would be better to leave Unicode out of Guile's system interface and
have the application encode and decode explicitly where needed.
There's one thing Python has over Guile, still: Python's system call
support is outstanding. For example, I managed to implement a
full-blown shell using Python. That was the first time I ever ran
into terminal-related system calls, and Python had them all.
Which ones are missing in Guile?
For example tcgetattr(3). (Ok, not a system call.)
Missing epoll(2) is inconvenient. Not being able to transfer an open
file descriptor via sendmsg(2) is really bad.
Marko
------------------------------
Message: 2
Date: Tue, 14 Feb 2017 10:54:38 +0100
From: Panicz Maciej Godek <address@hidden>
To: Arne Babenhauserheide <address@hidden>
Cc: Amirouche <address@hidden>, "address@hidden"
<address@hidden>
Subject: Re: How to make GNU Guile more successful
Message-ID:
<address@hidden
gmail.com>
Content-Type: text/plain; charset=UTF-8
2017-02-13 23:54 GMT+01:00 Arne Babenhauserheide <address@hidden>:
Panicz Maciej Godek <address@hidden> writes:
2017-02-13 12:06 GMT+01:00 Arne Babenhauserheide <address@hidden>:
There's also this problem with Scheme that it is a very diverse
community with plethora of implementations. And while I use Guile, I
don't mind using Chicken or Chez or Gambit for various purposes. Or
even Stalin sometimes. Maybe, instead of getting a better compiler, we
should focus on integrating existing compilers?
You?ll have to ask Andy Wingo about all the hidden complexity in just
wiring in a compilier. I assume it?s pretty big.
I think the r7rs folks are working in that regard, to make it possible
to write code which you can simply run through another Scheme
implementation if you need those strengths.
I started to use (import (...)) to get closer to that: Getting used to
the portable stuff (also it?s shorter than (use-modules (...)). But not
everything is portable, and performance critical stuff most definitely
isn?t.
And for the stuff I do, most things get performance critical at some
point. Even looking for null-bytes in a file becomes a bottleneck if you
have a few hundred TiB to check.
Though I mainly need to write Python at work (Scheme isn?t widespread
enough for the folks there ? Python is everywhere in science
nowadays). It?s still efficient to do that and I enjoy it, but not as
much as writing Scheme.
And it's easy to packages.
=> Another pain topic. In reality it's very easy to package
all sort of guile programs for guix. But guix itself needs
to be more stable.
I wish I had guildhall ready. Got hit by
time-eaten-by-other-project-because-guildhall-was-priority-three.
It needs to be easy to not just package some code, but also to share
that package without hitting a bottleneck.
What happened to initiatives like Scheme NOW, that tried to integrate
various groups of developers.
I did not hear from that.
Or why can't we just "steal" eggs from Chicken? (I mean it. They
already
have that problem solved)
Do you mean, integrating eggs into Guile so we could just use them?
Conceptually what would be needed for that is a metadata field: "Works
with Guile". And practically someone to write the integration.
There's surely many ways to approach that issue. The point is that for some
reason, Schemers from various tribes prefer to reinvent the wheel,
rather than use an existing one. (Not that I am any different)
However, I also think that these CPAN-alike solutions are far from optimal:
ideally, programming could be made an experience similar the game
"The Journey" by thatgamecompany (where you travel to your goal and
sometimes
encounter other players heading the same direction), and the repository
itself could look
more like Wikipedia (but first we'd need to start perceiveing programming
as
a compact way of representing knowledge)
Practically put: We need Andy Wingo to nitpick the tutorial about things
which will cause overheads the compiler cannot fix easily ? including
expensive use of macros.
I definitely oppose. If Chez has something solved better, why not use
Chez?
It?s not "why not use Chez", but rather "what should I teach new
people?"
They are already learning a new language. When I now go and point them
towards many different implementations which differ in details of stuff
I teach them, I?m throwing more complexity at them. More things to
understand before even starting to write working code.
I totally agree. Programmers shouldn't be concerned whether they're
using Chez or Guile or Gambit or Stalin or whatever else. Ideally, they
should do well without even knowing that such things exist.
There are Schemes, such as Kawa or Biwa or IronScheme, that are tied
to their environment, but most of them just run on the PC
Maybe it would already help to mark the code which will work the same in
all (r7rs) Schemes. Is there stuff which is well optimized in all
Schemes? Who knows that? The r7rs benchmarks look like this is very much
not the case: http://ecraven.github.io/r7rs-benchmarks/benchmark.html
(Or rather, the benchmarks would ask: "why should I *not* use Chez or
stalin for everything I do?" Because those are the fastest for most
tasks.)
But that might mean to write less elegant or efficient code to keep it
cross-implementation. Should I rather teach new people to solve a
problem as well as possible, or teach them to solve a problem in a
portable way?
I think that in principle, the programmer should only focus on writing
most elegant code
In my case, I decided to use Guile by checking Scheme
implementations. There were three with roughly equal activity and
features. I chose Guile, because it?s a GNU project and it has a long
history of surviving changing maintainers, so my skills are most likely
to stay useful.
That's interesting. I chose it by trying to add a scripting language to my
game engine written in C++. But I guess that if I was starting now, I'd
write
the whole engine in Chez (which wasn't opensource until last year)
The ultimate goal is not to optimize programs, but programmers.
I?m not sure that I want to optimize them, I want to teach them tools to
be more efficient and enjoy their work more (and teach myself the same).
Yeah, maybe I used a harsh word, but I meant exactly optimizing
programmers' efficiency (or if it sounds too bad, "giving them tools
to be more efficient")
I think one important point for Scheme would be to gather some consensus
points. The Zen of Python is part of what made that one community
strong. There is no reason why there should not be a Zen of Scheme,
along with implementation-specific Koans which extend it.
Do you have ideas for principles which could be shared by most Schemers?
It depends on the most Schemers, not me :)
However, you can have a look at the (grand scheme) glossary that I've been
maintaining for some time:
https://github.com/plande/grand-scheme
of course, the intent is to make the glossary usable for someone else than
me,
and I can boast that I have at least one user distinct from the maintainer.
You can have a look and let me know what you think. (for now it only works
with Guile). In particular, are there any factors that could convince you
to
adapt it as a base for your library, or what would you want changed
(I assume you won't stop at the README file).
Anyways, the rules (of thumb) are:
- functions should be pure
- language constructs that cause side-effects should be encapsulated
with macros that limit the extent of those side-effects
- if possible, use the quasiquote macro, rather than cons, append or
list
- prefer the use of match <http://synthcode.com/scheme/match.scm> to
cond,
if the patterns are simple
- never use abbreviations
- use commented prepositions to separate arguments
Also, I recently added infix syntax to Scheme, but (unlike in Racket or
David Wheeler's solutions) in the way it is still a prefix syntax. So for
example,
instead of writing (< a b), one ought to write (is a < b). The rationale is
that
prefix notation is terrible for non-symmetrical binary predicates, because
it
obscures the roles of respective arguments (in addition, (is a < b <= c)
expands
to (and (< a b) (<= b c))). I'm still not sure whether it is a good idea,
but I have
no reasons to think that it is bad either :]
[Curiously enough, I think that prefix notation in arithmetic is just fine:
(+ a b c) reads as "sum of a, b and c"]
Also, I think that the astounding success of R provides hints with
regard what is needed for a programming language to gain popularity. R
has a large repository of packages that fills a certain niche. When I
advertised my Pamphlet on Hacker News, someone responded critically:
"are there out of the box libraries to estimate a zero inflated
negative binomial regression model in guile". Of course, if I knew
what a zero-inflated negative binomial regression model, I could
deliver an implementation by just explaining the notions used in that
phrase.
I think there?s a quote which applies here: "Most people only use 20% of
the capabilities of any program, but they do not use the same 20%."
? Joel Spolksy, if I remember correctly.
And to make people really dig into it, a programming language must work
well for all tasks they might encounter. That?s why a comprehensive
standard library is important: It gives the assurance that the skills
you learn will stay useful wherever you go.
There?s a nice quote from Rust folks: "people started to feel safe when
we told them about unsafe" ? someone on GNU social.
This essentially says: they then saw that Rust could work in the
uncomfortable way some of their tasks might require. That they could
take it into harsher territory, if needed.
I like it that you and Amirouche look a lot at the sociocultural
perspective
of programming
(But then again, I try to write functional programs whenever
possible, often consciously sacrificing time complexity of my
solutions, and I'm aware that not everybody will like it.)
I look for ease of understanding, with functional programming techniques
being a useful tool to reduce complexity and to simplify refactoring.
But then, this is a point where we actually move into a similar
direction out of different motives. I think the only problem here is the
danger of assuming contradiction where there does not need to be
any. Just different nuances of Zen :)
Yes, to me the ease of understanding is also crucial. (I'd even go
further and say that undestranding is the very point of programming)
Best regards,
Panicz
------------------------------
Message: 3
Date: Tue, 14 Feb 2017 12:27:16 +0000
From: Guy Baumann <address@hidden>
To: address@hidden
Subject: Help formatting a UTC Timestamp
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
I am trying to format a timestamp from an api. It is sent in the
format "2011-03-24T20:30:47Z"
what I want to output is something like this
(strftime "%d %b %g " (localtime (current-time)) )
However I am unable to work out how to do this, have tried using
string->date with results below
Enter `,help' for help.
scheme@(guile-user)> (define date "2011-03-24T20:30:47Z")
scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (string->date "~Y-m-dT~H:~M:SZ" date)
srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
bad-date-format-string: "2011-03-24T20:30:47Z"
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> (string->date date "~Y-m-dT~H:~M:SZ")
srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
bad-date-format-string: "~Y-m-dT~H:~M:SZ"
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [2]> (string->date date "~Y-m-dT~H:~M:SZ")
srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
bad-date-format-string: "~Y-m-dT~H:~M:SZ"
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [3]> (string->date "2000" "~Y")
srfi/srfi-19.scm:571:22: In procedure encode-julian-day-number:
srfi/srfi-19.scm:571:22: In procedure -: Wrong type: #f
thanks for any help
//guy
------------------------------
Message: 4
Date: Tue, 14 Feb 2017 13:48:51 +0100
From: <address@hidden>
To: address@hidden
Subject: Re: Help formatting a UTC Timestamp
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8; x-action=pgp-signed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Feb 14, 2017 at 12:27:16PM +0000, Guy Baumann wrote:
I am trying to format a timestamp from an api. It is sent in the
format "2011-03-24T20:30:47Z"
what I want to output is something like this
(strftime "%d %b %g " (localtime (current-time)) )
However I am unable to work out how to do this, have tried using
string->date with results below
Enter `,help' for help.
scheme@(guile-user)> (define date "2011-03-24T20:30:47Z")
scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (string->date "~Y-m-dT~H:~M:SZ" date)
srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
bad-date-format-string: "2011-03-24T20:30:47Z"
You got the args reversed: it's first the date string, then the
template. Besides, you forgot a couple of tildes in your template
(e.g. it's "~m" and not just "m" and so on). Lastly, the template
for the zone offset is "~z" (a small z). The "big Z" in your input
string is just a concrete zone (afaik UTC).
This works:
scheme@(guile-user)> (define mydate "2011-03-24T20:30:47Z")
scheme@(guile-user)> (string->date mydate "~Y-~m-~dT~H:~M:~S~z")
$3 = #<date nanosecond: 0 second: 47 minute: 30 hour: 20 day: 24 month:
3 year: 2011 zone-offset: 0>
hth
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlii/LMACgkQBcgs9XrR2kbySACfY3yqQgFw4XWIBZo1Nif8exJ1
jwUAn04XBldYBIWDDhheEjI1nLbFbjhm
=MJ3B
-----END PGP SIGNATURE-----
------------------------------
Message: 5
Date: Tue, 14 Feb 2017 13:11:07 +0000
From: Chris Vine <address@hidden>
To: Guy Baumann <address@hidden>
Cc: address@hidden
Subject: Re: Help formatting a UTC Timestamp
Message-ID: <address@hidden>
Content-Type: text/plain; charset=US-ASCII
On Tue, 14 Feb 2017 12:27:16 +0000
Guy Baumann <address@hidden> wrote:
I am trying to format a timestamp from an api. It is sent in the
format "2011-03-24T20:30:47Z"
what I want to output is something like this
(strftime "%d %b %g " (localtime (current-time)) )
However I am unable to work out how to do this, have tried using
string->date with results below
Enter `,help' for help.
scheme@(guile-user)> (define date "2011-03-24T20:30:47Z")
scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (string->date "~Y-m-dT~H:~M:SZ" date)
srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
bad-date-format-string: "2011-03-24T20:30:47Z"
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> (string->date date "~Y-m-dT~H:~M:SZ")
srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
bad-date-format-string: "~Y-m-dT~H:~M:SZ"
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [2]> (string->date date "~Y-m-dT~H:~M:SZ")
srfi/srfi-19.scm:1415:18: In procedure priv:string->date:
srfi/srfi-19.scm:1415:18: In procedure string->date: TIME-ERROR type
bad-date-format-string: "~Y-m-dT~H:~M:SZ"
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [3]> (string->date "2000" "~Y")
srfi/srfi-19.scm:571:22: In procedure encode-julian-day-number:
srfi/srfi-19.scm:571:22: In procedure -: Wrong type: #f
You haven't got the escapes quite right. This will work:
(string->date date "~Y-~m-~dT~H:~M:~SZ")
As will this with skipping, given that your example uses numeric values:
(string->date date "~Y~m~dT~H~M~SZ")
Chris
------------------------------
Subject: Digest Footer
_______________________________________________
guile-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/guile-user
------------------------------
End of guile-user Digest, Vol 171, Issue 14
*******************************************