| Type | Bug | Status | dismissed | Date | 29-Sep-2014 21:24 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Ports | Submitted by | fork |
| Platform | All | Severity | not a bug | Priority | normal |
| Summary | HEAD modifies PORT! arguments |
|---|---|
| Description |
HEAD does not modify its argument if it is a series. You get a new series index. But if you pass HEAD a PORT! it modifies the argument. It should leave the argument at the position it is, and give you a new port with a position state. |
| Example code |
;;-- CURRENT BEHAVIOR
>> open %foo.txt
>> read foo
#{1122334455}
>> read foo
#{}
>> head foo
>> read foo
#{1122334455}
;;-- DESIRED BEHAVIOR
>> open %foo.txt
>> read foo
#{1122334455}
>> read foo
#{}
>> head foo
>> bar: head foo
>> read foo
#{}
>> read bar
#{1122334455}
|
| Assigned to | n/a | Fixed in | - | Last Update | 21-Oct-2014 18:01 |
|---|
| Comments | |
|---|---|
|
(0004510)
abolka 29-Sep-2014 22:03 |
Good observation, but the current behaviour works as designed. Actions (action!) are polymorphic over their datatype. HEAD, NEXT, SKIP, COPY etc all currently mutate port state and that's the intended behaviour. As such, this is definitely not a bug. |
|
(0004511)
szeng 29-Sep-2014 23:57 |
yes, this is kinda inconsistent, but returning a new port will introduce some side effects that might not be desirable, because a port is more than a plain series, it usually has some other resources with it, e.g. a network port has a network connection with it and a file port has a file descriptor with it. So returning a new port would mean new resources need to be created, which might or might not desirable. |
|
(0004512)
fork 30-Sep-2014 00:06 |
It would be better if doing "head foo" invalidated that foo, and if you tried to use it would throw an error. That way you would need to say "foo: head foo" instead.
That would be a more forward-looking solution, enabling an era in which it would be possible to keep things consistent without it being a resource burden, while having the code be coherent with series. |
|
(0004513)
szeng 30-Sep-2014 00:23 |
invalidating a port does modify the port, AFAICT. To really mimic the behavior of a series, you would need to introduce another wrapper structure around the port, just as the REBSRI around REBSER, so that you can use the same underlying port while keeping different indexes in the wrapper. |
|
(0004514)
fork 30-Sep-2014 00:26 |
Well, I'm proposing that even a dummy REBPRI which can only hold a port reference that is "valid" or "invalid" would leave room for future expansion...where code written to respect the invalidation and always pass the port into a new hot potato would continue to work if a better REBPRI were written. |
|
(0004527)
BrianH 21-Oct-2014 17:57 |
It is possible to make a port scheme that behaves the way that you suggest, for schemes that can possibly have series-like semantics. However, many port schemes aren't even remotely series-like, and creating a new port that is supposed to be referring to the same data at another position is only theoretically possible with schemes that even have position as a concept, and are able to share (one and/or the other are not true of some schemes).
The whole point to port schemes is that you can make them what they need to be. And what they need to be is usually not series. Btw, szeng, you can do this with port schemes now. They just have to be port schemes that emulate shared, offset, series-like semantics. It's not appropriate for most port schemes, but there was once a virtual block scheme that should have worked this way, but only partly did; there's no reason it wouldn't be able to work in a series-like way. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 21-Oct-2014 18:01 | BrianH | Description | Modified | - |
| 21-Oct-2014 18:01 | BrianH | Code | Modified | - |
| 21-Oct-2014 18:01 | BrianH | Category | Modified | Unspecified => Ports |
| 21-Oct-2014 18:01 | BrianH | Severity | Modified | minor => not a bug |
| 21-Oct-2014 18:01 | BrianH | Status | Modified | submitted => dismissed |
| 21-Oct-2014 18:01 | BrianH | Comment : 0004527 | Modified | - |
| 21-Oct-2014 17:57 | BrianH | Comment : 0004527 | Added | - |
| 30-Sep-2014 00:26 | fork | Comment : 0004514 | Added | - |
| 30-Sep-2014 00:23 | szeng | Comment : 0004513 | Added | - |
| 30-Sep-2014 00:06 | fork | Comment : 0004512 | Added | - |
| 29-Sep-2014 23:57 | szeng | Comment : 0004511 | Added | - |
| 29-Sep-2014 22:03 | abolka | Comment : 0004510 | Added | - |
| 29-Sep-2014 21:24 | fork | Ticket | Added | - |