Commit Graph

25 Commits

Author SHA1 Message Date
Edwin Brady
050abe663e
Merge pull request #1638 from stepancheg/idris2-time
Use C idris2_time for all C-based backends
2021-07-16 09:40:08 +01:00
Stefan Höck
599d0635e9
[ refactor ] JS backend overhaul (#1609) 2021-07-10 11:15:21 +01:00
Stiopa Koltsov
3d5ad0ca91 Use C idris2_time for all C-based backends 2021-06-28 23:57:58 +01:00
Kamiλ Shakirov
8e30b296c0
[ refactor ] Remove Data.Strings module (#1607) 2021-06-28 13:48:37 +01:00
Stiopa Koltsov
a6555549ee Route System.prim__system through C function
To be able to eventually refactor/extend `system` function: to be
able to specify a directory, environment variables, specify arguments
as array etc. Ideally it should be something like Rust
[`std::process::Command`](https://doc.rust-lang.org/std/process/struct.Command.html).
2021-06-28 11:28:14 +01:00
Nick Drozd
ec438760d9
Simplify some lambdas (#1561) 2021-06-16 15:22:30 +01:00
Fabián Heredia Montiel
dad4dcdaf8 Add totality annotations to src and libs/{prelude, base} 2021-06-12 21:06:08 -05:00
Mathew Polzin
a0a417240e
Simple signal handling (#1458) 2021-05-25 16:45:46 +01:00
stefan-hoeck
e293d82577 [ fix ] System.getArgs on node backend 2021-05-25 13:26:42 +01:00
Robert Wright
cd3906645b Add RefC getArgs support 2021-05-20 14:25:16 +01:00
Robert Wright
2a957a38d9 Add RefC FFI header file support 2021-05-20 14:25:16 +01:00
Guillaume ALLAIS
23b67d18ab [ lint ] remove trailing whitespace 2021-04-07 16:33:59 +01:00
Niklas Larsson
084997a880 Replace prim__getArgs with prim__getArgsCount and prim__getArg
This spares us from having to build Idris data structures in the foreign
code.
2021-04-03 10:45:02 +02:00
CodingCellist
89a84a34a4
Patch CVs and sleep in Racket (#1059) 2021-03-15 13:43:12 +00:00
Kamil Shakirov
8544e80076 Use the same naming convention for foreign primitives 2020-08-19 14:05:28 +01:00
Nick Drozd
e14a589e90 Consolidate boolean expressions 2020-07-12 21:00:33 -05:00
Rui Barreiro
88f8e745b1 Merge branch 'master' of github.com:idris-lang/Idris2 into javascript 2020-07-05 12:19:45 +01:00
Edwin Brady
dbdf7dab3d Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:

- it's easier for backend authors if the type of IO operations is
  slightly less restrictive. For example, if it's in HasIO, that limits
  alternative implementations, which might be awkward for some
  alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
  be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
  instance (I have personally never encountered one - if they turns out
  to exist, again, we can revisit!)
2020-06-21 19:21:22 +01:00
Edwin Brady
28855088c2 Split HasIO into HasIO and MonadIO
For things which don't require (>>=), HasIO is fine, otherwise MonadIO
gives access to the monad interface.
2020-06-21 14:46:14 +01:00
Edwin Brady
d12487f529 HasIO interface for IO actions
Also updates the Prelude and some base libraries to use HasIO rather
than using IO directly.
2020-06-21 01:18:43 +01:00
Rui Barreiro
f8f09858e8 Merge branch 'master' of github.com:idris-lang/Idris2 into javascript 2020-06-17 23:48:39 +01:00
Rui Barreiro
cb7dc7bffc test node004 passes 2020-06-17 23:29:54 +01:00
Niklas Larsson
630e4219fc Fix unsetenv
implement Windows support
2020-06-16 12:09:22 +02:00
Edwin Brady
c88bf7af8d Fix import loading
This was taking too long, and adding too many things, because it was
going too deep in the name of having everything accessible at the REPL
and for the compiler. So, it's done a bit differently now, only chasing
everything on a "full" load (i.e., final load at the REPL)

This has some effects:
+ As systems get bigger, load time gets better (on my machine, checking
  Idris.Main now takes 52s from scratch, down from 76s)
+ You might find import errors that you didn't previously get, because
  things were being imported that shouldn't have been. The new way is
  correct!

An unfortunate effect is that sometimes you end up getting "undefined
name" errors even if you didn't explicitly use the name, because
sometimes a module uses a name from another module in a type, which then
gets exported, and eventually needs to be reduced. This mostly happens
because there is a compile time check that should be done which I
haven't implemented yet. That is, public export definitions should only
be allowed to use names that are also public export. I'll get to this
soon.
2020-05-27 15:49:03 +01:00
Edwin Brady
dec7dff622 Add libraries 2020-05-18 14:00:08 +01:00